[twxu]

Hi @Hugo,

No problem; I’m glad the scene is working on your end!

The original issue was that the pneunet object was bending in an unexpected direction. You recommended viewing the normals using the SOFA GUI to see if they are well oriented, though when I try viewing the normals the scene immediately crashes (SIG11 SIGSEGV segfault).

Are you able to view the normals on your end?

[twxu]

Hi @Hugo,

Thank you for the clarification; that makes sense.

How would you recommend computing the area term (S)? Is there a way in SOFA to calculate the area of individual mesh elements?
Or, would it be better to sum all the forces and divide by the entire area?

[twxu]

Hi @Hugo,

Thanks very much; I was able to count the exact number of nodes in contact using both the “constraintForces” vector and a BoxROI containing just the contact surface of the object.

I’m just a bit confused on how to interpret the constraintForces vector: specifically, how to use it to calculate contact pressure. Though, that discussion may be better at the other topic: sofa-framework.org/community/forum/topic/measuring-contact-pressure/

In any case I’ll mark this topic as solved; thanks!

[twxu]

Hi @Hugo,

Apologies for the issues with the scenes.

I’ve uploaded a simplified version of the scene to the same GitHub repo linked above, could you please try running that?
Link: github.com/thomaswxu/SOFA/blob/main/scenes/singleFinger_wObject_simple.pyscn

It should be self-contained and shouldn’t require extra plugins outside of default SOFA, though it does assume the same file/folder layout as in the GitHub repo. Please feel free to contact me if you experience any other issues getting the scene to run.

[twxu]

I would support the move to Github discussions.

Overall I haven’t had major issues with the SOFA forum, except sometimes my posts are flagged incorrectly as spam by the auto-checker.

[twxu]

Hi @Hugo,

Thanks for your suggestion! I have activated the “computeConstraintForces” boolean, and can see the “constraintForces” data under GenericConstraintSolver in the SOFA GUI.

But, I’m not sure how to interpret this data. It appears to be a single row vector; I see in the SOFA documentation that it represents intensities of constraint forces, but I could not find further information.

Could you provide more details on how to calculate contact pressure from the “constraintForces” data? I’m not sure how to proceed with the pressure calculation currently.

[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

[twxu]

Hi @Hugo,

The scene file and object files are here: https://github.com/thomaswxu/SOFA
I’m not sure how to save the crash log; is that saved by adding a “printLog” argument to one of the SOFA components?

The purpose of the stiffLayer node is to make the bottom layer of the pneunet object have a higher stiffness/elastic modulus. (It mimics a real-life pneunet prototype which has a paper layer on the bottom.)

Please feel free to contact me if you experience any issues running the scene!

[twxu]

Hi @Hugo,

Thanks for the response.

I am not 100% sure, but I believe I am using the Lagrange-multiplier based method.

My scene and object files are here: https://github.com/thomaswxu/SOFA
I hope it is not too annoying to use; you will have to change some file paths/names for the objects to be loaded correctly.
(i.e. change “fea_variant” variable in scene file, then change corresponding file paths in “filenames.py”)

Please feel free to contact me if it doesn’t work or if you have any questions!

[twxu]

Hi @jnbrunet,

Thanks for your suggestion; that solves the error!

[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

[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

[twxu]

Hi @Hugo,

I added TetrahedronSetTopologyModifier, though SOFA still crashes with the same SEGFAULT errors when I try to view the normals using the SOFA GUI.

The mesh files I’m using are here (the pneunet files are the ones I’m trying to view normals of): drive link

Here is how my scene is organized:

<root node>
    <FreeMotionAnimationLoop />
    <GenericConstraintSolver />
    <DefaultPipeline />
    <BruteForceDetection />
    <MinProximityIntersection />
    <DefaultContactManager />

    <pneunet node>
        <EulerImplicitSolver />
        <SparseLDLSolver />
        <MeshVTKLoader />
        <TetrahedronSetTopologyContainer />
        <TetrahedronSetTopologyModifier />
        <TetrahedronSetGeometryAlgorithms />
        <MechanicalObject />
        <UniformMass />
        <TetrahedronFEMForceField />

        <BoxROI>
        <stiffLayer node>
            <TetrahedronSetTopologyContainer />
            <TetrahedronSetTopologyModifier />
            <TetrahedronSetGeometryAlgorithms />
            <TetrahedronFEMForceField />
        </node>
        <LinearSolverConstraintCorrection />

        <cavity node>
            <MeshSTLLoader />
            <Mesh />
            <MechanicalObject />
            <SurfacePressureConstraint />
            <BarycentricMapping />
        </node>

        <pneunet collision node>
            <MeshSTLLoader />
            <Mesh />
            <MechanicalObject />
            <TriangleCollisionModel />
            <Line />
            <Point />
            <BarycentricMapping />
        </node>
    </node>
</node>

Let me know if any additional info would help; I can definitely share the full scene file but I’d have to clean it up and simplify it (e.g. not use absolute file paths) first

[twxu]

Hi @Hugo,

Is there a way to check that inside SOFA? It seems ok when opened in Gmsh.
I’m also confused by this error because I only saw it appear after switching to v20.06 (the same scene opened in v19.06 did not show these errors).

[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.

[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.

[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.

[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.

[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

[twxu]

Solved; disabled the components that the build was failing on individually in the CMakeLists.txt file. Not sure why these components didn’t work, but the rest of the components built successfully:

standardTetrahedralFEMForceField, sphereForceField

[twxu]

Hi @Hugo,

Apologies for the delayed response.
That makes sense, thank you. Unfortunately for some reason I cannot view the normals (I see SEGFAULT errors and SOFA crashes). What should well-oriented normals look like?

[twxu]

Hi @nicklj, @Damien Marchal,

Sorry to add to an old post, but I am experiencing the same issue (after updating SOFA from v19.06 to v20.12). I see the exact same warning messages, but the scene still appears to work as it did before (using .VTK files).

Any updates on why these error messages appear?

[twxu]

Hi @Benjamin,

I used Gmsh. It worked fairly well for when one object was completely enclosed by the other object; I’m not sure how well it’d work if the objects are only partly in contact.

I opened the STL file of the outer object in Gmsh, partitioned it into different surfaces, then deleted the outer surface (leaving just the enclosed inner surface). So that inner surface was exported as a cavity mesh that aligned with the outer mesh.

Hope that helps!

[twxu]

Hi @Hugo,

Apologies for the delayed response.

1. I’ve now implemented a mesh where the nodes of the two objects (pneunet body, cavity) align, which has largely solved this twisting issue

2. I’ve tested with and without nonzero Rayleigh damping, and in both cases the forces stabilize to zero over time (which is good).

By the way, my understanding was that dissipative integration schemes can cause signals to go to zero (when the signal normally should not go to zero). In this case I believe it’s the opposite: I would expect the forces to go to zero as the pneunet reaches maximum pressure and remains motionless. Are there cases when dissipative integration schemes cause signals to not go to zero, when they should normally go to zero?

In any case I will mark this topic as resolved; thanks for your help Hugo!

[twxu]

Hi @Hugo,

Thanks so much for replying.
Basically I am experiencing 2 issues with my scene:

First, the cavity is able to inflate and cause the pneunet to bend, but the pneunet does not bend straight downward. It “twists” slightly (i.e. bends in the Z-direction into the screen) which is unexpected. I suspect that this is because the cavity mapping is applying pressure to pneunet nodes that are not touching the cavity mesh.

Second, I am probing forces on nodes on the underside of the pneunet (using Monitor), but the forces do not behave as expected.
(Forces are probed as the cavity pressurizes. The pneunet bends, then stops as max pressure is reached.)

When the probed pneunet nodes are being mapped to by cavity nodes, the forces increase then settle to nonzero values (unexpected).
Graph: https://imgur.com/Z5pdT0C

When the probed nodes are not being mapped to by cavity nodes, the forces increase then settle to zero (as expected).
Graph: https://imgur.com/hGxg7C3

(The pneunet nodes that I’m interested in are all being mapped to by cavity nodes.)

To summarize:
1. The pneunet does not bend straight downward; it “twists” and bends out of the plane.
2. Probed forces on pneunet nodes of interest do not eventually settle to zero as expected.

It seems that both of these issues are caused when cavity nodes get mapped to pneunet nodes that are not directly touching the cavity mesh. Is there a way to constrain the cavity mapping somehow so that this does not occur?

[Author]

Posts