Giter Club home page Giter Club logo

siconos / siconos Goto Github PK

View Code? Open in Web Editor NEW
156.0 22.0 27.0 242.36 MB

Simulation framework for nonsmooth dynamical systems

Home Page: https://nonsmooth.gricad-pages.univ-grenoble-alpes.fr/siconos/

License: Apache License 2.0

CMake 2.79% Shell 0.10% Batchfile 0.01% Python 8.19% C++ 41.75% C 45.52% GAMS 0.05% Nix 0.03% Dockerfile 0.15% SWIG 1.41%
nonsmooth-dynamical-systems complementarity-solvers simulation solvers optimization scientific-computing numerical-calculations variational-inequality bouncing-ball mcp

siconos's Introduction

Siconos

pipeline status Version License

A software package for the modeling and simulation of nonsmooth dynamical systems in C++ and in Python.

Siconos is an open-source scientific software primarily targeted at modeling and simulating nonsmooth dynamical systems:

  • Mechanical systems (rigid or solid) with unilateral contact and Coulomb friction and impact (Nonsmooth mechanics, contact dynamics, multibody systems dynamics or granular materials).
  • Switched Electrical Circuit such as electrical circuits with ideal and piecewise linear components: power converter, rectifier, Phase-Locked Loop (PLL) or Analog-to-Digital converter.
  • Sliding mode control systems.
  • Biology Gene regulatory networks.

Other applications are found in Systems and Control (hybrid systems, differential inclusions, optimal control with state constraints), Optimization (Complementarity systems and Variational inequalities), Fluid Mechanics, Computer Graphics, ...

Read more about Siconos at the Siconos homepage

Usage

Through your web browser

Perfect to understand and test the software or run lite simulations, demos, teaching ...

Prerequisite: a web browser and a network connection.

Pros: no installation prerequisites, nothing to do

Cons: limited resources. No long/important simulations.

Just click there Binder

Jupyter Lab environment with siconos ready to use and a set of end-user examples:

Prerequisite: Docker installed and usable on your computer.

To use last Siconos release, run the command line

docker run --rm -p 8888:8888 -ti gricad-registry.univ-grenoble-alpes.fr/nonsmooth/siconos-tutorials/siconoslab-master:latest

You will get something like

...
To access the server, open this file in a browser:
...
        http://127.0.0.1:8888/lab?token=b8a131ed7aed720c8fe1d7fae034cd2b669dcf686126c598

Copy this last line into your browser, and there you will be able to start a terminal or a notebook session.

You can also start a simple terminal to use Siconos through the command line with

docker run --rm --entrypoint /bin/bash  -ti gricad-registry.univ-grenoble-alpes.fr/nonsmooth/siconos-tutorials/siconoslab-master:latest

From source

Assuming you have cloned the project into , to build and install the libraries and the python interface ::

  • Create a user options file. Some templates are provided in /config_samples.
  • Run
cmake -S <path-to-siconos-sources> -B build-siconos -DUSER_OPTIONS_FILE=<your-options-file>
cmake --build build-siconos -j 4 # or the number of cores available on your computer.
ctest --test-dir build-siconos   # run tests, optional
cmake --install build-siconos

More details in Siconos download and install guide.

Main components

Each component can be used either from a low-level language like C/C++ or from Python.

siconos/numerics (C)

Collection of low-level algorithms for solving optimization problems arising in the simulation of nonsmooth dynamical systems:

  • Complementarity problems (LCP, MLCP, NCP)
  • Friction-contact problems (2D or 3D)
  • Second-order cone programming (SOCP)
  • Primal or Dual Relay problems
  • Finite dimensional Variational Inequality (AVI and VI)

siconos/kernel (C++)

Library for the modeling and simulation of nonsmooth dynamical systems.

  • Dynamical systems formalism: first order systems, Lagrangian and Newton-Euler formulations
  • Numerical integration techniques: Event-detecting (event-driven) and Event-Capturing (time-stepping) schemes
  • Nonsmooth laws: complementarity, Relay, normal cone inclusion, Friction Contact, Newton impact, multiple impact law.

siconos/mechanics (C++)

Component for the simulation of mechanical systems in interaction with their environment:

siconos/control (C++)

Library to add a controller to a simulation. For now almost all the implemented control schemes are based on sliding modes with an implicit discretization.

siconos/io (C++)

This component can be used to

  • serialize almost any simulation using boost::serialization
  • generate mechanical examples from HDF5 and to write HDF5 in view of visualization through vtk

License

Siconos is currently distributed under Apache Licenses (v2).

The archetypal example: "The bouncing ball"

from siconos.kernel import LagrangianLinearTIDS, NewtonImpactNSL,\
LagrangianLinearTIR, Interaction, NonSmoothDynamicalSystem, MoreauJeanOSI,\
TimeDiscretisation, LCP, TimeStepping
from numpy import eye, empty

t0 = 0       # start time
T = 10       # end time
h = 0.005    # time step
r = 0.1      # ball radius
g = 9.81     # gravity
m = 1        # ball mass
e = 0.9      # restitution coeficient
theta = 0.5  # theta scheme

# the dynamical system
x = [1, 0, 0]    # initial position
v = [0, 0, 0]    # initial velocity
mass = eye(3)  # mass matrix
mass[2, 2] = 2. / 5 * r * r
ball = LagrangianLinearTIDS(x, v, mass)
weight = [-m * g, 0, 0] 
ball.setFExtPtr(weight) #set external forces
# Interaction ball-floor
H = [[1, 0, 0]]
nslaw = NewtonImpactNSL(e)
relation = LagrangianLinearTIR(H)
inter = Interaction(nslaw, relation)
# Model
bouncingBall = NonSmoothDynamicalSystem(t0, T)
# add the dynamical system to the non smooth dynamical system
bouncingBall.insertDynamicalSystem(ball)
# link the interaction and the dynamical system
bouncingBall.link(inter, ball)
# Simulation
# (1) OneStepIntegrators
OSI = MoreauJeanOSI(theta)
# (2) Time discretisation 
t = TimeDiscretisation(t0, h)
# (3) one step non smooth problem
osnspb = LCP()
# (4) Simulation setup with (1) (2) (3)
s = TimeStepping(bouncingBall, t, OSI, osnspb)
# end of model definition

# computation
N = (T - t0) / h # the number of time steps
# time loop
while s.hasNextEvent():
    s.computeOneStep()
    s.nextStep()

siconos's People

Contributors

armandxlim avatar batzkass avatar bremond avatar fperignon avatar moleculext avatar octave-user avatar pierrebricewieber avatar pissard avatar radarsat1 avatar shaxov avatar vacary avatar xhub avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

siconos's Issues

[Kernel] fix bad casting in OneStepNSProblem::getOSIMatrix

This line of code

block = (std11::static_pointer_cast (Osi))->W(ds); // get its W matrix ( pointer link!)

is also executed for SchatzmanPaoliOSI, which is not based on MoreauJeanOSI.

The real fix is to remove the W matrix from the OSI and put it in the graph.

[cmake] add a WITH_FORTRAN option

motivations:

  • not all platform have a fortran compiler easily available (Windows, Mac OS X)
  • not all build system support fortran (Ninja, VS, ...)

We would loose at least:

  • ql0001
  • odepack
  • hem5

Todo:

  • add a cmake option WITH_FORTRAN
  • and a bunch of "if defined(WITH_FORTRAN) ... else ... endif" in
    • LsodarOSI.{h,c}pp
    • Hem5OSI.{h,c}pp
    • lcp_nsqp.c, lcp_qp.c

Optional:

  • add sundials (CVODE) to have a good event-driven integrator even if WITH_FORTRAN=NO

[io][mechanics] visualization of the initial state in siconos_vview

It is not possible to visualize the initial position in scions_vview. It need to simulate at least one to visualize the scene after this first step.

It seems also that the initial condition are taken into account in mechanics_io in the same for all the objects dynamic/static Convec shape/Primitive.

Boost Log

Would it be interesting to use Boost log for a smart logging system ?

However, it seems that compilation with Boost log is not trivial.

To be discussed

[CI] add pkg to ci_config

for some config, a particular package must be installed, otherwise the build will fail at the configure phase, The two have to be synchronize. It would be better if both information are in the same data structure.

[Kernel] Do not selfthrow if Lsodar fails

If Lsodar fails to integrate at one point, we just selfthrow and leave the poor user in the dark.
We should at least print the current state. A way to abort the simulation but still save simulation data somehow would be good.

LGPL code in externals/tools/f2c.h

This files is included in

  • many files in externals/netlib/dctemplates/ this is not an issue since we release this part under the LGPL
  • io/src/SiconosFull.hpp
  • kernel/src/SiconosFwd.hpp
  • kernel/src/simulationTools/EventDriven.hpp
  • kernel/src/simulationTools/LsodarOSI.hpp

It is included in SiconosFortran.h, which is itself included in

  • hairer.h
  • odepack.h
  • QP_Solvers.h

and so on, so forth.

Note that there are 5 (yikes) f2c.h files in the siconos repository:
./externals/netlib/dctemplates/F2CLIBS/libF77/f2c.h
./externals/netlib/dctemplates/F2CLIBS/libI77/f2c.h
./externals/netlib/dctemplates/F2CLIBS/f2c.h
./externals/netlib/dctemplates/f2c.h
./externals/tools/f2c.h

[Mechanics] warning generated by swig

/home/xhub/siconos/mechanics/src/bodies/Disk.hpp:0: Warning 402: Base class 'CircularDS' is incomplete.
/home/xhub/siconos/kernel/src/utils/SiconosTools/SiconosVisitor.hpp:155: Warning 402: Only forward declaration 'CircularDS' was found.
/home/xhub/siconos/mechanics/src/bodies/Circle.hpp:0: Warning 402: Base class 'CircularDS' is incomplete.
/home/xhub/siconos/kernel/src/utils/SiconosTools/SiconosVisitor.hpp:155: Warning 402: Only forward declaration 'CircularDS' was found.
/home/xhub/siconos/mechanics/src/bodies/DiskDiskR.hpp:0: Warning 402: Base class 'CircularR' is incomplete.
/home/xhub/siconos/kernel/src/utils/SiconosTools/SiconosVisitor.hpp:155: Warning 402: Only forward declaration 'CircularR' was found.
/home/xhub/siconos/mechanics/src/bodies/DiskDiskR.hpp:0: Warning 514: Director base class DiskDiskR has no virtual destructor

proposing a new mechanics API

This will take a bit of explaining, but it comes from discussions with @vacary and @bremond, and is related to the integration of Siconos with Gazebo. It's a little early to show this, it is very far from done and not even ready to put on master branch, but I would like to hear comments from the team on the approach before I make too much progress.

For a brief explanation, please see the comments of 4eee836 and changes of my branch mechanics-proposed

Here is a run-down. As discussed with @bremond, some goals are,

  • Remove references to Bullet classes in user code. Make it easier to switch collision back-ends. No more BulletDS.
  • Detach definition of bodies from their shapes. No more SphereDS, etc.

Additionally, the API should make it easy to describe scenes and instantiate objects corresponding to user software objects such as the Link/Collision/Shape distinction in Gazebo, both in C++ and in Python.

Personally I additionally wanted to avoid any unnecessary up/down-casting, which was quite difficult to achieve with an extended hierarchy like Shape→Sphere→BulletSphere, etc. This approach was viable, using a "factory" to generate Bullet-specific objects, but passing the pointers to the DS unavoidably required some casting. This is not just aesthetic — I want it to be impossible at compile time to pass a Bullet object to an ODE back-end, for example.

The solution I have converged on is to treat the scene description as an abstraction, and to have the Bullet-specific code "implement" this description. In testContact.cpp, you can see that one creates a scene,

SP::BodyDS body(new BodyDS());
SP::Contactor contactor(new Contactor());
SP::SiconosSphere sphere(new SiconosSphere(1,2,3,1.0));
contactor->addShape(sphere);
body->setContactor(contactor);

and then a particular broadphase implementation takes this scene as input:

SP::BulletBroadphase broadphase(new BulletBroadphase());
broadphase->buildGraph(contactor);

Here, SP::BulletBroadphase could be switched for another implementation of the SP::SiconosBroadphase interface.

The visitor framework turned out to be very useful for this, since the appropriate SiconosSphere or SiconosBox visitor is called, alleviating any need for casting.

Behind the scenes, buildGraph() traverses the scene (it will need to take a different argument eventually, probably the Model), and produces a set of btCollisionObject/btCollisionShape objects that reproduce the scene. This is then used in,

broadphase->performBroadphase();

which should produce indexSet1.

So, the only complicated part is that the scene may be updated; for instance, one might change the radius of a SiconosSphere after buildGraph() has been called. How to maintain these updates?

My solution thus far — and I'm definitely open to ideas here — is to have each shape contain a handler that is called any time an object's properties are changed. This handler is installed by the broadphase implementation during buildGraph(), and is an object that may contain extra broadphase-specific code and data. For now, it simply puts the objects on a "dirty" list, but it can be used to update the associated btSphereShape for example. Or, a single handler could be used for all objects that contains a hash table associating Bullet and Siconos objects. Different approaches are possible.

The important thing is that all Bullet-specific code is very well separated, and could be easily switched for a different collision engine. Meanwhile, the SiconosSphere/SiconosBox etc classes can be expanded to include a set of object types we desire to support — this could be based on SDF / URDF for example, but could also perhaps include 2D objects for a different back-end. The back-end is free to not support certain objects, and will only fail if it encounters an object it does not implement.

Things I'm not sure of:

  • whether the Contactor class is really needed, it only maintains a list of shapes.
  • whether joints need to be considered here. Perhaps they are just Relations between BodyDS and can be ignored with regards to the collision engine interface.
  • whether Contactor/SiconosShape instance can be shared between many DSs. This could be useful for particle models, but at the moment the handler is assumed to be instantiated for each object. Alternatively it could be shared.

I'm interested to hear your comments. I'll close this issue when the branch is either merged (not necessarily finished!) or decided not to merge.

[cmake] RPATH Stuff and MACOSX

Using RPATH stuff is now mandatory on MACOSX. In SiconosSetup.cmake, there is some lines about RPATH for the linking of library. I do not know how it works but there is not path in the resulting build library.

In a brute force way, I added following the recommendation in https://cmake.org/Wiki/CMake_RPATH_handling

 if(APPLE)
   set(CMAKE_MACOSX_RPATH ON)
   # use, i.e. don't skip the full RPATH for the build tree
   SET(CMAKE_SKIP_BUILD_RPATH  FALSE)

   # when building, don't use the install RPATH already
   # (but later on when installing)
   SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE) 

   SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")

   # add the automatically determined parts of the RPATH
   # which point to directories outside the build tree to the install RPATH
   SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)


   # the RPATH to be used when installing, but only if it's not a system directory
   LIST(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "${CMAKE_INSTALL_PREFIX}/lib" isSystemDir)
   IF("${isSystemDir}" STREQUAL "-1")
     SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
   ENDIF("${isSystemDir}" STREQUAL "-1")
 endif(APPLE)

But it doesn't work ...

[numerics] support NM_SPARSE matrices in fc3d solvers

As per @vacary 's request, I've added fc3d_sparse_test.c aka FC3D_sparse_test, a test that tries to solve a dummy fc3d problem with a sparse matrix. I'm raising that issue because I tried to solve fc3d from python that came from a reduction of a gfc3d problem and it failed for a few solvers.

We can discuss the list of solver to test (that is that should have that feature).

I'm only one test for all solvers since we already have too many binaries and tests.

Also if we decide that a solver should not support this kind of solver, it should return an error, not quit like now. Python does not really like that ...

[kernel] divergence of Newton iterations for NewtonEulerDS

Following (13531b7), see commit log, the convergence of the Newton loop is bad and some examples fails on a few time-steps.

This is mainly due inconsistent update of the operator T inside the DS and the use in various places in the code.

I have previously circumvented this problem by using T(sold) in every place. It is no longer possible in the new version which is nevertheless cleaner.

LGPL code in io/swig/io/

The python scripts io/swig/io/renderer.py and io/swig/io/SimpleGui.py are taken from pythonOCC.
They are under the LGPL license.

[mechanics][contact detection] How to control the contact detection of bullet

I use the following example to simulate few cubes into an hopper (b396508)

I have to question about the control of the contact detection of Bullet
1 - Is it possible to adjust for Scions/Mechanics the alert distance that creates a contact point between objects?
2- Is it possible to change or to control the spatial distribution of contact points between two surfaces ?

Build errors related to "ONLY mechanics"

I get build errors on current master (15102fc) related to stuff in FreeCAD, despite the following disabled items in my options file:

$ grep -e FREE -e OCC -e MEC myoptions.cmake 
option(WITH_OCC "compilation with OpenCascade Bindings. Default = OFF" OFF)
option(WITH_FREECAD "Use FreeCAD. Default = OFF" OFF)
option(WITH_MECHANISMS "Generation of bindings for Saladyn Mechanisms toolbox. Default = OFF" OFF)

The errors are,

Linking CXX executable testMultiBody
../../../../libsiconos_mechanics.so.3.9.0: undefined reference to `BRepBuilderAPI_MakeEdge::IsDone() const'
../../../../libsiconos_mechanics.so.3.9.0: undefined reference to `BRepAdaptor_HSurface::BRepAdaptor_HSurface(BRepAdaptor_Surface const&)'
../../../../libsiconos_mechanics.so.3.9.0: undefined reference to `Extrema_SequenceOfPOnSurf::Clear()'
../../../../libsiconos_mechanics.so.3.9.0: undefined reference to `GeomAdaptor_Surface::NbVPoles() const'

etc...

I've tracked it down to the following changes in e0b39b0,

diff --git a/cmake/siconos_find_common_dep.cmake b/cmake/siconos_find_common_dep.cmake
index 39ad1ea..e768547 100644
--- a/cmake/siconos_find_common_dep.cmake
+++ b/cmake/siconos_find_common_dep.cmake
@@ -84,7 +84,7 @@ ENDIF(WITH_BULLET)
 # --- OCC ---
 IF(WITH_OCC)
   if(NOT WITH_MECHANISMS)
-    COMPILE_WITH(OCE 0.15 REQUIRED ONLY mechanics)
+    COMPILE_WITH(OCE 0.15 REQUIRED)
     SET(HAVE_OCC TRUE)
     LIST(REMOVE_ITEM SICONOS_LINK_LIBRARIES DRAWEXE)
   endif()
@@ -95,7 +95,7 @@ IF(WITH_MECHANISMS)
   SET(OCE_TOOLKITS "TKernel"  "TKMath" "TKService" "TKV3d"  "TKBRep" "TKIGES" "TKSTL" "TKVRML" "TKSTEP" "TKSTEPAttr" "TKSTEP209" "TKSTEPBase" "TKShapeSchema" "TKGeomBase" "TKGeomAlgo" "TKG3d" "TKG2d" "TKXSBase" "TKPShape" "TKShHealing" "TKHLR" "TKTopAlgo" "TKMesh" "TKPrim" "TKCDF" "TKBool" "TKBO" "TKFillet" "TKOffset")

   message(STATUS "Searching for OCE ....")
-  compile_with(OCE COMPONENTS ${OCE_TOOLKITS} ONLY mechanics)
+  compile_with(OCE COMPONENTS ${OCE_TOOLKITS})
   LIST(REMOVE_ITEM SICONOS_LINK_LIBRARIES DRAWEXE)

   if(OCE_FOUND)

That is to say, if I apply this diff, reverting just these changes from e0b39b0, then I can build successfully.

LGPL code in kernel/src/utils/SiconosAlgebra/cholesky.hpp

This is used to provide a factorisation method for sparse matrices in SimpleMatrix::PLUFactorizationInPlace

The best course of action is to remove that code and replace it by something that also works for unsymmetric matrix.

We are already developing a nice wrapper around multiple LU library in numerics. We should leverage that and use it also in the kernel. Otherwise we are maintaining 2 linear algebra front-end in the same software. And I don't think it makes sense.

[Numerics] Linear System (LS) solver category

There is an LS Solver category in Numerics. Even though solver for Linear System is an important topic, it is far beyond the scope of Numerics.
It is basically a wrapper around LAPACK solver, with the same infrastructure as other categories of solvers.
The whole setup serves only one purpose: to have a consistent interface in GMP, which is nice, but it does not require to have its own category and to be displayed on the front page of Numerics. It should be rather hidden in tools or in GMP.

[numerics] FischerBurmeisterGenerated.c error: non-floating-point argument in call to function ‘__builtin_isfinite’

With the latest glibc as used by the latest ubuntu, the build fails cf

https://launchpadlibrarian.net/249608951/buildlog_ubuntu-xenial-amd64.siconos_3.9~alpha-0~4907~ubuntu16.04.1_BUILDING.txt.gz

The problem seems to be that we want to check the finiteness of an integer variable. For instance in FischerBurmeisterGenerated.c, x37 is an int and we have x37=x21 <= ZERO; POST_CHECK(x37);

By the way, shouldn't those variables be booleans?

[CI] add a config for OCE

no config currently builds wiith OCE. There is some data in CI/config/siconos.yml that indicate that it was worked on. Is there any major blocker.

If it is tested on CI, then errors could show up on the CDash

[Kernel] remove dead code

The functions in the following files appear to be use nowhere and has seen few updates in the last years. Therefore I think they could be consider for removal or move to some ``old'' directory. All the following files/classes are in the Kernel.

  • DynamicalSystemFactory
  • RelationFactory
  • utils/contract/check.hpp
  • SiconosSet
  • Cmp

Possible removal (no use of functionalities)

  • swapInMemory in DS ?

If you know more and especially why we should keep something or if you agree that some are effectively unused, raise your voice!

[Windows] add NSIS installer

NSIS has some scripting capabilities that could be leverage to provide a nice NSIS installer for Siconos with some dependencies "automatically" installed, like the MSVC C++ redistribuable kit.

Freecad seems to be using this technique and we could use their NSIS-related file as templates.

[kernel] remove DynamicalSystemsSet in OneStepIntegrator

The DynamicalSystemsSet is no longer use in

  • MoreauJeanOSI
  • EulerMoreauOSI

The remaining OSI have to treated as well:

  • MoreauJeanCombinedProjectionOSI
  • MoreauJeanDirectProjectionOSI
  • D1MinusLinearOSI
  • D1MinusLinearOSIHalfExplicitAccelerationLevelOSI
  • D1MinusLinearOSIHalfExplicitVelocityLevelOSI
  • NewMarkAlphaOSI
  • Hem5OSI
  • SchatzmanPaoliOSI
  • LsodarOSI
  • ZeroOrderHoldOSI

Normally, it should be file by file without side effect ...

The implementation of a subgraph has to be designed.

siconos-mechanisms.py does not find mechanics_io module

Hi,

Following the renaming and the new installation process, the siconos-mechanisms.py is buggy

In particular, the module siconos.mechanics.IO does not exist and siconos.mechanics.io
Traceback (most recent call last):
File "/usr/local/bin/siconos-mechanisms.py", line 24, in
from siconos.mechanics import IO
ImportError: cannot import name IO

It exists a new file mechanics_io but it is not install with the following options:

option(WITH_DOCUMENTATION "Build Documentation. Default = OFF" OFF)
option(WITH_PYTHON_WRAPPER "Build python bindings using swig. Default = ON" ON)
option(WITH_DOXYGEN_WARNINGS "Explore doxygen warnings. Default = OFF" OFF)
option(WITH_DOXY2SWIG "Build swig docstrings from doxygen xml output. Default = OFF." OFF)
option(WITH_SYSTEM_INFO "Verbose mode to get some system/arch details. Default = OFF." OFF)
option(WITH_TESTING "Enable 'make test' target" OFF)
option(WITH_GIT "Consider sources are under GIT" OFF)
option(WITH_SERIALIZATION "Compilation of serialization functions. Default = OFF" ON)
option(WITH_GENERATION "Generation of serialization functions with gccxml. Default = OFF" OFF)
option(WITH_CXX "Enable CXX compiler for numerics. Default = ON" ON)
option(WITH_UNSTABLE "Enable this to include all 'unstable' sources. Default=OFF" OFF)
option(BUILD_SHARED_LIBS "Building of shared libraries. Default = ON" ON)
option(DEV_MODE "Compilation flags setup for developpers. Default = OFF" OFF)
option(WITH_BULLET "compilation with Bullet Bindings. Default = OFF" OFF)
option(WITH_OCC "compilation with OpenCascade Bindings. Default = OFF" OFF)
option(WITH_MUMPS "Compilation with MUMPS solver. Default = OFF" OFF)
option(WITH_FCLIB "link with fclib when this mode is enable. Default = OFF" ON)
option(WITH_FREECAD "Use FreeCAD. Default = OFF" OFF)
option(WITH_MECHANISMS "Generation of bindings for Saladyn Mechanisms toolbox. Default = OFF" ON)
option(WITH_XML "Enable xml files i/o. Default = ON" ON)
option(WITH_DOCKER "Build inside a docker container. Default = OFF" OFF)

set(siconos_python_install "standard" CACHE STRING "Install mode for siconos python package")

set(COMPONENTS externals numerics kernel control mechanics io CACHE INTERNAL "List of siconos components to build and install")

[cmake] add options to enforce license

We have some code that cannot be distributed as GPL or Apache v2, like MA28 in HEM5. To facilitate the distribution, I propose to add 2 cmake options

  • ENSURE_GPL to guarantee that the resulting binary is GPL-compatible
  • ENSURE_APACHE to guarantee that the resulting binary is compatible with this license. This would for instance ensure that WITH_UMFPACK is disable.

Code that should be disable in both cases:

  • HEM5

Apache:

  • UMFPACK
  • FCLIB (if the license does not change to LGPL)

WITH_CXX or not WITH_CXX

A short issue (since Vincent likes this) : at the time, the option WITH_CXX=OFF does not work.
The idea is to compile externals+numerics only in C, which may be useful for specific env where only C compiler is available.
The question is : Is it really worth it to make it work?

[example] BulletBouncingBoxDynamic.py segfaults

Looks similar to the issue fixed in 83ce528

==28140==ERROR: AddressSanitizer: SEGV on unknown address 0x7fc453000053 (pc 0x7fc431d7d627 sp 0x7ffe34e177d0 bp 0x000000f16b40 T0)
#0 0x7fc431d7d626 in btCollisionWorld::~btCollisionWorld() (/usr/lib64/libBulletCollision.so.2.83+0x6f626)
#1 0x7fc431d7d6b8 in btCollisionWorld::~btCollisionWorld() (/usr/lib64/libBulletCollision.so.2.83+0x6f6b8)
#2 0x7fc4179ba28b in void boost::checked_delete(btCollisionWorld_) /usr/include/boost/core/checked_delete.hpp:34
#3 0x7fc4179c762e in boost::detail::sp_counted_impl_p::dispose() /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp:78
#4 0x7fc4179180bd in boost::detail::sp_counted_base::release() /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146
#5 0x7fc417918304 in boost::detail::shared_count::~shared_count() /usr/include/boost/smart_ptr/detail/shared_count.hpp:443
#6 0x7fc41795e0ff in boost::shared_ptr::~shared_ptr() /usr/include/boost/smart_ptr/shared_ptr.hpp:323
#7 0x7fc417962edd in BulletSpaceFilter::~BulletSpaceFilter() /home/xhub/siconos/mechanics/src/contactDetection/bullet/BulletSpaceFilter.hpp:26
#8 0x7fc417962fab in BulletSpaceFilter::~BulletSpaceFilter() /home/xhub/siconos/mechanics/src/contactDetection/bullet/BulletSpaceFilter.hpp:26
#9 0x7fc4179be577 in void boost::checked_delete(BulletSpaceFilter_) /usr/include/boost/core/checked_delete.hpp:34
#10 0x7fc4179c612e in boost::detail::sp_counted_impl_p::dispose() /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp:78
#11 0x7fc4179180bd in boost::detail::sp_counted_base::release() /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146
#12 0x7fc417918304 in boost::detail::shared_count::~shared_count() /usr/include/boost/smart_ptr/detail/shared_count.hpp:443
#13 0x7fc41791a2c7 in boost::shared_ptr::~shared_ptr() /usr/include/boost/smart_ptr/shared_ptr.hpp:323
#14 0x7fc4178fbfa5 in _wrap_delete_BulletSpaceFilter /build/siconos/wrap/siconos/mechanics/contact_detection/bulletPYTHON_wrap.cxx:115918
#15 0x7fc4385762a2 in PyObject_Call (/usr/lib64/libpython2.7.so.1.0+0x4c2a2)
#16 0x7fc438576b33 in PyObject_CallFunctionObjArgs (/usr/lib64/libpython2.7.so.1.0+0x4cb33)
#17 0x7fc417668c9f in SwigPyObject_dealloc /build/siconos/wrap/siconos/mechanics/contact_detection/bulletPYTHON_wrap.cxx:1721
#18 0x7fc4385ac49a (/usr/lib64/libpython2.7.so.1.0+0x8249a)
#19 0x7fc4385c8363 (/usr/lib64/libpython2.7.so.1.0+0x9e363)
#20 0x7fc4385ab53e (/usr/lib64/libpython2.7.so.1.0+0x8153e)
#21 0x7fc4385acfaf (/usr/lib64/libpython2.7.so.1.0+0x82faf)
#22 0x7fc4385b190b in _PyModule_Clear (/usr/lib64/libpython2.7.so.1.0+0x8790b)
#23 0x7fc438621dfa in PyImport_Cleanup (/usr/lib64/libpython2.7.so.1.0+0xf7dfa)
#24 0x7fc43862d82d in Py_Finalize (/usr/lib64/libpython2.7.so.1.0+0x10382d)
#25 0x7fc43863ee43 in Py_Main (/usr/lib64/libpython2.7.so.1.0+0x114e43)
#26 0x7fc437f8c6df in __libc_start_main (/lib64/libc.so.6+0x206df)
#27 0x400758 in _start (/usr/bin/python2.7+0x400758)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 btCollisionWorld::~btCollisionWorld()
==28140==ABORTING
/build/siconos/scripts/siconos: /home/xhub/siconos/examples/Mechanics/ContactDetection/BulletBouncingBox/BulletBouncingBoxDynamic.py failed, Command '['python', '/home/xhub/siconos/examples/Mechanics/ContactDetection/BulletBouncingBox/BulletBouncingBoxDynamic.py']' returned non-zero exit status 1

[Kernel] remove weak_ptr link from Simulation to Model

A Simulation object should not have a weak_ptr to the Model.

A quick look at the code show that the Model is needed for 2 reasons:

  • getting access to the topology. We can directly put a SP to the Topology.
  • setting and getting time from the Model. My understanding is that the reference for the current/next time is the EventManager. The only usage I've spotted to get the current time through the following calls: simulationLink->model()->currentTime(). Hence, I think a method of Simulation can directly get this info.

Is this analysis correct or did I miss something?

document siconos.mechanics interface

There are many examples in examples/Mechanics/ContactDetection/BulletIO that could be interesting to put in the documentation (and it would be good also to document how the simulation in running in those)

Build failed due to #define Float float in PATH_SDK

The compilation of BulletTimeStepping.cpp fails due a side effect between boost and PATH_SDK.

[81%] Building CXX object mechanics/CMakeFiles/mechanics.dir/src/contactDetection/bullet/BulletTimeStepping.cpp.o
In file included from /Users/acary/siconos/mechanics/src/contactDetection/bullet/BulletTimeStepping.cpp:48:
In file included from /Users/acary/siconos/kernel/src/modelingTools/NonSmoothDynamicalSystem.hpp:27:
In file included from /Users/acary/siconos/kernel/src/simulationTools/Topology.hpp:28:
In file included from /Users/acary/siconos/kernel/src/simulationTools/SimulationGraphs.hpp:27:
In file included from /Users/acary/siconos/kernel/src/utils/SiconosTools/SiconosGraph.hpp:56:
In file included from /opt/local/include/boost/graph/graph_utility.hpp:31:
In file included from /opt/local/include/boost/pending/container_traits.hpp:23:
In file included from /opt/local/include/boost/unordered_set.hpp:17:
In file included from /opt/local/include/boost/unordered/unordered_set.hpp:21:
In file included from /opt/local/include/boost/functional/hash.hpp:6:
In file included from /opt/local/include/boost/functional/hash/hash.hpp:21:
In file included from /opt/local/include/boost/functional/hash/detail/hash_float.hpp:14:
/opt/local/include/boost/functional/hash/detail/float_functions.hpp:78:28: error: expected a qualified name after 'typename'
template
^
/Users/acary/siconos/externals/PATH_SDK/include/Types.h:24:18: note: expanded from macro 'Float'

define Float float

             ^

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.