- This topic has 8 replies, 2 voices, and was last updated 3 years, 8 months ago by
.
-
Posts
-
I have been studying the sofa framework for almost two weeks now. I have read the entire documentation and the sofa paper twice, studied many of the scene examples and studied parts of the source. Here are my thoughts:
- sofa is feature-rich and impressive. It is the work of many brilliant researchers over a decade. (You only have to look at the many academic publications written in the course of the development of sofa.) Sofa is also a gray box, meaning one can quickly get impressive results without being a domain expert in many complicated fields. This is perhaps the strongest selling point sofa has over many competing projects.
- A simulation in sofa can be created by defining a scene in one of the three ways (1) an XML scene file (with a file extension scn), (2) Python, or (3) C++ API. A beginner is more likely to interface with sofa via XML scene files.
- Regardless of how they are created, scenes do NOT describe the flow of data in a simulation, but rather register or declare components that will be “picked up” and used by sofa at runtime.
- The heartbeat of sofa is a cascading system of visitors that use the registered components to produce a simulation.
- As a result of the above, if you do not register the correct scene components you will not get the result you expect. And you will not know why.
- Furthermore, many scene components require other components. Again, if you do not declare the required components you will not get the result you expect. And as before you will not know why.
The last two points get to the heart of why I am struggling with sofa:
The number of sofa components is large and it is not clear which components are required in order to achieve a particular result. Furthermore the components required by each components is sparsely documented. I was able to glean a few from the documentation but many of these dependencies appear to be undocumented. I have been trying to work out these dependencies by looking at the examples and studying the visitors. Both approaches have been tedious and do not guarantee success.
I hope this post is not taken as a criticism of sofa but an attempt to highlight obstacles that beginners such as myself face.
I am willing to help with the documentation if anyone is willing to collaborate with me. I am also willing/able to write an XML schema that could be used to validate a user-autheored scene file e.g. for dependencies. For example if you create an implicit solver you also require a linear solver, linking to non-existent components etc. However the list of sofa components XML elements is also undocumented.
Dear @olumide
First of all, thanks a lot for all your input on the forum and sorry for the delay of my reply!
Your feedback and analysis are very valuable, and in no way it is a critism. We love such a constructive approach.
You understood well the forces and weaknesses of SOFA (versatile grey-box, altough laking of documentation).
Another interesting point: you captured the difference between the scene graph and the graph of data (invisible -for now- in SOFA). Congratulations for understanding all this!We currently are in the process of improving several of these weaknesses. Starting by the code organization (CMake project with many dependy issues), we work on changing the core of SOFA from a monolyth to a real modular core. Data dependency, documentation, performances are other topics that are / will very soon be addressed.
We would much appreciate help on the large documentation task. I would be glad to discuss further directly with you. Would you be open to this?
Best wishes,
Hugo
Hello @Hugo,
Thanks for your reply. I’ve been waiting for you to return from holiday 😉
I understand why sofa is designed the way it is. The goal is to avoid coupling components. (Therefore, sofa core calls the components, not the other way round.)
I would like to help with the documentation of sofa and am willing to collaborate with someone in order to do so. (It’s time I gave something back to an open source project.) As I said, IMO two possible contributions that would make the most impact to users right now are:
1. A detailed list and description of the various components, including the full list of parameters supported by each component, and any dependencies (aka other components) that the current components may have, and the circumstances in which those dependencies may be required. The list can be XML-centric but would be equally valid for Python and C++ APIs.
2. Using the information outlined above, it should be possible to write an XML schema that will check a sofa scene file for possible “issues”. My understanding is that the animation loop determines the visitors that will be activated and therefore the possible components that sofa will look for. Graphically, one can even show placeholders for the various components that the current animation loop will attempt to “look up”. Such a feature could provide a hint to users on what might be missing for their scenes. But this is an entirely different project.
I’ll send you a direct email.
Regards,
– Olumide
Dear @olumide
As said earlier, it’s good to see that you captured the big picture of SOFA.
Have you found some time to look at the “Components” section in the online documentation or the SofaComponents project ?Again, we would delighted to have you with us during our dev meetings.
Best wishes,Hugo
Hi @Hugo,
I have read through the Components section of the online documentation, and more recently SofaComponents, thanks.
I am thinking about how the documentation of the three animation loops can be expanded to show all components visitable, in order to illustrate the dependency and flow of data between components. If I find it useful I will share it with everyone. However, at the moment I am studying nonlinear finite element analysis. (Sadly, the problem that I hope to solve is multiple sources of nonlinearity; nonlinear materials, large deformation and, to make matters worse, ill-posed.)
I would love to join your dev meetings. Unfortunately the time clashes with my day job. Nevertheless I hope to join a session some day.
Regards,
– Olumide
Hey @olumide
Note that for each animation loop the graph traversal and its order are different. This is why this path the visitors is only described in the animation loop component pages (e.g. DefaultAnimationLoop see the flow diagram).
Non-linear FEA (involving non-linear materials as SOFA does) is always brought back to a linearized system to be solved. Only, several Newton steps will be required to compute it.
Sorry for the colliding time schedule of the dev meeting. Anyway, feel free to subscribe to the dev-mailing list to get all the dev reports.
Best
Hugo
Thanks @Hugo,
I have just subscribed to the dev list.
- You must be logged in to reply to this topic.
