Simulation incredibly slow

[twxu]

Hi,

I’d like to use SOFA to run many simulations (of bending pneunet interacting with a soft cylinder) for research, but my simulations run incredibly slowly for some reason (10 hours for 7 seconds of simulation).

I have tried implementing the Multithreading and SofaCUDA plugins alongside the SoftRobots plugin, but no success so far.

Could the issue be because of the use of SparseLDLSolver? I read from the SOFA documentation that this component can be very slow for large systems. Though, I tried replacing SparseLDLSolver with CGLinearSolver and did not observe speed increases.

General layout of scene solvers and constraint corrections used:

<root node>
    <FreeMotionAnimationLoop />
    <GenericConstraintSolver />
    <DefaultPipeline />
    <BruteForceDetection name="N2" />
    <MinProximityIntersection />
    <DefaultContactManager response="FrictionContact" />

    <pneunet node>
        <EulerImplicitSolver />
        <SparseLDLSolver />
        (load mesh, mechanical object, etc.)
        <LinearSolverConstraintCorrection />
    </node>

    <cylinder node>
        <EulerImplicitSolver />
        <SparseLDLSolver />
        (load mesh, mechanical object, etc.)
        <LinearSolverConstraintCorrection />
    </node>
</node>

[Scheikl]

Hi @twxu,
LinearSolverConstraintCorrection is actually a pretty expansive computation, as it solves the linear system at each time step anew.

Could you try the adapted scene as follows?

<root node>
    <FreeMotionAnimationLoop />
    <GenericConstraintSolver />
    <DefaultPipeline />
    <BruteForceDetection name="N2" />
    <MinProximityIntersection />
    <DefaultContactManager response="FrictionContact" />

    <pneunet node>
        <EulerImplicitSolver />
        <CGLinearSolver />
        (load mesh, mechanical object, etc.)
        <PrecomputedConstraintCorrection />
    </node>

    <cylinder node>
        <EulerImplicitSolver />
        <CGLinearSolver />
        (load mesh, mechanical object, etc.)
        <PrecomputedConstraintCorrection />
    </node>
</node>

As long as the model is not changed too much during the simulation (for example by using the CarvingPlugin) that should be fine.

Cheers,
Paul

[twxu]

Hi @Scheikl,

Thanks very much for the prompt response. Does PrecomputedConstraintCorrection require some initial file to be created? I implemented the changes you suggested but my scene will not open for some reason:

[ERROR] [FileRepository] File object-9876-0.02.comp NOT FOUND in :E:/sofa/src/share:E:/sofa/src/examples:E:/sofa/build:E:/sofa/build

[Scheikl]

Hi @twxu,
oh, yes you are absolutely right.
You can generate that by setting recompute to true.

<PrecomputedConstraintCorrection recompute="true" />

Cheers,
Paul

[twxu]

Hi @Scheikl,

Is it normal for the precomputation to take a long time for some meshes?
The .comp file was generated for the cylinder in about 10 minutes, but even after 5 hours the .comp file for the pneunet was not generated.

[Scheikl]

Hi @twxu,
the computation time increases with your model size.

Are your models maybe a bit too large?
The Liver of the demo scene examples/demos/liver.scn, for example, has 181 points.

Cheers,
Paul

[twxu]

Hi @Scheikl,

I think you’re absolutely correct that my model size is making it slow. Does the time needed for the precomputation scale linearly with model size?

The cylinder object had ~1000 points and took about 10 minutes, but the pneunet object has ~3500 points and seems to take many hours.

I’m also concerned that perhaps the pneunet precomputation takes so long because it uses an additional cavity mesh inside with a “SurfacePressureConstraint” (from SoftRobots plugin). Would that affect the precomputation?

Thanks so much for all your help so far.

[Scheikl]

Hi @twxu ,
sadly I am not familiar with the underlying code, but I guess there is some Matrix inversion involved which would make the computation scale roughly cubic.

I did not have the chance to work with cavity inside meshes yet.
Maybe someone from the SoftRobots Plugin (for example @@sescaida) could give you more info on that?

You are very welcome. 🙂

[sescaida]

Hello @scheikl and @twxu,

unfortunately, I’m not an expert on the solvers, so I can not give a very technical insight. However, it does seem very weird that a simulation would take in the order of hours. Up to a few thousand elements, the simulations should run interactively (5FPS+). As an example, on my computer I run a simulation that has ~2200 points and ~7500 tetrahedra at 8 FPS, without CUDA, etc. Using the SurfacePressureConstraint, which I have often used, shouldn’t affect the performance in this way neither. So, that leaves me wondering about whether you are doing something else in your scene. Here a re a few questions for debugging and feedback:

– Are you using a script (a python controller) that writes to disk or similar?
– How did you generate your geometry?
– Does the caduceus scene run smoothly (the one launched when starting SOFA with no arguments)?
– Does the pneunet or any other example from the SoftRobots plugin run smoothly?

If you want, you can post a share link to your geometries and I can have a look to see whether there’s something out of the ordinary happening with them.

Best

Stefan

[twxu]

Hi @sescaida,

– I am using a python controller, but I basically copied the one used by the SoftRobots examples (increments SurfacePressureConstraint value at regular time intervals inside onBeginAnimationStep). I’m also using a Monitor object to export force data on some (5) nodes inside the scene.

– I generated the geometries by first exporting an STL file from SolidWorks, then creating a VTK file using Gmsh (v4.5.6). In the scene I use the VTK files for the volumetric mesh, and the STL files for the collision mesh. The files I used can be found here: drive link

– Both the caduceus scene and the SoftRobots pneunet example scenes run smoothly.

If you could take a quick look at the geometry files I’m using I would really appreciate it; this has become quite a bottleneck for my research.

[sescaida]

Hi @twxu,

I looked at the meshes and they seem to be ok. I can load them with gmsh and as you say, the number of elements is reasonable, so from that side there should not be an issue.

To me, that leaves three candidates as a cause for your problem: the monitor object, the scripting and the collision pipeline. Have you tried to disable each one of them? I guess you started modeling your pneunet by modifying the existing example scene? Could that be a way to debug this issue? Concretely, I mean:

1) Take original pneunet scene and replace the geometries only (stls and vtk)
2) Add the elements you want (monitor object, collision pipeline) and test after each addition.

Best

Stefan

[twxu]

Hi @sescaida,

Thanks for your suggestions!
It seems like the main issue is something to do with the collision pipeline: my simulation runs smoothly until the pneunet comes into contact with the cylinder, at which point it slows down greatly. I will definitely try replacing the geometries in the example pneunet scene (“grab the cube”) and see if it still slows down during collision.

I also tried disabling the Monitor object, which helped a lot: it took ~1 hour instead of ~6 hours for ~5 seconds of simulation time. Unfortunately I think I need to keep the Monitor object so I can measure forces on the cylinder, unless there’s another way to probe node forces?

Also, do you know of any potential reasons why generating the .comp file for PrecomputedConstraintCorrection could take a very long time? I used PrecomputedConstraintCorrection for the cylinder which seemed to help, but for some reason even after many hours the .comp file for the pneunet is not generated.

[sescaida]

Hi @twxu,

you’re welcome!

If the monitor object is causing some issues, I would definitely prioritize having the scene running smoothly. There should be alternatives to obtain the force values through scripting by accessing data fields of the components.

As you say, try adapting the example pneunet scene to your geometries and see where the bottleneck appears. It is normal for the simulation to slow down when contacts are happening. How much, will depend on the complexity of the collisions, but more than a factor of 10 should indicate a problem, I would say. One thing you can do to optimize this, is by making sure only the relevant parts of your object are having a collision mesh. This will save time by avoiding proximity queries for the parts that are not expected to enter in contact anyways. Beyond that, I think @scheikl actually has some practical experience in this and might be able to help out.

Best

Stefan

[Hugo]

Hi @twxu,

Congrats @scheikl for the explanations! Thank you and @sescaida for the tremendous help, so much appreciated to have support on the forum!

@twxu, about the PrecomputedConstraintCorrection requires to precompute once at the first time step the inverse of A-1 in order to then efficiently process all computations required for the constraint resolution:
– Lagrange multipliers solving :
– bring back the lambda (Lagrange multipliers) in 3D space: before computing the corrective velocity

Therefore, the more degrees of freedom (nodes) you have the longer it takes to precompute/store. And it will even be quadratic regarding your nb of nodes.

Never forget to take the time to read through the page about Lagrange constraints, especially here the section about ConstraintCorrection.

I am sorry for your other problem, could you summarize it again?

I hope it helps.
Best,

Hugo

[twxu]

Hi @Hugo,

Thanks for the additional details on the PrecomputedConstraintCorrection!

I was able to generate the .comp file for the pneunet, though when I use CGLinearSolver and PrecomputedConstraintCorrection (instead of SparseLDLSolver and LinearSolverConstraintCorrection) the pneunet no longer bends in the simulation, for some reason (it is meant to bend using a cavity mesh and a SurfacePressureConstraint).

The main issue I was having was that the simulations were taking a long time (slows down after collision). It sped up significantly after removing a Monitor object from the scene: now it takes about 30 min for 1 second of simulation time. Currently I’m looking into whether there are other reasons why the collisions are slow, though no luck so far

[jnbrunet]

Hi @twxu,

Just a quick question: Did you compile SOFA yourself or did you use the precompiled version from the download section of this website?

If you compiled it yourself -> Make sure you did not compile it in debug mode but in release mode.

Also, on what system are your running your simulation (OS? CPU? How much RAM?)

J-N

[twxu]

Hi @jnbrunet,

Currently I’m using v20.06 compiled from sources. I believe it is in Release mode; at least, I made sure to set it to “Release” inside VisualStudio when building the solution file generated by CMake.

I’m running SOFA on my personal laptop: OS is Windows 10 Home, Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz, with 16 GB installed RAM

[Hugo]

Hi @twxu,

Have you tried as suggested earlier by @sescaida “try adapting the example pneunet scene to your geometries and see where the bottleneck appears” ?

Could you also share a screenshot of your scene? Especially if collision occurs, you could activate the “Interaction” view option to see where contacts (if any) are located.

Hugo

[twxu]

Hi @Hugo,

I have tried incrementally adapting the example pneunet scene, though it wasn’t exactly the same because that scene uses a rigid object instead of a soft object. Currently I believe the bottleneck is the collision calculations between the pneunet and the object, since there is quite a large collision surface area (judging by the alarmDist red lines in the GUI):

simulation screenshots: https://github.com/thomaswxu/SOFA/tree/main/exampleImages

[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

[nhnhan]

Hi everyone,
I am having the same problem as described in this post. My scene is quite a little bit different which can be reviewed through this link. To summarize it, I have a flexible tube that is pneumatically actuated to certain pressure Q using SurfacePressureConstraint and an object (the finger in this scene) moves forward to make interaction with the tube. Things seem fine until the collision occurs in the early state (with a small number of contact nodes), the tube appears to be “exploded” and then the simulation is crashed. I can say that the tube was not deformed as expected when making contact with the object. Also, I got this warning in the terminal

[WARNING] [GraphScatterredType] set an element is not supported in MultiVector

I have followed all suggestions in this post but nothing works. Otherwise, I also have some minor problem:
1. When you load this scene, there will be error message said:

[ERROR]   [TetrahedronSetTopologyContainer(topology)] Cannot find edge 0 [167, 0] in triangle 0
[ERROR]   [TetrahedronSetTopologyContainer(topology)] Cannot find edge 0 [167, 0] in triangle 0
[WARNING] [TetrahedronSetTopologyContainer(topology)] TrianglesAroundEdge buffer can't be created as EdgesInTriangle buffer creation failed.
[ERROR]   [TetrahedronSetTopologyContainer(topology)] Cannot find triangle 0 [335, 337, 205] in tetrahedron 0
[WARNING] [TetrahedronSetTopologyContainer(topology)]  In getTetrahedronArray, cannot find edge for tetrahedron 0and edge 0
[ERROR]   [TetrahedronSetTopologyContainer(topology)] Cannot find triangle 0 [335, 337, 205] in tetrahedron 0
[WARNING] [TetrahedronSetTopologyContainer(topology)] TetrahedraAroundTriangle buffer can't be created as trianglesInTetrahedron buffer creation failed.

I tried to reopen the mesh file (.vtk) by using gmsh and it seems okay. So, i don’t understand why this error popped out.
2. When I change the inner pressure value, the tube is supposed to be expanded evenly in all direction but it is not (in my opinion) and the model is weirdly shaking

Hope to hear your thought about this issue, and any help is deeply appreciated. Thank you

[Hugo]

Hi @nhnhang

In your scene, several problems seem to occur:

• for the skin, you are using a LinearSolverConstraintCorrection. Such a constraint correction requires a direct linear solver to be able to compute the A-1 matrix, used for the computation of the compliance matrix W. Either you use a direct linear solver (like the LDL you commented) or you change for a UncoupledConstraintCorrection. Be careful, choosing one or the other are two different assumptions on your system. See the doc for more, or we can make some training session. Anyway, this will the warning [WARNING] [GraphScatterredType] set an element is not supported in MultiVector
• About the topology errors/warning, the edge topology structure seems to be missing, just add the option createSubelements="1" in the associated MeshLoader

By using a direct linear solver I get:

By using the UncoupledConstraintCorrection I get:

I hope this helps and let’s see if the shaking (meaning numerical instabilities, maybe lack of convergence) remains and solve this subsequently. It could also come from the management of constraint through the UncoupledConstraintCorrection.

Best wishes,

Hugo

[Author]

Posts