[Hugo]

Hi Zahra,

First of all, now SOFA v16.12 starts being a bit old. It’s good to remain a bit up-to-date, but I understand the need of stable release for simulation development.

Regarding your result #1 and #2, this looks strange and never occured with me. This may be due to your Python version, what do you have?

result #3:
– the invertMatrix error : it warns that the inverse of the system matrix includes very small values. This might come from a too strong sollicitation and FEM elements might have collapsed
– the nlcp gaussseidel error : it is a normal output if the constraint resolution (GaussSeider is the solver used to compute the solution of the constraint problem) did not find a solution with the tolerance and nb max of iterations given by the user.

Regarding the error from [FileRepository], it seems to be fixed in the latest master version.
But when animating, I never got a crash. I will try to recompile from scratch the v18.06 on my machine.

Best,

Hugo

[Hugo]

Hi @mjbarrow,

you are actually using Flexible which uses an API a bit different from SOFA (decoupling the numerical integration, the mechanical law etc.). This is why the VTKExporter is not very usable in your case. Moreover, the simulation is based on Frame approach, with Voronoi shape functions. There is therefore no topology assiociated (usually required by VTKExporter).

In your particular case, I would recommand to export it using python:
python script “exportPositionYoungModulus.py”

import Sofa
import sys

class WriterController(Sofa.PythonScriptController):

    def bwdInitGraph(self,node):
        self.nodeWithYoungModulus = node.getChild('Flexible').getChild('behavior').getChild('E')
        self.MO = self.nodeWithYoungModulus.getObject('E')
        self.containerYM = self.nodeWithYoungModulus.getObject('youngM')

        position = self.MO.findData('position').value
        youngModulus = self.containerYM.findData('values').value

        thefile = open('exportPositionYoungModulus.txt', 'w')
        
        for i in range (0, len(position)-1) :
            thefile.write("%s\n" % position[i])
        
        for i in range (0, len(position)-1) :
            thefile.write("%s\n" % youngModulus[i])
        
        return 0

and add the PythonController in your scene:

<PythonScriptController name="WriterController" filename="exportPositionYoungModulus.py" classname="WriterController"/>

Let me know if it suits you.
Best,

Hugo

[Hugo]

Hi @adrien,

Thank you for sending the scene.
In your case, the issue comes from the fact that you are using an explicit solver (RungeKutta) that does not build the system: the RungeKutta computes the acceleration (unknown x of your system Ax=b) by directly computing A-1.b which is very simple in your case since the Mass matrix is diagonal (UniformMass). Neither b or A is constructed, but x is found directly.

The resolution of your constraints requires to have build a compliance matrix. In explicit (with RungeKutta for instance), you might use the mass matrix as compliance and therefore use a UncoupledConstraintCorrection to build it. But usually constraints and compliance building requires the use of implicit schemes. Does this help you?

Best,

Hugo

[Hugo]

Hi @adrien

This is good project, modal analysis is a nice approach to improve performances of the simulation of complex systems! And, lucky you, a plugin implementing the Model (hyper)Reduction method will soon be released in open-source in SOFA!
I will keep you updated about it.

Best

Hugo

[Hugo]

Hi @masoud,

we already implemented such a simple code. You can find it in this repository: MyAwesomeComponents (see the src folder). This repository can be compiled as an external plugin.
I would be curious to know more about your institution and your simulation activity with SOFA. Do not hesitate to tell us more about it!

Cheers

Hugo

[Hugo]

Hi Zahra,

For the difference between the latest stable version of SOFA and the master branch, the only way to follow it is to keep very close to the SOFA GitHub repository and the associated development activity (see the “Watching” options in Github).

However, the difference between releases is available in our CHANGELOG.md file, available in the SOFA sources.

Best regards,

Hugo

[Hugo]

Hi Zahra,

I noticed some of your errors as well. This is preoccupying that such an issue passed through the SOFA contributions.
We will investigate, thank you very much for your notice. If you don’t here from us, please poke us again by the end of next week.

Cheers,

Hugo

[Hugo]

Hi @mjbarrow

could you post the full node for my understanding?
this should not be hard to fix

[Hugo]

Otherwise the use of VTKExporter is good solution for export as discussed in your other topic.

[Hugo]

Hi @mjbarrow

there is actually a specific tool for running several simulations in SOFA with Python: sofa-launcher. It is an python API launching SOFA simulation that can be called from a Python script.
The advantage of this tool is that simulations are executed parallel, i.e. independently.
Unfortunately I don’t have experience with it. I will try to find a bit of time to test it.

Cheers

Hugo

[Hugo]

Good to hear Zahra!
Binesh, it appears that Tetra2TriangleTopologicalMapping will indeed be able to retrieve the surface mesh. So there might not be a need for the Tetra2SurfaceTriangleMapping

Thanks you all for the collaboration!

[Hugo]

Hi Zahra,

I guess you behavior has been fixed since the PR#372
That explains your problem. JeanNicolas and my advices might whatever help you in overcome this issue. Keep us updated.

Hugo

[Hugo]

Hi,

This scene is working fine for me. I am using the master branch of SOFA.
Which version of SOFA are you using Zahra ?

Jean Nico is right:
– Tetra2TriangleTopologicalMapping is good enough to get the surface representation
– ObjExporter must be carefully used since it uses the visual model and exports it, VTKExporter is always a good solution and works fine also in your case.

Hugo

[Hugo]

Hi @mbarrow

I just tested this:

<Node name="root" dt="0.01" gravity="0 -9.81 0">
    <Mesh name="mesh" filename="mesh/dragon.obj" />
    <MeshObjLoader name="loader" filename="mesh/dragon.obj" />
    <MechanicalObject src="@loader" template="Vec3f" name="mecha" showObject="1" />
    <TetrahedronSetTopologyContainer src="@loader" name="topo" />
    <VTKExporter filename="example.vtk" listening="true" edges="0" triangles="1" quads="0" tetras="0" pointsDataFields="topo.points" exportAtBegin="1" />
</Node>

and it exports the “points” as a dataField in the vtk format.
Are the component in the same order than in your scene (first the Container then later in the scene the exporter) ?

Hugo

[Hugo]

Hi Zahra,

The Tetra2TriangleTopologicalMapping creates indeed a triangle topology from a tetrahedral one. Therefore is not supposed to remove the triangles within the volume. As Binesh suggested the ObjExporter does the job.

But a nice thing would be to create a new class Tetra2SurfaceTriangleTopologicalMapping inheriting from Tetra2TriangleTopologicalMapping and selecting only triangles on the border.

Hugo

[Hugo]

Hi @faichele

Always good to hear from you!
The ArticulatedHierarchyController has not been updated for a long time: history

Do you have a simple scene to test with it ?

Hugo

[Hugo]

Hi Adrien

do you have a simple scene hightlight the issue (to make sure it comes from the RungeKutta)?
Do you have any trace of the seg fault to share?

Best,

Hugo

[Hugo]

Hi @suwan,

A good point would be to create a surface mesh with lower resolution dedicated to the collision detection. So that the physics would still run on the 23460 tetrahedral mesh, while the collision computation would be done on a coarser mesh.

Another solution would be to use GPU implementation.

Do you have any scene with meshes that we could test ?
If this is confidential, you can still contact me in PM.

Best regards,

Hugo

[Hugo]

Great to hear!
Thanks for the feedback Noura !!

[Hugo]

Hi @noura

I am not sure to understand what you want to simulate.
You apply a rotation on the center of mass, the object rotates indeed.

But what is the constraint you want to apply?

[Hugo]

Thanks for your feedback @secretdevil 😉

[Hugo]

Great to hear, thank you for keeping us updated @eunkyungbae
Best wishes,

Hugo

[Hugo]

Nice to hear @suwan thank you for your feedback.
Best,

Hugo

[Hugo]

Hi @suwan,

These are not useful for the open-source code of SOFA. These dependencies are required for solvers (CUBLAS) and collision detection algorithms (CUDPP) that are implemented in private plugins. In the future, these options should be moved directly into these private plugins to avoid polluting the open-source code.
Hope this answers your question.

Best

Hugo

[Hugo]

Hi Zahra,

No the modeler is deprecated since v17.12 included.
We are working on a new Modeler application. Sorry about the inconvenience. We will update the whole community when this will be released.

Best regards,

Hugo

[Author]

Posts