[jnbrunet]

Hey @geofliu,

Are you using python 2 or python 3?

If you are using python 3 and its matching plugin SofaPython3, there are some issues with stlib3 and SofaPython3 that remains to be fixed. See for example

Issues with running examples on SOFA_v20.12.02_Defrost_Linux

Missing libraries: STLIB and libSofaPython

Python scene errors

I’m not sure what is the current state or future plans with respect to the compatibility of softrobots/stlib(3) and SofaPython3. With the upcoming SOFA release v21.06, maybe @guillaumeparan or someone from the consortium or defrost team could tell you a bit more.

[jnbrunet]

Hey @benjamin,

It looks like this component stores its spring parameters at the beginning of the simulation and does not automatically update them when the stiffness data field changes.

Can you try manually calling the “reinit” method of the object just after changing its stiffness? Something like:

self.LSrtgFF.stiffness=str(self.SpringStiffness)
self.LSrtgFF.stiffness.reinit()

[jnbrunet]

Well, everything on the SofaPython3 plugin seems fine. My guest would be that the SoftRobot plugin from the Defrost team hasn’t been completely migrated from SofaPython(2) to SofaPython3.

Maybe @hugo have more insight from the Defrost team on this migration state? I guess this will be a topic in the STC#11 next week.

[jnbrunet]

Hi @mohshaw,

It looks like python is able to find stlib3 from what you showed me (the last line of the output).

Make sure you export the following just before starting runSofa (in the same terminal) :

$ export SOFA_ROOT=/home/mohshaw/Downloads/SOFA_v20.12.02_Defrost_Linux/SOFA_v20.12.00_Linux
$ export PYTHONPATH="$SOFA_ROOT/plugins/SofaPython3/lib/python3/site-packages:$SOFA_ROOT/plugins/SoftRobots/lib/python3/site-packages:$SOFA_ROOT/plugins/STLIB/lib/python3/site-packages:$PYTHONPATH"
$ $SOFA_ROOT/bin/runSofa -l SofaPython3

[jnbrunet]

Hi @mohshaw,

It looks like the python interpreter embedded inside the SofaPython3 plugin isn’t able to find the stlib3 python module. Can you try execute the following and give me the output (make sure the first command has a valid path to your SOFA installation):

$ export SOFA_ROOT=/home/mohshaw/Downloads/SOFA_v20.12.02_Defrost_Linux/SOFA_v20.12.00_Linux
$ [ -f $SOFA_ROOT/bin/runSofa ] && echo "Path is good" || echo "Path is not good" 
$ export PYTHONPATH="$SOFA_ROOT/plugins/SofaPython3/lib/python3/site-packages:$SOFA_ROOT"
$ which python3.7
$ export PYTHONPATH="$SOFA_ROOT/plugins/SofaPython3/lib/python3/site-packages:$SOFA_ROOT/plugins/SoftRobots/lib/python3/site-packages:$SOFA_ROOT/plugins/STLIB/lib/python3/site-packages:$PYTHONPATH"
$ python3.7 -c "import sys; print('\n'.join(sys.path))"
$ python3.7 -c "import SofaRuntime;print(SofaRuntime);import softrobots;print(softrobots);import stlib3;print(stlib3)"

[jnbrunet]

Hey @baymin,

It is not currently possible. We would need to add python bindings allowing us to call :

BodyPicked point = GUIManager::getGUI()->getViewer()->getPickHandler()->getLastPicked();

This should not be too complicated:

1. Add python bindings for the BaseViewer class, especially the getPickHandler method
2. Add the getViewer() methods to the already existing bindings of BaseGui.
3. Add python bindings for the PickHandler class, especially the getLastPicked() method.
4. Add python bindings for the BodyPicked class, especially these members:

    sofa::core::behavior::BaseMechanicalState *mstate;
    sofa::Index indexCollisionElement;
    defaulttype::Vector3 point;
    SReal dist;
    SReal rayLength;

It would be a good addition to the SofaPython3 plugin, if you or somebody else is up to the challenge (maybe @hugo has an idea here). I can provide help and guidance without issue.

J-N

[jnbrunet]

Hey @amir,

I think you have to install libopengl0:

sudo apt install libopengl0

See here for a reference.

JN

[jnbrunet]

I think applyElasticityTensor is more tricky than what you described.

Could be, but looking quickly on how it is used, i.e. called 3 times (1 per coordinates), this looks a lot like a kind of “optimization” to compute where is the 6×3 strain variation matrix. It is like the applyElasticityTensor computes the product with one column (one coordinate) of . We could probably check this by comparing/printing it against the caribou forcefield since both of them produce exactly the same stiffness matrix (I validated it).

I understand your point 2, but I think the code in TetrahedronHyperelasticityFEMForceField did not compute K_ii in updateTangentMatrix (maybe I’m wrong…).

Yeah it only computes the upper part of the diagonal matrix (K_ij with i!=j). The K_ii coefficients should be the accumulation of each “edges” connected to the node “i”. So no need to compute/store it.

Anyway, maybe there is no need to dig it in more detail, as I think Caribou is an excellent replacement. Actually I’ve read the code of Caribou these days, and the way you did in HyperelasticForcefield is clear and tide. It follows the standard and generic approach and is a very good reference on how to write a decent hyperelastic model in SOFA.

Thanks a lot ! There is still a lot of work to do, but I very happy to learn that it is still useful to some people 🙂

When I compile it with the latest version of SOFA(and in-tree build of SofaPython3), it shows the following errors

Hum I’m not sure, it looks like a SOFA compilation error… Can you re-post your error here so we can look at it together without polluting this forum? It will also be a good occasion to create the first github discussion on the caribou repo 😉

[jnbrunet]

Hey @nicklj,

The TetrahedronHyperelasticityFEMForceField has, well, an interesting implementation design… And certainly not very intuitive. If you want to see another implementation of a hyperelastic forcefield which is a little bit more intuitive, I invite you to have a look at the HyperelasticForcefield of the plugin Caribou.

Anyway, going back to your questions, it will be easier if we use some equations. Lets take the Saint-Venant-Kirchhoff material as an example. We have

Where is the Green strain tensor.

1. I believe the applyElasticityTensor(tetinfo, params, input, output) function computes the product where the tilde denotes the Voigt notation, i.e is a 6×6 matrix (symmetric part of a fourth order tensor) and is a 6×1 vector (symmetric part of a second order tensor). This function is therefore probably used to compute the non linear part of the elemental tangent stiffness matrix (see equation 2.24 of my thesis for a quick reference).

2. It stores it on the “edge” because the stiffness matrix is symmetric for a hyperelastic material, i.e. . Hence no need to compute both and . In this very specific case, i.e. a linear tetrahedral element, every pair of nodes (i,j) is also a geometrical edge. This is not the case with hexahedral elements, for example. Again, have a look at the HyperelasticForcefield of the plugin Caribou to see how this is done with a more generic approach (compatible with every isoparametric elements).

I hope that helps a little bit !
J-N

[jnbrunet]

Yeah, for the moment only a (full) Newton-Raphson is implemented, which means that the system matrix is assembled and inverted at each Newton steps.

There is work being done right now to unify the NR solver for all ODE solvers (static and dynamic). Once this is finished, I’m pretty sure a line search and BFGS could follow closely.

[jnbrunet]

Hey @olumide,

Boundary and non-boundary terms are treated the same way in SOFA: it is up to the component to assemble a force vector and its jacobian (in the case the force depends upon the deformation), and feed them to the ODE solver. If your force was constant, then you could have used the ConstantForceField component to give the nodal forces directly in your XML file. However, since yours isn’t constant, you need to provide its jacobian matrix and a way to update the force at each time step (or load increment).

J-N

[jnbrunet]

Hey @olumide,

Yes, the static solver is in fact a Newton-Raphson iterative solver. It can therefore solve any deformation dependent forces, either linear or non-linear with respect to the displacement u(x).

You will have however to implement this load force f(u) manually by creating a new SOFA ForceField“. Moreover, you will have to override three methods of the force field:

addForce(f, x, v): This function fills up the f force “vector”, which is in fact a nx3 matrix containing n nodal force vectors (1×3) for a mesh having n nodes. Here, the parameter x is a nx3 “vector” containing the current positions of the nodes, and “v” contains the nodal velocities.

addKToMatrix(A, k): This function adds the jacobian matrix J of your load force to the matrix A (times a scalar value k, i.e. A += k*J). It therefore computes the derivative of f(u) with respect to the displacement vector field u evaluated at the current displacement u_i: J(u_i) = dF(u_i) / du, where i is the current Newton iteration number.

Finally, addDForce(df, dx) simply computes df = J*dx where againJ is the same jacobian matrix computed in addKToMatrix.

J-N

[jnbrunet]

Hum, I’m not sure what’s going on here. If forcefields and OglModels are rendering, to me this means that everything is fine on the visual pipeline.

Can you try to debug your component to make sure it succeed to get to the rendering calls? For example, you could put a quick debug message inside the draw() method of the component just before calling vparams->drawTool()->drawXXX(). Does it get there? Or does it get stopped by some if(...) before calling the drawTool?

[jnbrunet]

Hey Andrea,

Does it render something or is it just black? Like, can you see forcefields and OglModels being drawn?

Does it help if you add Sofa.Simulation.initVisual(root) after Sofa.Simulation.init(root)?

J-N

[jnbrunet]

Hey Arnaud,

Where is the library that you downloaded from the pardiso’s website? It should look like “libpardiso(…).so”.

Once you find it, you need to put this path into the cmake variable “PARDISO_LIB”. For example, on my PC, I do:

cmake -DPARDISO_LIB=/opt/libpardiso600-GNU800-X86-64.so ..

J-N

[jnbrunet]

Hey Andrea,

Are you sure you are using the same GUI (qt vs qglviewer) for both python and runSofa?

Can you show us the part of your code that creates the root node, initializes it and starts the GUI?

[jnbrunet]

Hey Michael,

When you use the python interpreter, SofaPython3 has no easy way to determine where is installed your SOFA. For this purpose, when SOFA tries to look for plugins, it check if the environment variable SOFA_ROOT exists. If it is the case, it will look into SOFA_ROOT/plugins to find its plugins.

Could you try again setting SOFA_ROOT to your SOFA installation path?

For example:

$ export SOFA_ROOT=/your/path/to/sofa/build/install
$ python ~/SofaPython3/examples/emptyForceField.py

J-N

[jnbrunet]

Hi Pho,

Did you remove your pybind11 previously installed by anaconda? Looks like this file should exists:

/home/pho/anaconda3/share/cmake/pybind11/pybind11Config.cmake

Is this still the case?

In any case, I would suggest you install pybind11 using your system package manager instead of anaconda:

# Ubuntu
$ sudo apt install pybind11-dev

# Fedora
$ sudo dnf install pybind11-devel

# MacOS
$ brew install pybind11

[jnbrunet]

Hey Pho,

Something does not seems right here.

First, concerning your first question, you should not have to add $SOFA_BLD/install/plugins to the cmake prefix path, as this should already be done by the SOFA’s cmake macro. I’m guessing you are on the master branch of SofaPython3, while being on the v20.12 branch of SOFA, since the pluginization of SofaSimulationGraph didn’t make it in the release, hence the cmake error. You need to checkout v20.12 on SofaPython3 as well.

Next, how is cmake able to output you the version and path of pybind11 if he cannot find it? My guest is that you had previously manually set the cmake path of pybind11 since the latter isn’t installed in a standard path (anaconda) and cmake probably has no idea it exists there.

Could you try the following:

$ cd ~/Desktop/plugin.SofaPython3
$ git checkout v20.12
$ rm -rf build && mkdir build
$ cd build
$ cmake -DCMAKE_PREFIX_PATH="$SOFA_BLD/install/lib/cmake;/home/pho/anaconda3/share" ..

And let us know how it goes.

J-N

[jnbrunet]

Let’s see…

+ Github will now be responsible for handling spam,
+ Advanced markdown for formatting our post,
+ Mobile friendly interface,
+ Automatic links to github issues, PR and users,
+ Advanced search functions,
+ Inserting images into our posts by drag&drop,
+ Preview before posting

Yes, let’s move to Github !

[jnbrunet]

Hey Peter,

I just answer a similar question here: https://www.sofa-framework.org/community/forum/topic/sofapython3-pygame-rendering-example-not-working/#post-18513

Let me know there if you have any further questions.

J-N

[jnbrunet]

Hey @beichun

We removed this example since it was broken and to fix it would required us to pull GUI dependencies from SOFA into the bindings of sofa::simulation only to initalize GL (see here).

For now, if you want to make it work, you can create c++ bindings that does just that: initialize glew and call sofa::simulation::draw() whenever you need the scene to be draw in your qt context.

There has been a recent PR here that isolate OpenGL code from SOFA into a single module. It would therefore be possible to add bindings for this specific module in SofaPython3 without creating a dependency between the binding of sofa::simulation and OpenGl. This is however not in our development plan for SP3 and would require someone from the community to spend some of its time on this.

I hope that answers your question.
J-N

[jnbrunet]

Hey Andrea,

Well, we went a little bit further 🙂

Moreover, I need to update the background image at every time step so I will also have to call setBackgroundImage() inside my functions…

This is not a problem since the important thing is that setBackgroundImage() is called after Sofa.Gui.GUIManager.Init(). Events such as onBeginAnimationStep() are usually handled by your controller after the initialization of the GUI. You probably got the currentGui == None if you tried to get it in your createScene function since it is called before the init GUI.

Also note that if I use Sofa.Gui.GUIManager.createGUI(root) (without __file__) I get the following error:
[SofaRuntime] RuntimeError: basic_string::_M_construct null not valid

Yeah, this is already known, the second argument is mandatory and we should handle this better.

Finally,

Still not working. If I run what you suggested I get the following warning:

[SofaViewer] Could not create file ‘path_to_my_image/img.png’
Valid extensions: dds

and there is no background image.

(…)

If I only run

Sofa.Gui.GUIManager.Init(“scene”, “qglviewer”)
Sofa.Gui.GUIManager.createGUI(root, __file__)

I get a similar warning:

[SofaViewer] Could not create file ‘/home/andrea/Projects/sofa/share/textures/SOFA_logo.bmp’
Valid extensions: dds

This is because extensions other than dds (jpeg, png, tiff and bmp) are handled by the CImg plugin. Simply add a

root.addObject('RequiredPlugin', name='CImgPlugin')

In your createScene function.

Let me know how that worked out.
J-N

[jnbrunet]

Hey Andrea,

You need to call this function after the GUI has been created:

Sofa.Gui.GUIManager.Init("scene", "qglviewer")
Sofa.Gui.GUIManager.createGUI(root)
# ---> HERE <----
# Get the current BaseGui instance
current_gui = Sofa.Gui.GUIManager.GetGUI()

# Change the background image
current_gui.setBackgroundImage("image.png")
# ----------------
Sofa.Gui.GUIManager.MainLoop(root)

Let me know if this is working or if you face other issues.

J-N

[jnbrunet]

Hey Andrea,

Looking at your output, it looks like the setBackgroundImage() is looking for a BaseGui as first argument. This is similar to the “self” argument you usually find inside class methods in python. Hence this is a method which should be called from an instance of BaseGui, and not a static function that you can call directly.

Could you try the following:

# Get the current BaseGui instance
current_gui = Sofa.Gui.GUIManager.GetGUI()

# Change the background image
current_gui.setBackgroundImage("image.png")

J-N

[Author]

Posts