Noura

Hello,

I faced the same issue before with CGAL. Fortunately, I noticed that I could compile SOFA with CGAL successfully using clang
I know that this doesn’t solve the problem, but it could be a temporary solution until the issue is fixed.

I’m running:

Ubuntu 18.04.1 LTS
CGAL-4.11
clang version 6.0.0-1ubuntu2

In order to compile using clang:…[Read more]

Hello Antonin,

Thanks for the clear detailed reply. Yes, it helps!

For the moment, the collision models are static along the simulation, and splitting the mesh into 2 parts sounds a good approach.

The hint concerning “doCollisionDetection” method is also handy, I may need to implement a specific collision pipeline with an adapted narrow phase…[Read more]

Hi Zahra,

In general, you can use the python debugger pdb directly in the terminal
https://docs.python.org/2.0/lib/module-pdb.html

Or inside an IDE such as Spyder which supports pdb as well
https://pythonhosted.org/spyder/debugging.html

I hope this will help,

Noura

Hi Zahra,

I’m running Sofa v18.06. If you compile the core of sofa successfully, you should have runSofa binary in the bin directory as usual. Isn’t that the case?

Noura

Great effort. Thanks!

The constraints page in particular is very helpful. In case of related suggestions or minor remarks, should we post them on this thread or on sofa doc github?

Noura

BTW, I noticed that the link of “Mapping” page doesn’t exist.

Hi Ben,
Did you defined the “constraintFactor” in the AttachConstraint component?
If not, please try something like this:

<AttachConstraint object1="@obj1" object2="@obj2" indices1="0 1 2 3" indices2="0 1 2 3" constraintFactor="1 1 1 1" />

Best,

Noura

Hi Hugo,

Yes, it is working as desired right now! Thanks a lot.

Besides the sensitivity to the dt, mass and force values, I realized that the main issue was due to the absence of the “compliance” parameter in the “UncoupledConstraintCorrection”!.

I also noticed that by removing the mass and constraint correction from the “object1_surf” node,…[Read more]

Hi Hugo,

Thanks for looking into the scene. Yes, I see your notice about the usage of different templates in a projective constraint is very relevant and now, at least, I understand why the behaviour is not as expected.

Concerning your question about the need of MO_object1:
I use it is because the cube should be a rigid object and not a…[Read more]

Thanks @Hugo and @Binesh for your attempts!

We managed finally to fix our simulation.
Solution was by replacing the MechanicalObject position by a different one (the base of the bone instead of its center of mass), and it works as desired.

Best,

Noura

Hi Hugo,

No matter where the torque is applied (on the center of mass or on another point), the proximal extremity of the bone (Node RAF_Proximal in the scene) should be fixed against translation.
In other words, imagine that the bone is mounted to a fixation device at this point (RAF_Proximal) which allows it only to rotate but not to go…[Read more]

Hi @Binesh,

Thanks for your comment.
In my current scene, there is no mesh topology node. Do you mean in the “Surface_Radius” Node? If yes, I already tried to set both: once a “FixedConstraint” and then a “PartialFixedConstraint” on the vertex (which has index no 1011). None of these lines:
<FixedConstraint name="fixation_poisition"…[Read more]

Hi,

Maybe adding <FixedTranslationConstraint template="Rigid3d" /> inside
<Node name="cube" activated="1">
should restrict the translation and allow the rotation? Not sure if this is the proper way to do it.

Noura

Hi Zahra,

Regarding your first question, that line is not important, it’s just an html foramt error which should underline the phrase “In your scene”.
In your scene, if you want to use Python …

For your second question:
First of all try to test your scene without arguments, run:
zahra@zahra-System-Product-Name:~$…[Read more]

Hi Eleonora,

As mentioned before, I think that using attach constriants between 2 vertices requires that these 2 vertices be close to each other, optimally they should share the same position (see illustration). Otherwise the connection won’t look good because of the distance gap between the objects.
In my simulation, I managed to get good meshes…[Read more]

Just to conclude before closing the thread: it looks like gcc 7.3.0 issue. I switched to clang 6.0.0 without any problems.

Noura

Hi Hugo,

I think that searchUp should be called here, as it a BaseObject function.

typename T::SPtr searchUp() const { const BaseContext* context = getContext(); return typename T::SPtr(context->get<T>(BaseContext::SearchUp)); }

I also noticed that this error is gcc dependent:
– using gcc 7.3.0 => compilation error
– using gcc 5.4.0 =>…[Read more]