[Hugo]

Hey @abdelrahman2010

The fact that you get different results between SOFA from a python environment and SOFA from runSofa necessarily comes from your main() function (since this function is called when working from python and not called from runSofa).

Indeed, you can notice that the main() function is adding
rootNode.addObject(TrunkController(node=rootNode))

despite the TrunkController is also defined in the createScene() function.
Could you try to remove this line?

Best

Hugo

[Hugo]

Hi @arsalan

Is there anyway you can access 3d models of the organs you want to simulate?
Then, we could help you building the scene.

Hugo

[Hugo]

hey @frank

Thanks for your interest in SOFA! Which haptic device would you like to use for your force feedback?

You have an example in the Geomagic plugin (in applications/plugins) in the scenes/ folder.

Best wishes,

Hugo

[Hugo]

Hey @neriodev

First of all sorry for this very late reply.
The integration of SOFA within UE has been prototyped by @epernod from InfinyTech3D. Any interest in it or in a collaboration can be referred here.

Let me know if you want to know more generally regarding the open-source project SOFA.
Best wishes,

Hugo

[Hugo]

Hey @sergiopm23

Have you the STLIB plugin well loaded in the PluginManager? (and the SofaPython plugin?)

Hugo

[Hugo]

Hey @brunob81hk

Sorry about this mis-solved flag!
Hey @froy could you take a look at it please?

Hugo

[Hugo]

Great to know @christopheyberg

If you think your changes can be useful for others do not hesitate to pull-request them.
Let’s keep updated about this when the time suits you.

VG

Hugo

[Hugo]

Hi @christopheyberg

Sorry for the delay of the reply.
To get the convergence error, you can firstly use the graph to check residuals at each iteration. The LCP does not provide by default much more.
I think you can also use the printLog option to print information.

However, it could be possible to modify the Gauss Seidel in it to output more, like creating data to access the information of interest. This would require modifications in LCPcalc and LCPConstraintSolver. This is no more simple way, but we could assist you in it.

Best wishes,

Hugo

[Hugo]

Hey @brunob81hk

Sorry for replying so late but I was hoping someone else (better than me on the topic) would have answered.

I never built a simulation with a jaw model for grasping. I guess you got inspired from both the Xitact and Geomagic examples.

Without the meshes I cannot run the scene, let me know if you are willing to share them.

Could you try using : input2="@DOFs" ?
You would have the articulated system independent from the Trex position but managing the opening/closing of the jaw. The “Trex” node in charge of following the Trex device and the VectorSpringFF connecting the two for stability.

Let me know if it helps.

@epernod if you recall how to build a jaw model it is also welcome 😉

Sorry for being approximated Bruno,

Hugo

[Hugo]

Hi @anthony

Shall we close this topic ?
Best

Hugo

[Hugo]

Great @anthony !
If you would share some feedback when you reach your final results it would be nice : a video, a scene file or anything else would be great!

Best

Hugo

[Hugo]

Dear SOFA forum,

Registration for the 2021 edition of the SOFA Week is free and open!
It’s now time:

– to submit a (short as you wish) abstract to save a time slot for a presentation of your work: https://easychair.org/cfp/sws2021
– to apply for the award competition if you would like to win one of the two prices : https://www.sofa-framework.org/sofa-events/sofa-week-2021/awards/
– to mention the topic of interest you would like to address at the STC#12, and the work you achieved recently
– or simply to register for attendance!

Best,

–
The SOFA Consortium staff

[Hugo]

Hey @asedal !

Thank you for posting your issue. I will summarize the solutions we discussed together directly:

1. It is confirmed (Chip is discussing it with the devs) that the SurfacePressureConstraint is timestep dependent and the pressure set as input has to actually be related to pressure/dt as explained in the associated GitHub issue.

2. I think you are now smoothly working with the LinearSolverCC, right ?

Do not hesitate to also update this discussion thread (and we keep in contact per email as well obviously 😉 )

Best,

Hugo

[Hugo]

Hi @sedal,

I just update this post.

Regarding the issue with the SurfacePressureConstraint detailed in the associated GitHub issue.

Note that the research team is also investigating convergence issues with such constraints. I will update you, it could also explain the difficulty to converge with your high-stiffnesses.

Best wishes,

Hugo

[Hugo]

Hi @quantanovo

Even if it took me some time, I carried on the investigation. It appears that the SurfacePressureConstraint is timestep dependent and the pressure set as input has to actually be related to pressure/dt as explained in the associated GitHub issue.

You may want to follow closely the ongoing discussion there.
Best wishes,

Hugo

[Hugo]

Hi @ma1991

Thanks for your question.
Positions of an object are stored in the component MechanicalObject. This component is storing the degrees of freedom / state information: rest_position (equals to initial position if not specified), position, velocity.

I would therefore recommend to access the initial position from MechanicalObject.rest_position and the current position from MechanicalObject.position. Your total displacement would therefore be: position-rest_position.

I hope this helps
Best wishes,

Hugo

[Hugo]

Hi @daserk

For such a docker topic, let me poke @younesssss for a bit of support.
Could you give a look please @younesssss ?

Best

Hugo

[Hugo]

Hi @steph @toriwalnuss

Any update on this topic?
Hope you are now using it smoothly

Best

Hugo

[Hugo]

Hey @geofliu

Can you confirm us that with the v21.06 the problem is now solved?
Else I would push for working on this on the STLIB side.

Best

Hugo

[Hugo]

Hi @bmanz

I usually use imgbb to uplaod an image and get a link that I can reference in my post. Feel free to do the same.

Best,

Hugo

[Hugo]

Ola @eaparra

To have an example, you should rather take a look at the scene BeamFEMForceField.scn.

If the simulation is far away from the experiment, I would indeed check the units. To help here, I would need to see your scene. What do you give as a topology? what is the lenghth unit?

The important point with units is that they have to remain coherent: if you give as input a mesh/topology in meters and you would like to work in Newton, then your Young’s modulus is in Pa. If you give as input a mesh/topology in millimeters and you would like to work in Newton, then your Young’s modulus is in GPa. etc

In the same way, the radius of your beam must be in the same length unit than your mesh.

Best wishes,

Hugo

[Hugo]

You are welcome @toriwalnuss

I set the topic as solved.
I found the extract translation values by computing the size of the box bounding your mesh (dx, dy, dy) and by translating the object by (dx/2, dy/2, dy/2) you get it centered back in (0,0,0). For this I used the “Extract Cell by Region” filter from Paraview 😉

Best

Hugo

[Hugo]

hi @chiarasapo

Would you agree to share this code by making a pull-request on GitHub?
Best wishes,

Hugo

[Hugo]

This is per-fect @asedal, thanks a lot!

[Hugo]

Note that I moved your topic in the forum “Using SOFA” instead of “Announcement”.
Best,

Hugo

[Author]

Posts