Showcase how to get data from SOFA components and fix RegularGridTopology

[th-skam]

@Fimache, this is just to show how we can simplify the particular scene using existing SOFA mechanisms. It's a PR on the #16.
You can read the changes in the PR to learn about the concepts.

• Basically, to implement the quadrature logic on the boundary, you don't need to create the arrays yourself. The hexa and quad arrays can be taken from SOFA components. So the compute_nodal_forces function can be simplified. This will make it easier for you to have higher-order quadrature rules in your next PRs.
• To do the above, we need to use a Python Controller object. This is because the hexa and quad arrays get initialized by SOFA so they are not available at the time the python script is being parsed. That's something new to learn about SOFA.
• Finally, inside a Node, you can't have 2 Topology Containers. So the RegularGridTopology must be placed in a node above (I named it GridTopology) and the solid Node that you have simply references it one level above.

Take some time to look at this PR and get back if you have any questions.

[Fimache]

I verified and tested the changes. Results match the previous version perfectly. The simplification is clean and well-structured.

These questions are to help me properly learn SOFA mechanisms for my upcoming contributions. Thanks in advance!

1. Node ordering in quads
   Do the quads from Hexa2QuadTopologicalMapping have the same node ordering as the ones I was building manually? The outward normal (sign) depends on node ordering , is this guaranteed by SOFA convention, or should I verify it?

2. Choice of onSimulationInitDoneEvent
   Why onSimulationInitDoneEvent rather than another event (e.g., onAnimateBeginEvent)? I understand topology arrays aren't available until after init, but is this a general rule for all SOFA topology data? If forces changed every frame, would I switch to onAnimateBeginEvent?

3. @../ reference syntax
   @../GridTopology/grid goes up one level in the node tree. For deeper hierarchies, would I use @../../? Is there an absolute syntax (by node name) instead of relative?

4. Now that quads comes from SOFA, would upgrading to higher-order quadrature (e.g., 3×3 Gauss points) be straightforward in a future PR?

[th-skam]

I verified and tested the changes. Results match the previous version perfectly. The simplification is clean and well-structured.

These questions are to help me properly learn SOFA mechanisms for my upcoming contributions. Thanks in advance!

1. Node ordering in quads
   Do the quads from Hexa2QuadTopologicalMapping have the same node ordering as the ones I was building manually? The outward normal (sign) depends on node ordering , is this guaranteed by SOFA convention, or should I verify it?
2. Choice of onSimulationInitDoneEvent
   Why onSimulationInitDoneEvent rather than another event (e.g., onAnimateBeginEvent)? I understand topology arrays aren't available until after init, but is this a general rule for all SOFA topology data? If forces changed every frame, would I switch to onAnimateBeginEvent?
3. @../ reference syntax
   @../GridTopology/grid goes up one level in the node tree. For deeper hierarchies, would I use @../../? Is there an absolute syntax (by node name) instead of relative?
4. Now that quads comes from SOFA, would upgrading to higher-order quadrature (e.g., 3×3 Gauss points) be straightforward in a future PR?

1. I do not know whether you used the same convention or not.
   1.1. The quads result from the Hexa2Quad mapping and the origin mesh is created with the RegularGridTopology. Because of this, the unit normal vector is pointing outwards if your winding rule is right-handed. In SOFA, it is.
   • If you really want to geek a bit about this, you can see it in the SOFA GUI with a visual model. If you apply the visual model to the mapped node, it will show properly. However, if in the Hexa2QuadTopologicalMapping you invert the normals by setting flipNormals=1, you will see in the GUI that the surface is rendered dark (shaded) because the mapping flips the normals to point inwards.
2. There are 2 things to know here. First is the init function, part of every object in the scene graph. It is responsible for initializing Data members (such as positions, topology etc) and, generally speaking, setting up the components before the simulation begins. Second, the onSimulationInitDoneEvent is triggered right after the init function is called on every component. In order for us to work with the data we have to wait until init finishes. On the other hand, the onAnimateBeginEvent is triggered at the start of every time step. Given that this is a static simulation, we only need to distribute loads at the start and not in every time step. That's why we use only one called, right after the init has finished.
3. Yes, you would use @../../. For absolute path, you can use @Node1/Node2/
4. I don't know how straightforward this would be. Besides, for the 3x3 quadratures, most likely, you'll be needing the hexas.