[Matthieu Nesme]

Hi,

have a look to the Compliant plugin and its python API (StructuralAPI).

The example sofa/applications/plugins/Compliant/examples/bielle_manivelle/structuralAPI.py shows how to build such a system.

— Matthieu

[Matthieu Nesme]

Sorry for my late answer, but I guess the problem has nothing to do with the masks.
And I would recommend you to use the masks!

It comes from which compilation variables where defined while compiling SOFA and which one are defined when including sofa headers in your external application.

By default SOFA_USE_MASK is defined while compiling sofa, so every header files with #ifdef SOFA_USE_MASK will do some specific stuff, if you do not define the SOFA_USE_MASK variable before including the header, it cannot work.

Of course this is true for any compiler variables.
There are several possibilities to make it transparent for someone who want to use SOFA as an external library, and we have to put something in place.

[Matthieu Nesme]

Hi,

you should also have a look to the Compliant Plugin where I did implement a non-linear solver CompliantNLImplicitSolver.
Note that the implementation itself is crappy (playing with both flat vectors and graph-scattered multi-vec is not elegant and I did not clean anything).
But it can inspire you.

I would also be interested in such an integrator, please let me know if you do implement it!

Matthieu

[Matthieu Nesme]

Hi,

projective constraints can only be applied on independent dofs while Lagrange Multipliers based constraints can be applied to any dofs (even mapped ones).

Projective constraints are way cheaper (almost free) compared to LM that increases the system size. They also are generally numerically more stable but can only represent a limited range of constraints (representable by a projection matrix, constant for a time step). In my knowledge, they were first introduced in http://dl.acm.org/citation.cfm?id=280821 sec 5.3.

projectPosition and projectVelocity are called at the end of the time step to project the current state in the feasible space.
projectResponse implements P*dx (with P the projection matrix and dx is relative to a position variation = position difference, velocity, acceleration…) Used for iterative, non-assembled solvers.
projectJacobianMatrix implements P*J where J is a matrix. I guess it is used in the core LM constraint solver, but has to be checked!
projectMatrix is, for now, used as a way to get the projection matrix from several projective constraints (by doing the first call with the identity matrix). It is used in the Compliant plugin (another LM solver implementation).

Implementing a floor as a projective constraint is not a good idea as it would only be a post-treatment. Nothing would prevent a particle to penetrate the floor during the solve.
The idea would be to move the violated particles in projectPosition, and to adjust their velocity in projectVelocity (inelastic or elastic contacts).
The particles should stay free to move and the projection matrix should be the identity matrix (ie projectResponse does not do anything).

While clean unilateral constraints would prevent a particle to penetrate the floor during the solve but it would be way more costly.

A third way is to use penalities (see PlaneForceField). Note that penalities could be mixed with the projective constraint (used here as a kind of post-stabilization).

I hope this helps.

Matthieu

[Matthieu Nesme]

Hi,

the most efficient is to use subsetmultimappings.
Warning, multimappings cannot be cleanly created in an xml scene.

Your exact situation is in several examples:
c++ scene: tutorial/compositeObject
python scene: SofaPython/compositeObject.py

Otherwise you can always use regular hard, bilateral constraints.

– Matthieu

[Matthieu Nesme]

Hi,

Indeed stiff elasticity is more challenging to simulate.
The condition number of the implicit system increases as the stiffness increases.
I guess you are using an iterative solver (such as the conjugate gradient) that will require more iterations to converge (and so will be slower). If the solution is not accurate enough, it can result in absence of gravity.
A direct solver (such as Cholesky decompositions) is less sensitive to numerical difficulties but can still have trouble with too stiff systems.
If you need to simulate stiff materials, have a look to our recent publication on the topic: https://hal.inria.fr/hal-01157835

Best,
Matthieu

[Matthieu Nesme]

Hi there,

what you want to do is to simulate plasticity.
It is possible with the “Flexible” plugin (maybe there are other implementations I am not aware of).
Have a look to the example Sofa/applications/plugins/Flexible/examples/strain/plastic.scn.
If you need more specific parameters to set up the plasticity, you will need to implement your own “PlasticStrainMapping”.

[Author]

Posts