25 September 2020 at 1 h 42 min #17209
I’m working on a simulation with a pneunet, which has a cavity that is pressurized.
I am experiencing some issues due to mapping. Specifically, it seems that the nodes of the “cavity” mesh are being mapped to incorrect nodes in the surrounding pneunet mesh (so pressure is being applied to the wrong pneunet nodes as the cavity pressurizes).
I’ve found an example scene from the SoftRobots plugin which has the same setup, but does not have this mapping issue (see images below).
1. Poor mapping in my scene
2. Good mapping in example scene
3. Scene setup with cavity mesh (green) and surrounding pneunet mesh (blue), from SoftRobots example
(link to images in case they don’t appear: https://imgur.com/a/4M0SMIr)
Do the mesh nodes of the cavity and the surrounding pneunet have to align perfectly to stop the mapping from spreading to outside/nearby nodes? If so, is there a good way to create the meshes so that their nodes/elements align?
Any guidance is appreciated!5 October 2020 at 22 h 29 min #17282HugoKeymaster
- SOFA Consortium
Thank you for your message.
The nodes of the cavity do not have to be aligned with the surrounding pneunet. The fact is that a correspondance will be sought for each node of the cavity with regards to the surrounding element (here, sought in the surrounding tetrahedron in the pneunet mesh).
If your configuration 1. not working properly?
If not, could you elaborate on the issue?
Hugo6 October 2020 at 18 h 52 min #17317
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).
When the probed nodes are not being mapped to by cavity nodes, the forces increase then settle to zero (as expected).
(The pneunet nodes that I’m interested in are all being mapped to by cavity nodes.)
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?10 October 2020 at 0 h 03 min #17341HugoKeymaster
- SOFA Consortium
Interesting, I do not know in detail the SoftRobot tutorial. But I think I can already guide you a bit.
1. since you are using a mesh for the cavity which not fitting the mechanical mesh anymore (no exact correspondence between mesh vertices), the mapping will compute the associated points in the finger mesh around each point of the cavity mesh (and their barycentric coordinates). If the finger mesh is oriented (by this, I mean tetrahedra are all oriented in the same direction) then you can have a slight twisting effect due to the pressure constraint mapped into these oriented tets. To decrease this effect, you should use a finer mesh or a non-oriented mesh (for the finger).
2. This, I guess, could be due to the dissipative integration scheme. Especially the Rayleigh damping added. Could you try setting them to zero ?
Hugo21 October 2020 at 22 h 57 min #17437
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!
- You must be logged in to reply to this topic.