[Hugo]

Hi @twxu

Indeed, on your image “example2.PNG” or “exampleContactLines.PNG”, the number of contact points seems huge several hundreds maybe thousands of them. It is a lot! Really a lot!

The solution would be to definitely coarsen your collision model.

Best,

Hugo

[Hugo]

Hi @timp

NaN could explain it or wrong pointer, but it is weird.
Could you please share with me the full scene (in PM if you prefer) so that I can investigate this?

An usual way to investigate would be to compile in debug and see the trace.

Best,

Hugo

[Hugo]

Hi @eaparra

Thank you for your question and thank you for providing the scene files, it helps a lot!

In mechanics, the cantilever beam is a well-known example. Usually, the mass at the end is modeled as a force (F = mg) applied at the extremity of the beam. Do you really need to model the full mass object at the extremity or a force would do it?

Your scene using the projective AttachConstraint works well.

The case of a coupling using the BilateralInteractionConstraint can not work. BilateralInteractionConstraint belongs to the constraints solved using the Lagrange multiplier approach. It therefore requires the two step resolution (free + correction motion) implemented in the FreeMotionAnimationLoop with a ConstraintSolver.

I plan to write a doc page about it in the coming days, your post just motivates me more.

I hope this helps.
Best

Hugo

PS: We try to answer as quickly as possible on the forum, but do no worry: we notice each one of your posts here. Just be comprehensive, technical support is free, it is not our only task and our manpower remains limited. We are in the process of providing a closer and more robust support for the community.
Anyway, feel free to get involved as well or ask your institution to support us to get more manpower on the open-source!

[Hugo]

Hey @mckysd5

Even if slow, is the collision well responding?
How many contacts can you see (activate the view option “Interactions”)?

Are your object in collision at the beginning of the simulation?
This must not be the case (in any simulation software).

Are your meshes clean? (no duplicated faces)

Are your collision settings (alarmContact / alarmDistance) properly set regarding the object size / your tolerance?

Could you share a simple scene creating the problem?
Could you post the full warning info you get?

Best wishes,

Hugo

[Hugo]

Hey @olumide

Note that for each animation loop the graph traversal and its order are different. This is why this path the visitors is only described in the animation loop component pages (e.g. DefaultAnimationLoop see the flow diagram).

Non-linear FEA (involving non-linear materials as SOFA does) is always brought back to a linearized system to be solved. Only, several Newton steps will be required to compute it.

Sorry for the colliding time schedule of the dev meeting. Anyway, feel free to subscribe to the dev-mailing list to get all the dev reports.

Best

Hugo

[Hugo]

Hi @amazier

Did you well compiled the plugin using GCC ?

Best

Hugo

[Hugo]

Hey @anoushs

Have you noticed that with BoxROI you can define both the “box” data field or the “orientedBox” data field?
This should do the job as you expect.

Best

Hugo

[Hugo]

Hey @jonny

Let’s ask @GuillaumeParan our release expert. Do you have any idea Guillaume? Maybe related to the changes to be backported?

Best,

Hugo

[Hugo]

Hi @andrija987 @pasquale94

Thank you for your feedback.

@andrija987, right ! GH discussions could help a bit for the forum management with new features, but more importantly: it would better (and quicker) connect the community and, as you stated, it would foster the emergence of novel ideas (future implementations).

We are currently increasing our efforts on the forum and this will go crescendo!

We should take a decision this week, anyone please feel free to give your opinion!

Best wishes,

The SOFA Consortium

[Hugo]

Hey @nguyenvanpho

Have you installed pybind11 as requested in the doc?
Best

Hugo

[Hugo]

Let me notice @olivier-goury author of the code 😉

Hugo

[Hugo]

AttachConstraint is a projective constraint.

Further to your request, I just wrote this doc page (the visual bug in the doc will soon be fixed).

I hope this helps.
Best

Hugo

[Hugo]

Dear @anoushs

Are the faces of your meshes coherent (same number of point and same location of each point) ? If so, you could set on each face Bilateral constraint (if you use a FreeMotionAnimationLoop = solving constraint using the Lagrange multipliers) or AttachConstraint.

If each mesh is different (different resolution), then it will be difficult.

An alternative: you could define your object as one single object and define heterogeneous values of the stiffness. Which mechanical constitutive law are you using? TetrahedronFEMForceField right ? If so, you can define a global “youngModulus” and then define a factor per tetrahedron (vector “localStiffnessFactor”).

Best wishes,

Hugo

[Hugo]

Hi @twxu

Could you please create a simplified scene (without plugins if possible) that I could run and test?
I found some scene bu none of them are working.

Best,

Hugo

[Hugo]

Hi @yupeng

After investigation, my advice was wrong. In SOFA, only the TetrahedronDiscreteIntersection implements the discrete collision between a TetrahedonCollisionModel and any other model. I did not know this. Your there need to use TetrahedronDiscreteIntersection.

As you noticed, when using it in a scene, you receive:

[ERROR]   [InfoComponent(Not created (TetrahedronDiscreteIntersection))] Object type TetrahedronDiscreteIntersection<> was not created  
The object is not in the factory.  

I got it as well. This class is not a SOFA object, and it is not added to the Factory. It therefore can not be used in a scene. Moreover, it is only an Intersector: therefore it can not compute the whole discrete intersection. This seems to be an old class.

A solution could be to create in SofaMiscCollision (applications/plugins) a class inheriting from both DiscreteIntersection and TetrahedronDiscreteIntersection. By doing this, you would have the intersection method you want.

However, for needle insertion, people does not seem to use collision models based on Tetras.

Hugo

[Hugo]

Hey @jonny

Sorry I am no expert of the RecordedCamera.
I will poke @epernod for this.

Best

Hugo

[Hugo]

I got it to compile as you did and got the same runtime error (loading the plugin):

[ERROR]   [PluginManager] Plugin loading failed (/data/Softwares/sofa/build/build-master/lib/libSofaPardisoSolver.so): /data/Softwares/sofa/build/build-master/lib/libSofaPardisoSolver.so: undefined symbol: pardisoinit_

The symbol pardisoinit_ is missing, which means that in the newer versions of pardiso, the constructor of pardisoinit() (maybe the number of parameters) changed. Let’s try to investigate both on our side, the first to succeed let the other know and make a nice pull-request 😉

Best

Hugo

[Hugo]

Dear all, thank you so much for your inputs and feedback! That’s great to count you with us, and your opinion is definitely super valuable!

@amackeith do not worry, if a migration is decided (next week the dev meeting will discuss this, according to your replies), we will make sure to find a way to migrate all previous discussions as well!

Hugo

[Hugo]

Opinions from all users are welcome!

@amazier @anoushs @mckysd5 @psomers @twxu @tschuelia @albanodot @andrija987 @estefania @pasquale94 @sergeinikolaev @torri @nhnhan @amackeith

[Hugo]

hey @anoush

Such instabilities are usually related to wrong definition of your numerical settings (time step, tolerance, mesh size etc), impacting the conditioning and resolution of your system. This is the art of numerical analysis: the key is always to understand the mathematical/matrix system you are actually building in your simulation.

In you case, it could be:
– a too quick increase of the pressure with a time step too large
– a pressure inducing large deformation of the mesh leading to ill-shaped finite elements
– the pressure constraint can not be respected as desired and your constraint system diverges
etc etc.

To solve such problem, more insight of a basic scene example displaying your problem is needed. Best wishes,

Hugo

[Hugo]

A pull-request has been proposed to fix this.

I therefore close the topic.
Best wishes,

Hugo

[Hugo]

Congrats to both of you @jnbrunet @quantanovo

I therefore close the topic. Do not hesitate to open a new one for any other topic.
Best wishes,

Hugo

[Hugo]

Hey

From your scene singleFinger_wObject_XML.scn, it appears that you indeed use Lagrange multipliers: use of the FreeMotionAnimationLoop + GenericConstraintSolver.

Recovering contact forces can be done in the GenericConstraintSolver:
– activate the “computeConstaintForces” boolean
– this fills the nodal data field “constraintForces” that you can use to compute your pressure

I hope this helps.
Best

Hugo

[Hugo]

Hey @stonkens @damien-marchaluniv-lille1-fr

The new release v20.12 is out!
Plugins SoftRobot, STLIB and so on are being (or were) updated to be compatible with. It should therefore be all fine!

Let us know if you have any issue, otherwise we’ll close the topic.

Best,

Hugo

[Hugo]

Dear @olumide

As said earlier, it’s good to see that you captured the big picture of SOFA.
Have you found some time to look at the “Components” section in the online documentation or the SofaComponents project ?

Again, we would delighted to have you with us during our dev meetings.
Best wishes,

Hugo

[Author]

Posts