The version of Bullet included under src/collision/bullet does not support C++11 due to issues in LinearMath/btSerializer.cpp, which have since been resolved upstream.

I see two courses of action that we can take in order to easily begin supporting C++11 in Chrono:

1. Fix the incompatibilities. This is easier and will minimize the amount of testing required. However, we will lose out on any bugfixes that may have been introduced over the last five years/1300 commits.
2. Update to a more recent version of Bullet. This will allow us to benefit from the last five years of Bullet's development, but could introduce new bugs. All validation tests will need to be rerun.

(There is also a third option in which the build system is told to build anything Bullet-related as C++03, but that only delays the issue and adds unnecessary complexity.)

If option 2 is chosen, I ask whoever performs the update to do the following:

• Continue to clearly mark lines where any changes were made.
• Make it obvious which version/commit of Bullet is being used.
• Include all relevant licenses.
• Preferably move the directory to src/thirdparty to make it obvious that the code is developed by a third party not associated with Chrono.
• Update CMakeLists.txt with all files (including headers). This is required for packaging and distribution.

I have tracked down Chrono's version to around Bullet SHA 41314b5ebc. A diff of the real version of Bullet and Chrono's modified version is at: https://gist.github.com/andrewseidl/5ad3b592675465a4b569#file-bullet-diff

The header file is not copied to the install directory (because it is not in the CMakeLists.txt).

Several of the include files for the DEM demos have incorrect capitalization, i.e. "CHapidll.h" instead of "ChApidll.h", causing the builds to fail on Linux.

I try to build the project in folder template_project. There are only 2 file in this folder: CMakeLists.txt and my_example.cpp. While buiding, I follow the guidelines from http://api.chrono.projectchrono.org/tutorial_install_project.html. CMAKE can generate *.sln without any problem. But when compiling the project in VS 2015, it shows "error C2259 cannot instantiate abstract class due to following members". The error is from this line:

What should I do to resolve this issue?

I'm on Arch linux 64 bit. I'm trying to compile from git.
I have python and irrlicht installed.
I've enabled python, irrlicht and vehicle with cmake and this what I get when trying to compile at 59%.

[ 59%] Linking CXX shared module _ChronoEngine_python_irrlicht.so
Error copying file "/home/tapir/Documents/chronoengine-git/src/chrono/build/lib/libChronoEngine_irrlicht.so" to "/usr/bin/DLLs/.".
make[2]: *** [src/chrono_python/CMakeFiles/_ChronoEngine_python_irrlicht.dir/build.make:108: src/chrono_python/_ChronoEngine_python_irrlicht.so] Error 1
make[2]: *** Deleting file 'src/chrono_python/_ChronoEngine_python_irrlicht.so'
make[1]: *** [CMakeFiles/Makefile2:1268: src/chrono_python/CMakeFiles/_ChronoEngine_python_irrlicht.dir/all] Error 2
make: *** [Makefile:161: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

If I leave out Irrlicht but keep python on then this is what I get:

[ 67%] Building CXX object src/chrono_python/CMakeFiles/_ChronoEngine_python_core.dir/__/__/python/ChModuleCorePYTHON_wrap.cxx.o
[ 67%] Linking CXX shared module /usr/bin/DLLs/_ChronoEngine_python_core.so
/usr/bin/ld: cannot open output file /usr/bin/DLLs/_ChronoEngine_python_core.so: No such file or directory
collect2: error: ld returned 1 exit status
make[2]: *** [src/chrono_python/CMakeFiles/_ChronoEngine_python_core.dir/build.make:105: /usr/bin/DLLs/_ChronoEngine_python_core.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:1228: src/chrono_python/CMakeFiles/_ChronoEngine_python_core.dir/all] Error 2
make: *** [Makefile:161: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

Disabling python and re-enabling irrlicht, compiles OK.

This came up in conversation and I figure the best thing to do is raise it here for consideration. I think there are quite a few people from within the government working on aspects of chrono that should be pushed back into the upstream. Chrono is already licensed so there is way less complexity from a government participation standpoint. There is a sticking point on contributions from people who cannot assign copyright, ARL is hashing some of these ideas out over here.

I am not a lawyer, but I think that for this project a simple contributor agreement that reassigns copyright to the project maintainers would get the government people around any worry that their legal department would get obnoxious about them attempting to contribute upstream. A contributor agreement that has to be agreed to by the person submitting the pull request / commit would get around the worry that their work would be public domain and otherwise not encapsulated by the projects license.

Mainly, its hard to get lawyers to agree to let us contribute code upstream. If the choices were all made for us by the upstream source it will reduce the discussion space.

I've had Chrono Engine up and running with Irrlicht, but want to add Python now to utilize the Solidworks plugin, but I can't get Chrono to build with Python.

For the record I'm installing on Ubuntu, using python3.4 and swig 3.0.7 (also tried older releases of python and swig but get the same errors). During the build, first I get a lot of warnings that say:

/home/james/chrono/src/chrono_python/../chrono/core/ChSmartpointers.h:330: Warning 503: Can't wrap 'operator bool_type' unless renamed to a valid identifier.

But the make continues, then finally stops with two errors given below. Any help would be greatly appreciated!

[ 87%] Building CXX object src/chrono_python/CMakeFiles/ChronoEngine_python_core.dir/__/**/python/ChModuleCorePYTHON_wrap.cxx.o
/home/james/chrono/chrono_build/python/ChModuleCorePYTHON_wrap.cxx: In member function ‘virtual void chrono::ChLogPython::Output(const char, size_t)’:
/home/james/chrono/chrono_build/python/ChModuleCorePYTHON_wrap.cxx:6890:29: warning: format not a string literal and no format arguments [-Wformat-security]
PySys_WriteStdout(buffer);
^
/home/james/chrono/chrono_build/python/ChModuleCorePYTHON_wrap.cxx: In function ‘PyObject_ PyInit__ChronoEngine_python_core()’:
/home/james/chrono/chrono_build/python/ChModuleCorePYTHON_wrap.cxx:531125:133: error: taking address of temporary [-fpermissive]
SWIG_Python_SetConstant(d, "CSYSNULL",SWIG_NewPointerObj(SWIG_as_voidptr(&chrono::ChCoordsys< double >(chrono::VNULL,chrono::QNULL)),SWIGTYPE_p_chrono__ChCoordsysT_double_t, 0 ));
^
/home/james/chrono/chrono_build/python/ChModuleCorePYTHON_wrap.cxx:1172:89: note: in definition of macro ‘SWIG_NewPointerObj’
#define SWIG_NewPointerObj(ptr, type, flags) SWIG_Python_NewPointerObj(NULL, ptr, type, flags)
^
/home/james/chrono/chrono_build/python/ChModuleCorePYTHON_wrap.cxx:531125:60: note: in expansion of macro ‘SWIG_as_voidptr’
SWIG_Python_SetConstant(d, "CSYSNULL",SWIG_NewPointerObj(SWIG_as_voidptr(&chrono::ChCoordsys< double >(chrono::VNULL,chrono::QNULL)),SWIGTYPE_p_chrono__ChCoordsysT_double_t, 0 ));
^
/home/james/chrono/chrono_build/python/ChModuleCorePYTHON_wrap.cxx:531126:133: error: taking address of temporary [-fpermissive]
SWIG_Python_SetConstant(d, "CSYSNORM",SWIG_NewPointerObj(SWIG_as_voidptr(&chrono::ChCoordsys< double >(chrono::VNULL,chrono::QUNIT)),SWIGTYPE_p_chrono__ChCoordsysT_double_t, 0 ));
^
/home/james/chrono/chrono_build/python/ChModuleCorePYTHON_wrap.cxx:1172:89: note: in definition of macro ‘SWIG_NewPointerObj’
#define SWIG_NewPointerObj(ptr, type, flags) SWIG_Python_NewPointerObj(NULL, ptr, type, flags)
^
/home/james/chrono/chrono_build/python/ChModuleCorePYTHON_wrap.cxx:531126:60: note: in expansion of macro ‘SWIG_as_voidptr’
SWIG_Python_SetConstant(d, "CSYSNORM",SWIG_NewPointerObj(SWIG_as_voidptr(&chrono::ChCoordsys< double >(chrono::VNULL,chrono::QUNIT)),SWIGTYPE_p_chrono__ChCoordsysT_double_t, 0 ));
^
make[2]: * [src/chrono_python/CMakeFiles/_ChronoEngine_python_core.dir//__/python/ChModuleCorePYTHON_wrap.cxx.o] Error 1
make[1]: *** [src/chrono_python/CMakeFiles/_ChronoEngine_python_core.dir/all] Error 2
make: *** [all] Error 2

I've enabled unit_Matlab according the directions describe here. However, when I tried to build the demos, I ran into the following linking error:

1>------ Build started: Project: demo_matlab, Configuration: Release Win32 ------
1>Linking...
1>demo_matlab.obj : error LNK2019: unresolved external symbol _engOpen referenced in function "public: __thiscall chrono::ChMatlabEngine::ChMatlabEngine(void)" (??0ChMatlabEngine@chrono@@QAE@XZ)
1>demo_matlab.obj : error LNK2019: unresolved external symbol _engClose referenced in function "public: __thiscall chrono::ChMatlabEngine::~ChMatlabEngine(void)" (??1ChMatlabEngine@chrono@@QAE@XZ)
1>demo_matlab.obj : error LNK2019: unresolved external symbol _engEvalString referenced in function "public: bool __thiscall chrono::ChMatlabEngine::Eval(char *)" (?Eval@ChMatlabEngine@chrono@@QAE_NPAD@Z)
1>demo_matlab.obj : error LNK2019: unresolved external symbol _mxDestroyArray referenced in function "public: bool __thiscall chrono::ChMatlabEngine::PutVariable(class chrono::ChMatrix<double> const &,char *)" (?PutVariable@ChMatlabEngine@chrono@@QAE_NABV?$ChMatrix@N@2@PAD@Z)
1>demo_matlab.obj : error LNK2019: unresolved external symbol _engPutVariable referenced in function "public: bool __thiscall chrono::ChMatlabEngine::PutVariable(class chrono::ChMatrix<double> const &,char *)" (?PutVariable@ChMatlabEngine@chrono@@QAE_NABV?$ChMatrix@N@2@PAD@Z)
1>demo_matlab.obj : error LNK2019: unresolved external symbol _mxGetPr referenced in function "public: bool __thiscall chrono::ChMatlabEngine::PutVariable(class chrono::ChMatrix<double> const &,char *)" (?PutVariable@ChMatlabEngine@chrono@@QAE_NABV?$ChMatrix@N@2@PAD@Z)
1>demo_matlab.obj : error LNK2019: unresolved external symbol _mxCreateDoubleMatrix_730 referenced in function "public: bool __thiscall chrono::ChMatlabEngine::PutVariable(class chrono::ChMatrix<double> const &,char *)" (?PutVariable@ChMatlabEngine@chrono@@QAE_NABV?$ChMatrix@N@2@PAD@Z)
1>demo_matlab.obj : error LNK2019: unresolved external symbol _mxGetDimensions_730 referenced in function "public: bool __thiscall chrono::ChMatlabEngine::GetVariable(class chrono::ChMatrixDynamic<double> &,char *)" (?GetVariable@ChMatlabEngine@chrono@@QAE_NAAV?$ChMatrixDynamic@N@2@PAD@Z)
1>demo_matlab.obj : error LNK2019: unresolved external symbol _mxGetNumberOfDimensions_730 referenced in function "public: bool __thiscall chrono::ChMatlabEngine::GetVariable(class chrono::ChMatrixDynamic<double> &,char *)" (?GetVariable@ChMatlabEngine@chrono@@QAE_NAAV?$ChMatrixDynamic@N@2@PAD@Z)
1>demo_matlab.obj : error LNK2019: unresolved external symbol _engGetVariable referenced in function "public: bool __thiscall chrono::ChMatlabEngine::GetVariable(class chrono::ChMatrixDynamic<double> &,char *)" (?GetVariable@ChMatlabEngine@chrono@@QAE_NAAV?$ChMatrixDynamic@N@2@PAD@Z)
1>C:\Users\Daniel\Documents\SBEL\Chrono_GIT_build\bin\Release\demo_matlab.exe : fatal error LNK1120: 10 unresolved externals
1>Build log was saved at "file://c:\Users\Daniel\Documents\SBEL\Chrono_GIT_build\demos\matlab\demo_matlab.dir\Release\BuildLog.htm"
1>demo_matlab - 11 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 2 up-to-date, 0 skipped ==========

I'm currently running on Windows 7, using MSVC with Matlab2013a installed.

Followed the instructions here: http://api.projectchrono.org/tutorial_install_chrono.html

chrono\src\chrono\utils\ChParserOpenSim.cpp : fatal error C1128: number of sections exceeded object file format limit: compile with /bigobj

64-bit Debug build.

From ChHashFunction.h, line 77:

/// Specialized hash function for strings (other version)
///
struct HashFunction_String2
{
    unsigned operator()(const std::string& key) const 
    { 
        size_t n = key.length();
        const char* d = key.c_str();
        unsigned h = 0; 
        for (size_t i = 0; i < n; ++i, ++d)
              h = (h << 2) + *d;
        return ((h >= 0) ? (h ) : (-h ));
    }
};

Question: Why when returning h, which is unsigned, do you check to ensure h is positive? This seems unnecessary.

I'm looking to build chrono against the version of bullet that is currently integrated into my project (currently version 2.82). Are there any modifications to the included version of bullet that might prevent me from building against the version I already have integrated?

Cheers,

Bob

Hello, I have successfully built a physical system using module parallel, but then I found out a problem with the function GetTotalAABB(), details are as follows:
When I define the system like:
ChSystemNSC mphysicalSystem(false,1000,20); auto scene = std::make_shared<ChBody>(); scene->SetPos(ChVector<>(0, 0, 0)); scene->SetBodyFixed(true); mphysicalSystem.Add(scene); scene->GetCollisionModel()->ClearModel(); scene->GetCollisionModel()->AddTriangleMesh(mmeshbox,false, false, VNULL, ChMatrix33<>(1), 0.005); scene->GetCollisionModel()->BuildModel(); scene->SetCollide(true); ChVector<> bbmin, bbmax; scene->GetTotalAABB(bbmin,bbmax); std::cout<<"min of scene"<<bbmin.x()<<" "<<bbmin.y()<<" "<<bbmin.z()<<" "<<std::endl; std::cout<<"max of scene"<<bbmax.x()<<" "<<bbmax.y()<<" "<<bbmax.z()<<" "<<std::endl;
I get outputs like:
min of scene-0.587664 -0.0730529 -8.3998 max of scene5.23018 4.38043 4.31234
Then I just changed several lines to use module parallel:
ChSystemParallelNSC mphysicalSystem; auto scene = std::make_shared<ChBody>(std::make_shared<collision::ChCollisionModelParallel>()); ChVector<> bbmin, bbmax; scene->GetTotalAABB(bbmin,bbmax); std::cout<<"min of scene"<<bbmin.x()<<" "<<bbmin.y()<<" "<<bbmin.z()<<" "<<std::endl; std::cout<<"max of scene"<<bbmax.x()<<" "<<bbmax.y()<<" "<<bbmax.z()<<" "<<std::endl;
I didn't change other things and I got:
min of scene0 0 0 max of scene0 0 0
Is there something I was missing or I just misunderstood this function? Thank you.

The current README would serve better as release notes.

A new readme with info about the project, quickstart on how to use Chrono, and links to documentation needs to be written.

Hi,

Chrono tag 2.0.0 failed to build on MacOsX Yosemite 10.10.5 with Clang.

ohana:chrono acary$ /usr/bin/c++ --version
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
ohana:chrono acary$ make
[ 0%] Building CXX object CMakeFiles/ChronoEngine.dir/collision/ChCModelBullet.cpp.o
In file included from /Users/acary/Softs/chrono/src/collision/ChCModelBullet.cpp:25:
In file included from /Users/acary/Softs/chrono/src/physics/ChSystem.h:50:
In file included from /Users/acary/Softs/chrono/src/physics/ChLinksAll.h:38:
In file included from /Users/acary/Softs/chrono/src/physics/ChLinkPneumaticActuator.h:34:
In file included from /Users/acary/Softs/chrono/src/pneumatica/assepneumatico.h:20:
In file included from /Users/acary/Softs/chrono/src/pneumatica/sis_attuatore_3_2.h:22:
In file included from /Users/acary/Softs/chrono/src/pneumatica/pistone_3_2.h:22:
In file included from /Users/acary/Softs/chrono/src/pneumatica/pistone.h:23:
/Users/acary/Softs/chrono/src/pneumatica/volume.h:42:40: warning: expression result unused [-Wunused-value]
volume() {rho=1.225; p0=101325, n = 1,4;g=p=v=v1=0;};
^
In file included from /Users/acary/Softs/chrono/src/collision/ChCModelBullet.cpp:32:
In file included from /Users/acary/Softs/chrono/src/collision/ChCConvexDecomposition.h:32:
/Users/acary/Softs/chrono/src/collision/convexdecomposition/HACD/hacdHACD.h:309:53: error: friend declaration specifying a default argument must be a definition
friend HACD * const CreateHACD(HeapManager * heapManager = 0);
^
/Users/acary/Softs/chrono/src/collision/convexdecomposition/HACD/hacdHACD.h:312:25: error: friend declaration specifying a default argument must be the only declaration
inline HACD * const CreateHACD(HeapManager * heapManager)
^
/Users/acary/Softs/chrono/src/collision/convexdecomposition/HACD/hacdHACD.h:309:53: note: previous declaration is here
friend HACD * const CreateHACD(HeapManager * heapManager = 0);
^
/Users/acary/Softs/chrono/src/collision/convexdecomposition/HACD/hacdHACD.h:314:20: error: calling a private constructor of class 'HACD::HACD'
return new HACD(heapManager);
^
/Users/acary/Softs/chrono/src/collision/convexdecomposition/HACD/hacdHACD.h:226:14: note: declared private here
HACD(HeapManager * heapManager = 0);
^
1 warning and 3 errors generated.
make[2]: *** [CMakeFiles/ChronoEngine.dir/collision/ChCModelBullet.cpp.o] Error 1
make[1]: *** [CMakeFiles/ChronoEngine.dir/all] Error 2
make: *** [all] Error 2

moving ChNodeBody.h from ../physics to ../unit_FEM causes a compiler error on windows on two demos,
demos/fem/demo_meshless.cpp
demos/irrlicht/demo_sph.cpp

should probably generalize ChNodeBody to work with any object that can be constrained to a rigid body, not just FEM nodes, and have ChNodeBody.h implement that base class.

@Milad-Rakhsha we are not able to build Chrono projects on ubuntu 14.04 because of the following compil errors. I Seem to recall that we fixed this, but maybe I'm wrong. Here's a more complete error trace:

mpicc -fno-strict-aliasing -g -O2 -g -fwrapv -w -fPIC -I/buildbot/Ubuntu_14_04/build/linux2/lib/python2.7/site-packages/numpy/core/include -Iproteus -I/buildbot/Ubuntu_14_04/build/linux2/include -I/buildbot/Ubuntu_14_04/build/linux2/include/chrono/collision/bullet -I/buildbot/Ubuntu_14_04/build/linux2/include/python2.7 -c proteus/mbd/pyChronoCore.cpp -o build/temp.linux-x86_64-2.7/proteus/mbd/pyChronoCore.o -std=c++11
3651In file included from /buildbot/Ubuntu_14_04/build/linux2/include/chrono/core/ChMatrixNM.h:18:0,
3652                 from /buildbot/Ubuntu_14_04/build/linux2/include/chrono/core/ChMatrix33.h:18,
3653                 from /buildbot/Ubuntu_14_04/build/linux2/include/chrono/collision/ChCCollisionModel.h:20,
3654                 from /buildbot/Ubuntu_14_04/build/linux2/include/chrono/collision/ChCCollisionInfo.h:17,
3655                 from /buildbot/Ubuntu_14_04/build/linux2/include/chrono/collision/ChCCollisionSystem.h:18,
3656                 from /buildbot/Ubuntu_14_04/build/linux2/include/chrono/physics/ChSystem.h:26,
3657                 from proteus/mbd/ChMoorings.h:8,
3658                 from proteus/mbd/pyChronoCore.cpp:458:
3659/buildbot/Ubuntu_14_04/build/linux2/include/chrono/core/ChMatrix.h: In member function 'void chrono::ChMatrix<Real>::MatrMultiplyAVX(const chrono::ChMatrix<double>&, const chrono::ChMatrix<double>&)':
3660/buildbot/Ubuntu_14_04/build/linux2/include/chrono/core/ChMatrix.h:547:17: error: '__m256d' was not declared in this scope
3661                 __m256d sum = _mm256_setzero_pd();
3662                 ^
3663/buildbot/Ubuntu_14_04/build/linux2/include/chrono/core/ChMatrix.h:547:25: error: expected ';' before 'sum'
3664                 __m256d sum = _mm256_setzero_pd();
3665                         ^
3666/buildbot/Ubuntu_14_04/build/linux2/include/chrono/core/ChMatrix.h:549:29: error: expected ';' before 'ymmA'
3667                     __m256d ymmA = _mm256_broadcast_sd(A_add + A_NCol * rowA + elem);
3668                             ^
3669/buildbot/Ubuntu_14_04/build/linux2/include/chrono/core/ChMatrix.h:550:29: error: expected ';' before 'ymmB'
3670                     __m256d ymmB = _mm256_loadu_pd(B_add + elem * B_NCol + colB);
3671                             ^
3672/buildbot/Ubuntu_14_04/build/linux2/include/chrono/core/ChMatrix.h:551:29: error: expected ';' before 'prod'
3673                     __m256d prod = _mm256_mul_pd(ymmA, ymmB);```

See bulletphysics/bullet3#394 for discussion.

How this gets fixed in chrono depends on which minimum C++ standard version is supported. If C++11 is OK then intptr_t could be used to easily fix it.

It appears that OpenCASCADE 6.8 has changed or removed BRepMesh::Mesh, which is used by unit_CASCADE/ChCascadeMeshTools.cpp and unit_CASCADE/ChIrrCascadeMeshTools.h. This prevents the use of Chrono with the latest versions of OpenCASCADE.

I'm not sure if it's a bug or not, but if I put mphysicalSystem.SetTimestepperType(ChTimestepper::Type::RUNGEKUTTA45); in demo_IRR_emit_processor.cpp, then the objects spawned doesn't collide the ground.

should it be possible to compile unit_FEM without unit_MATLAB? Currently I need to make some changes to demos/fem/CMakeLists.txt to be able to compile this (in windows, msvc 2010)

Hi, I am trying to install on linux,(ubuntu 14.04). But I get the following error.

CMake Error at build/CMakeFiles/git-data/grabRef.cmake:36 (file):
  file failed to open for reading (No such file or directory):

    /home/yunxiao/Downloads/chrono-develop/build/CMakeFiles/git-data/head-ref
Call Stack (most recent call first):
  cmake/GetGitRevisionDescription.cmake:77 (include)
  CMakeLists.txt:76 (get_git_head_revision)

what may be the problem?
-shan

clang throws the following error during compiling process:

chrono/src/collision/convexdecomposition/HACD/hacdHACD.h:309:53: error: friend declaration specifying a default
argument must be a definition
friend HACD * const CreateHACD(HeapManager * heapManager = 0);

the assignment "HeapManager * heapManager = 0" should be moved to definition.

C++11 introduced platform-independent timers and duration counters with std::chrono. Now that we're requiring C++11 support, new code should use std::chrono instead of platform-specific timers.

See, eg: http://en.cppreference.com/w/cpp/chrono/high_resolution_clock , http://en.cppreference.com/w/cpp/chrono/time_point , and http://en.cppreference.com/w/cpp/chrono/duration

Note that this may cause namespace issues in improper code that has using namespace chrono; or using namespace std;.

Hello, I'm trying to turn my code a bit faster by adding the parallel module. I installed boost, blaze and CUDA, and then I enabled MODULE_PARALLEL in CMake. I recompiled project chrono with success, but when I tried to include files like "chrono_parallel/physics/ChSystemParallel.h" and "chrono_parallel/collision/ChCollisionModelParallel.h" and compile my project I got errors like:
[ 50%] Building CXX object CMakeFiles/scenenet_room_generator.dir/scenenet_room_generator.cpp.o [100%] Linking CXX executable scenenet_room_generator CMakeFiles/scenenet_room_generator.dir/scenenet_room_generator.cpp.o：in function ‘el::base::debug::crashReason(int)’中： scenenet_room_generator.cpp:(.text+0x279)：对‘el::base::elStorage’ undefined reference CMakeFiles/scenenet_room_generator.dir/scenenet_room_generator.cpp.o：in function ‘el::base::LogFormat::updateFormatSpec()’中： scenenet_room_generator.cpp:(.text._ZN2el4base9LogFormat16updateFormatSpecEv[_ZN2el4base9LogFormat16updateFormatSpecEv]+0x905)：对‘el::base::utils::s_currentUser’ undefined reference scenenet_room_generator.cpp:(.text._ZN2el4base9LogFormat16updateFormatSpecEv[_ZN2el4base9LogFormat16updateFormatSpecEv]+0x944)：对‘el::base::utils::s_currentUser’ undefined reference scenenet_room_generator.cpp:(.text._ZN2el4base9LogFormat16updateFormatSpecEv[_ZN2el4base9LogFormat16updateFormatSpecEv]+0x9c3)：对‘el::base::utils::s_currentHost’ undefined reference CMakeFiles/scenenet_room_generator.dir/scenenet_room_generator.cpp.o：in function ‘el::base::LogDispatcher::dispatch()’中： scenenet_room_generator.cpp:(.text._ZN2el4base13LogDispatcher8dispatchEv[_ZN2el4base13LogDispatcher8dispatchEv]+0x52)：对‘el::base::elStorage’ undefined reference scenenet_room_generator.cpp:(.text._ZN2el4base13LogDispatcher8dispatchEv[_ZN2el4base13LogDispatcher8dispatchEv]+0x91)：对‘el::base::elStorage’ undefined reference scenenet_room_generator.cpp:(.text._ZN2el4base13LogDispatcher8dispatchEv[_ZN2el4base13LogDispatcher8dispatchEv]+0xac)：对‘el::base::elStorage’ undefined reference scenenet_room_generator.cpp:(.text._ZN2el4base13LogDispatcher8dispatchEv[_ZN2el4base13LogDispatcher8dispatchEv]+0xfb)：对‘el::base::elStorage’ undefined reference CMakeFiles/scenenet_room_generator.dir/scenenet_room_generator.cpp.o：in function ‘el::base::MessageBuilder::initialize(el::Logger*)’中： scenenet_room_generator.cpp:(.text._ZN2el4base14MessageBuilder10initializeEPNS_6LoggerE[_ZN2el4base14MessageBuilder10initializeEPNS_6LoggerE]+0x1c)：对‘el::base::elStorage’ undefined reference
Could you help me with that? Thank you.

Is there a particular reason why ChMatrix33::Get_A_quaternion() uses local variables of type double instead of the template argument Real?

Two things here, which may or may not be related.
First, load_normals and load_uv are not used, so the for() loops for loading data will always attempt to read in from both.

Second, when you load a Wavefront file that describes faces with only vertex and normals (and no texture coordinate), I get an error on line 122 of ChIrrNodeProxyToAsset.cpp (lines 121-122 shown):

if ( mmesh->getIndicesUV().size() == mmesh->getIndicesVertexes().size() ) {
                uv1 = mmesh->getCoordsUV()[ mmesh->getIndicesUV()[itri].x ];

I imagine this is user error, but I'm getting increases in momentum for a simple two body problem depending on the size of the time step even in Implicit Euler and HHT fails after repeated reduction of the time step. If I set the time step small enough with application->SetTimestep(); I can get it to go away, but I'm not sure how to set the time step a priori and was thinking chrono was doing something unconditionally stable and adapting dt based on error tolerances. Here is a video showing the issue:
chrono_momentum_conservation.avi.gz

Here is the code for solver config:

   // Change solver
    msystem.SetSolverType(ChSystem::SOLVER_MINRES);
    msystem.SetSolverWarmStarting(true);  // this helps a lot to speedup convergence in this class of problems
    msystem.SetMaxItersSolverSpeed(200);
    msystem.SetMaxItersSolverStab(200);
    msystem.SetTolForce(1e-10);

    // Change integrator:
    //msystem.SetIntegrationType(chrono::ChSystem::INT_EULER_IMPLICIT_LINEARIZED);  // default: fast, 1st order
    //msystem.SetIntegrationType(chrono::ChSystem::INT_HHT);  // precise, slower, might iterate each step
    msystem.SetIntegrationType(chrono::ChSystem::INT_EULER_IMPLICIT);  // precise, slower, might iterate each step

class ChApi ChBroadPhaseCallback
{
public:
/// Callback used to report 'near enough' pairs of models.
/// This must be implemented by a child class of ChBroadPhaseCallback.
/// Return false to skip narrow-phase contact generation for this pair of bodies.

• virtual bool BroadCallback(
  ChCollisionModel* mmodelA, ///< pass 1st model
  ChCollisionModel* mmodelB ///< pass 2nd model
  )
  {
  // do nothing by default - please inherit and implement it!
  return true;
  };
  };

Users running pre-VS2012 or pre-GCC 4.7 will need to update their compilers

On Unix-like systems at least, installing to /usr/local/ so that the chrono include directory is found on the default include search path causes the problem that although headers can be found using #include "chrono/some_header.h", any chrono headers included by that header assume a root of chrono, not its containing directory (/usr/local/include/ in this case), so they're not found. As an example, chrono/physics/ChSystem.h includes core/ChLog.h, when really it should include chrono/core/ChLog.h. Could this be fixed at all? Is there a reason that it's like this?

Compiling with unit_Python enabled fails when building Swig-generated wrapper files.

CentOS 6.2, GCC 4.4.6 and ArchLinux GCC 4.8.1

/dev/shm/chrono/build/unit_PYTHON/ChModuleCorePYTHON_wrap.cxx: In function ‘IteratorBodies IteratorBodies_Next(IteratorBodies*)’:
/dev/shm/chrono/build/unit_PYTHON/ChModuleCorePYTHON_wrap.cxx:6294: error: no ‘operator++(int)’ declared for postfix ‘++’, trying prefix operator instead
/dev/shm/chrono/build/unit_PYTHON/ChModuleCorePYTHON_wrap.cxx: In function ‘IteratorLinks IteratorLinks_Next(IteratorLinks*)’:
/dev/shm/chrono/build/unit_PYTHON/ChModuleCorePYTHON_wrap.cxx:6302: error: no ‘operator++(int)’ declared for postfix ‘++’, trying prefix operator instead
/dev/shm/chrono/build/unit_PYTHON/ChModuleCorePYTHON_wrap.cxx: In function ‘IteratorOtherPhysicsItems IteratorOtherPhysicsItems_Next(IteratorOtherPhysicsItems*
)’:
/dev/shm/chrono/build/unit_PYTHON/ChModuleCorePYTHON_wrap.cxx:6310: error: no ‘operator++(int)’ declared for postfix ‘++’, trying prefix operator instead
/dev/shm/chrono/build/unit_PYTHON/ChModuleCorePYTHON_wrap.cxx: In function ‘IteratorPhysicsItems IteratorPhysicsItems_Next(IteratorPhysicsItems*)’:
/dev/shm/chrono/build/unit_PYTHON/ChModuleCorePYTHON_wrap.cxx:6318: error: no ‘operator++(int)’ declared for postfix ‘++’, trying prefix operator instead

When using the numerical differentiation option in ANCF elements (such as ChElementBeamANCF, ChElementShellANCF, and ChElementBrick) I experienced much better convergence when changing the for-loop in the jacobian calculation from:

for (int inode = 0; inode <2; ++inode) (line 203 in ChElementBeamANCF)

to:

for (int inode = 0; inode <2; inode++)

I believe the problem is that this does not cycle through all of the nodes correctly for the internal force calculations.

use of std::sqrt and other math functions causes compilation error on linux
solution:
Either use cmath.h or, remove std:: before math functions
note that min will need to be changed to fmin

I would suggest removing std:: before math functions, that way only ChContactDEM.cpp needs to be changed.

Re:

It should be possible to remove a number of predefined compiler macros from this section since they are already set by the compiler. Specifically, _WIN64 will be defined when compiling on 64bit and _WIN32 will be defined on 32bit and 64bit. MinGW also has a standard set of macros.

Approximately 23 source files will need to be updated to reflect these changes.

A small gui error: the normal and tangent forces are switched when plotted in gui.

I see that Chrono has some capabilities for sensor models, but from what I can tell they are not yet as mature as the ones in Gazebo. On the other had Gazebo has a limited vehicle dynamic support and Chrono seems to do a much better job with this (from what I can tell). I noticed the repo that connects Gazebo and Chrono (to get the best of both worlds) called Chrono_Gazebo, but this package is out of date and I started to update it with https://github.com/amelmquist/Chrono_Gazebo/pull/6, but I am not very familiar with these tools, so it is my feeling that this will take quite a bit of work for me to complete. I noticed that Chrono supports interfacing with other software packages such as MATLAB and SolidWorks, but there is nothing for Gazebo.

Is there a reason that the Chrono_Gazebo project is not maintained and an option to use in the current Chrono?

Is there any potential to update this repo and maintain it with new versions of ROS, Gazebo and Chrono?

Also, am does Chrono run some of the HMMWV models in real-time, or am I waisting my time?
Thanks!

Have some minor isse when building against new cuda (9.2) mainly in type conversion.

[ 96%] Built target demo_PAR_ballsSMC
Scanning dependencies of target demo_GL_cohesion
In file included from /opt/cuda/include/thrust/detail/reference.h:173,
                 from /opt/cuda/include/thrust/memory.h:25,
                 from /opt/cuda/include/thrust/device_ptr.h:25,
                 from /opt/cuda/include/thrust/device_malloc_allocator.h:25,
                 from /opt/cuda/include/thrust/device_vector.h:25,
                 from /home/bartus/AUR/chronoengine/src/chronoengine/src/chrono_fsi/ChFsiDataManager.cuh:24,
                 from /home/bartus/AUR/chronoengine/src/chronoengine/src/chrono_fsi/ChFsiInterface.h:22,
                 from /home/bartus/AUR/chronoengine/src/chronoengine/src/chrono_fsi/ChFsiInterface.cpp:18:
/opt/cuda/include/thrust/detail/reference.inl: In instantiation of ‘thrust::reference<Element, Pointer, Derived>::value_type thrust::reference<Element, Pointer, Derived>::strip_const_get_value(const System&) const [with System = thrust::cuda_cub::tag; Element = chrono::fsi::Real3; Pointer = thrust::device_ptr<chrono::fsi::Real3>; Derived = thrust::device_reference<chrono::fsi::Real3>; thrust::reference<Element, Pointer, Derived>::value_type = chrono::fsi::Real3]’:
/opt/cuda/include/thrust/detail/reference.inl:105:54:   required from ‘thrust::reference<Element, Pointer, Derived>::value_type thrust::reference<Element, Pointer, Derived>::convert_to_value_type(System*) const [with System = thrust::cuda_cub::tag; Element = chrono::fsi::Real3; Pointer = thrust::device_ptr<chrono::fsi::Real3>; Derived = thrust::device_reference<chrono::fsi::Real3>; thrust::reference<Element, Pointer, Derived>::value_type = chrono::fsi::Real3]’
/opt/cuda/include/thrust/detail/reference.inl:122:38:   required from ‘thrust::reference<Element, Pointer, Derived>::operator thrust::reference<Element, Pointer, Derived>::value_type() const [with Element = chrono::fsi::Real3; Pointer = thrust::device_ptr<chrono::fsi::Real3>; Derived = thrust::device_reference<chrono::fsi::Real3>; thrust::reference<Element, Pointer, Derived>::value_type = chrono::fsi::Real3]’
/home/bartus/AUR/chronoengine/src/chronoengine/src/chrono_fsi/ChFsiInterface.cpp:99:66:   required from here
/opt/cuda/include/thrust/detail/reference.inl:137:19: error: could not convert ‘thrust::system::detail::generic::get_value<thrust::cuda_cub::tag, thrust::device_ptr<chrono::fsi::Real3> >((*(thrust::execution_policy<thrust::cuda_cub::tag>*)(& thrust::detail::derived_cast<thrust::cuda_cub::tag>((*(thrust::detail::execution_policy_base<thrust::cuda_cub::tag>*)(& non_const_system))))), ((const thrust::reference<chrono::fsi::Real3, thrust::device_ptr<chrono::fsi::Real3>, thrust::device_reference<chrono::fsi::Real3> >*)this)->thrust::reference<chrono::fsi::Real3, thrust::device_ptr<chrono::fsi::Real3>, thrust::device_reference<chrono::fsi::Real3> >::m_ptr)’ from ‘void’ to ‘thrust::reference<chrono::fsi::Real3, thrust::device_ptr<chrono::fsi::Real3>, thrust::device_reference<chrono::fsi::Real3> >::value_type’ {aka ‘chrono::fsi::Real3’}
   return get_value(thrust::detail::derived_cast(non_const_system), m_ptr);
          ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /opt/cuda/include/thrust/system/detail/generic/memory.inl:22,
                 from /opt/cuda/include/thrust/system/detail/generic/memory.h:71,
                 from /opt/cuda/include/thrust/detail/reference.inl:22,
                 from /opt/cuda/include/thrust/detail/reference.h:173,
                 from /opt/cuda/include/thrust/memory.h:25,
                 from /opt/cuda/include/thrust/device_ptr.h:25,
                 from /opt/cuda/include/thrust/device_malloc_allocator.h:25,
                 from /opt/cuda/include/thrust/device_vector.h:25,
                 from /home/bartus/AUR/chronoengine/src/chronoengine/src/chrono_fsi/ChFsiDataManager.cuh:24,
                 from /home/bartus/AUR/chronoengine/src/chronoengine/src/chrono_fsi/ChFsiInterface.h:22,
                 from /home/bartus/AUR/chronoengine/src/chronoengine/src/chrono_fsi/ChFsiInterface.cpp:18:
/opt/cuda/include/thrust/system/detail/generic/memory.inl: In instantiation of ‘void thrust::system::detail::generic::get_value(thrust::execution_policy<Derived>&, Pointer) [with DerivedPolicy = thrust::cuda_cub::tag; Pointer = thrust::device_ptr<chrono::fsi::Real3>]’:
/opt/cuda/include/thrust/detail/reference.inl:137:19:   required from ‘thrust::reference<Element, Pointer, Derived>::value_type thrust::reference<Element, Pointer, Derived>::strip_const_get_value(const System&) const [with System = thrust::cuda_cub::tag; Element = chrono::fsi::Real3; Pointer = thrust::device_ptr<chrono::fsi::Real3>; Derived = thrust::device_reference<chrono::fsi::Real3>; thrust::reference<Element, Pointer, Derived>::value_type = chrono::fsi::Real3]’
/opt/cuda/include/thrust/detail/reference.inl:105:54:   required from ‘thrust::reference<Element, Pointer, Derived>::value_type thrust::reference<Element, Pointer, Derived>::convert_to_value_type(System*) const [with System = thrust::cuda_cub::tag; Element = chrono::fsi::Real3; Pointer = thrust::device_ptr<chrono::fsi::Real3>; Derived = thrust::device_reference<chrono::fsi::Real3>; thrust::reference<Element, Pointer, Derived>::value_type = chrono::fsi::Real3]’
/opt/cuda/include/thrust/detail/reference.inl:122:38:   required from ‘thrust::reference<Element, Pointer, Derived>::operator thrust::reference<Element, Pointer, Derived>::value_type() const [with Element = chrono::fsi::Real3; Pointer = thrust::device_ptr<chrono::fsi::Real3>; Derived = thrust::device_reference<chrono::fsi::Real3>; thrust::reference<Element, Pointer, Derived>::value_type = chrono::fsi::Real3]’
/home/bartus/AUR/chronoengine/src/chronoengine/src/chrono_fsi/ChFsiInterface.cpp:99:66:   required from here
/opt/cuda/include/thrust/detail/static_assert.h:71:7: error: invalid application of ‘sizeof’ to incomplete type ‘thrust::detail::STATIC_ASSERTION_FAILURE<false>’
       sizeof(::thrust::detail::STATIC_ASSERTION_FAILURE< (bool)( B ) >)>\
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/cuda/include/thrust/detail/static_assert.h:71:7: note: in definition of macro ‘THRUST_STATIC_ASSERT’
       sizeof(::thrust::detail::STATIC_ASSERTION_FAILURE< (bool)( B ) >)>\
       ^~~~~~
[ 96%] Building CXX object src/demos/opengl/CMakeFiles/demo_GL_cohesion.dir/demo_GL_cohesion.cpp.o
[ 96%] Linking CXX executable ../../../bin/demo_GL_shapes

All the GetLog() output results at the end of the test return NaN.

I've traced the problem to the function ChLcpIterativeMINRES::Solve_SupportingStiffness(ChLcpSystemDescriptor& sysd), and without going into too much detail, the problem occurs after the first few iterations in the loop starting on line 457 in ChLcpIterativeMINRES.cpp, either alpha or beta compute a value of zero in the denominator.

This also occurs for at least one other example, test_2() in the same demo, and maybe more. One guess is that some part of the solver is under construction, and I might be getting ahead of myself.

lines 463 - 467:

  // alpha = (r' * Zr) / ((Zp)'*(MZp));
        double rZr = r.MatrDot(&r, &Zr);      // 1)  z'* Zr
        double ZpMZp = r.MatrDot(&Zp, &MZp);  // 2)  ZpMZp = (Zp)'*(MZp)

        double alpha = rZr / ZpMZp;

lines 498 - 502:

        // beta = (r' * N*r) / (r_old' * N*r_old);
        double numerator = r.MatrDot(&r, &Zr);            // 1)  r'* Z *r
        double denominator = r.MatrDot(&r_old, &Zr_old);  // 2)  r_old'* Z *r_old

        double beta = numerator / denominator;

Hi~ I download Chrono::PyEngine v.2.0.8 module for Python v.3.x 64bit. And i use python v3.3(64 bit).
There is a problem when i test this moudle with " import ChronoEngine_python_core " . It seems lack some DLL.

import ChronoEngine_python_core

Traceback (most recent call last):
File ".\ChronoEngine_python_core.py", line 14, in swig_import_helper
return importlib.import_module(mname)
File "D:\python3_3\lib\importlib_init_.py", line 88, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1577, in _gcd_import
File "", line 1558, in _find_and_load
File "", line 1525, in _find_and_load_unlocked
File "", line 586, in _check_name_wrapper
File "", line 497, in set_package_wrapper
File "", line 510, in set_loader_wrapper
File "", line 1130, in load_module
File "", line 313, in _call_with_frames_removed
ImportError: DLL load failed: 动态链接库(DLL)初始化例程失败。

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "", line 1, in
File ".\ChronoEngine_python_core.py", line 17, in
_ChronoEngine_python_core = swig_import_helper()
File ".\ChronoEngine_python_core.py", line 16, in swig_import_helper
return importlib.import_module('ChronoEngine_python_core')
File "D:\python3_3\lib\importlib_init.py", line 88, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
ImportError: DLL load failed: 动态链接库(DLL)初始化例程失败。

clang-format

I have added a base style configuration for clang-format. Once we settle on a desired style, would it be preferred that I reformat the entire source tree in one go, or should it be done piecewise?

Desired style

A comparison of the included styles is at: https://gist.github.com/andrewseidl/8066c18e97c40086c183

A list of available style options is at: http://clang.llvm.org/docs/ClangFormatStyleOptions.html

• @rserban and @andrewseidl prefer the Chromium style.
• @hmazhar requested lines longer than 80 chars.

Using clang-format

Installation

• Linux: included with clang
• OSX: using Homebrew, brew install clang-format
• Windows: see http://llvm.org/builds/

Editor support

• Eclipse: https://github.com/wangzw/cppstyle
• Emacs: http://clang.llvm.org/docs/ClangFormat.html
• SublimeText: https://github.com/rosshemsley/SublimeClangFormat
• Vim: https://github.com/rhysd/vim-clang-format
• Visual Studio: http://llvm.org/builds/
• Xcode: https://github.com/travisjeffery/ClangFormat-Xcode

I have also written a Git hook which will run clang-format on changed files when you commit. This should not be used: you should instead use the command-line tool or the integration with your editor.

Hi can we please get some documentation on setting up Chrono with OSX? I've managed to get Chrono::Engine and Irrlicht working but have become stuck with Parallel. I've tried using GCC instead of Clang and have attempted it through XCode and Unix makefiles but the compilation always crashes (the current problematic file seems to be real4.h).
Many thanks, Mark

• Include all relevant headers
• Package for Windows
• Check rpath settings
• Build RPMs for CentOS 6, 7
• Build DEBs for Ubuntu 14.04, 15.04

Except for vacuous setters, the chrono::ChLinkLock data members limit_Rp and limit_D (type = chrono::ChLinkLimit*) and are not used anywhere in the chrono code. The same applies to the chrono::ChLinkLimit data members penalty_only, polar, and rotation (type = int, but better as booleans).

Recommendation: Delete those unused data members. If a derived class has need for those members, declaring and defining those members should be a task for the author of that derived class.

Hi, I am trying to build the program SceneNetRGB-D, I have successfully installed chrono and irrlicht 1.8.2,
but when I try to compile SceneNet, I get problem like following:
/mntExt/DW/codes/scenenetrgb-d/scene_generator/scenenet_room_generator.cpp:23:50: fatal error: chrono/physics/ChContactContainerDEM.h: No such file or directory compilation terminated. make[2]: *** [CMakeFiles/scenenet_room_generator.dir/scenenet_room_generator.cpp.o] error 1 make[1]: *** [CMakeFiles/scenenet_room_generator.dir/all] error 2 make: *** [all] error 2
But I can't find a file container named "physics" in projectchrono, can someone help me?
Thank you.

My system is ubuntu 16.04 want to compile with python3.5 The cmakeList is below

and the irrlicht I have compile two like this

Did I have wrong setting in linux
Best regard

line 196 of demo_postprocess.cpp throws an error,

    mparticles->GetCollisionModel()->BuildModel();

Occurs during instantiation of ChParticlesClones, the ChModelBullet member mcontactable is set to 0 on line 181 of ChParticleClones.cpp:

    particle_collision_model = new ChModelBullet();
    particle_collision_model->SetContactable(0);

The result of calling GetPhysicItem() on the bullet collision model during BuildModel(), there is no mcontactable pointer to return the physics item.

The commented out check on line 84 of ChCModelBullet.cpp should be changed from

    // assert (GetPhysicsItem());

to

assert(mcontactable);

for catching this error.

My bare minimum for a quality C++ software library is that it must compile clean with -Wall using either a GNU or LLVM compiler. The chrono code fails to meet this minimal standard. With -Wall, I get several thousands of lines of warning messages. In fact, the chrono code does not compile clean even without -Wall.

I've created a bin for soil particles, and have a plate that is box shaped drop down to apply a weight to the surface of the soil particles. The plate is a tight fit into the box, and is slightly less wide than the extents of the box. However, it seems that the collision shape for the box is incorrect, and it looks like it is using the (slightly wider) AABB for the actual collision shape, causing the plate to get stuck when it collides with the top of the bin. I believe there is an error in the box collision detection somewhere.

You can find the code I used for this in the SBEL github, under the demo_soilbin project. It is the demo_sinkageTest.cpp that runs this test.

I built a stand-alone project using the CMake functions found here but I am still having some problems.

The biggest problem is that Irrlicht support is not included and must be re-done in my CMakeList.