[jnbrunet]

Hey Paul,

What you don’t see when you launch a python scene with runSofa is that the following things happen:

1. SOFA creates a root node
2. It calls the method createScene(root) of your script
3. And then, SOFA calls root.init() which will visit the root tree and call the init method on every components.

The last step is quite important as most SOFA components initialize their vectors/data fields during this “init” phase, and not during the creation of the object. There is ongoing work right now that aims at changing this behavior to better handle dynamic creation/modification of objects.

Fortunately, in SofaPython3 you are allowed to manually launch this “init” phase on any nodes you created:

def Marker(rootNode, name, pose):
    marker = rootNode.addChild(name)
    (...)
    marker.init() # recursively initialize components of the node tree
    print(marker.MechanicalObject.position.value)
    return marker

Hopefully this should solve your issue
J-N

[jnbrunet]

Hey @uljad,

Great that you finally found SOFA and its awesome community 🙂

Unfortunately, as far as I know, CutFEM isn’t implemented in SOFA (or has not been made public). This would be a very cool feature, and if you are working on this, I’m sure a CutFEM plugin for SOFA would be much appreciated by many here.

There has been some work on fictitious domain methods (like CutFEM) on hexahedral meshes that are cut by an immersed boundary. You can look at the HexahedronCompositeFEM component which does a homogenization pass on a (coarse) grid using finer grids to compute the stiffness of each cut elements. I think there is an example in sofa/example/components/forcefield.

Hope that helps.
J-N

[jnbrunet]

Hey @younesssss,

This is weird, I’m able to find them on my side. Can you give me the output of

1. find /home/younes/travail/plugin/SoftRobotsOnTheWeb/src/tools/docker/install -name "libSofaMeshCollision*"

and

2. git rev-parse --short HEAD

J-N

[jnbrunet]

Hey @scharreyron,

Looking at your crash trace, the faulty one seems to be

4 com.apple.HIToolbox 0x00007fff31d80c29 _HIPersistentUICreatePersistentWindow + 69 (or the 2-3 lines before)

Searching for _HIPersistentUICreatePersistentWindow on google seems to point out different users that got similar errors. Unfortunately, they all seems to be fixing it by upgrading/reinstalling their system. Looks like an error coming from a user configuration of some sort. Do you sometime get similar crashes when opening applications other than runSOFA?

Could you try upgrading your softwares? If this doesn’t work, maybe try to compile SOFA yourself (there is a good guide here).

If it is still not working out, I guess a system update/reinstall could be needed 🙁

Unfortunately, from the quick google search and the fact that you seems to be the only one having this problem with SOFA, I don’t think we will easily find the source of the error.

If you can, keep us updated on your progress.

J-N

[jnbrunet]

Hey Sukhraj,

Glad that you are trying out SOFA!

The VTKExporter works by looking in its context (the <Node></Node> that contains it) in order to find a topology container ( [.*]SetTopologyContainer). It will then write the elements found in this topology.

Looking quickly at your scene, you should probably move the VTKExporter to get something like this:

<?xml version="1.0"?>
<Node name="root" dt="0.05" showBoundingTree="0" gravity="0 -9 1">
    <VisualStyle displayFlags="showVisual" />
    <RequiredPlugin pluginName="CGALPlugin"/>

    <MeshObjLoader name="loader" filename="mesh/test.obj" />

    <Node name="visu_surface">
        <MechanicalObject name="dofs" position="@../loader.position"/>
        <TriangleSetTopologyContainer name="topo" triangles="@../loader.triangles"/>
        <TriangleSetTopologyModifier   name="Modifier" />
        <TriangleSetTopologyAlgorithms name="TopoAlgo"   template="Vec3d" />
        <TriangleSetGeometryAlgorithms template="Vec3d" name="GeomAlgo" drawTriangles="1" />
    </Node>

    <Node name="tetra_mesh">
        <MeshGenerationFromPolyhedron name="MeshGenerator" inputPoints="@../loader.position" inputTriangles="@../loader.triangles" inputQuads="@../loader.quads"/>
        <MechanicalObject name="dofs" position="@MeshGenerator.outputPoints"/>
        <TetrahedronSetTopologyContainer name="topo" tetrahedra="@MeshGenerator.outputTetras"/>
        <TetrahedronSetGeometryAlgorithms template="Vec3d" name="GeomAlgo" drawTetrahedra="1" drawScaleTetrahedra="0.8"/>
        <VTKExporter name="exporter" filename="test_out" XMLformat="1" edges="0" tetras="1" listening="true" exportAtBegin="true" overwrite="true"/>
    </Node>
</Node>

Note that I removed the cellsDataFields attribute, as it isn’t used to stored the mesh topology, but rather some “field values” that you would like to store for each elements (cells).

Hope that helps.
J-N

[jnbrunet]

Hey @stonkens,

I haven’t worked with STLIB, therefore I cannot really say what have or have not been migrated from SofaPython to SofaPython3.

For these particular types, it seems there are some bindings in the SofaTypes modules.

$ python3
>>> import SofaTypes
>>> print('\n'.join(dir(SofaTypes)))
Mat1x1
Mat2x2
Mat3x3
Mat3x4
Mat4x4
Quat
SofaTypes
Vec10d
Vec10i
Vec11d
Vec11i
Vec12d
Vec12i
Vec1d
Vec1i
Vec2d
Vec2i
Vec3d
Vec3i
Vec4d
Vec4i
Vec5d
Vec5i
Vec6d
Vec6i
Vec7d
Vec7i
Vec8d
Vec8i
Vec9d
Vec9i

>>> help(SofaTypes.Quad)
Help on class Quat in module SofaTypes.SofaTypes:

class Quat(pybind11_builtins.pybind11_object)
 |  Method resolution order:
 |      Quat
 |      pybind11_builtins.pybind11_object
 |      builtins.object
 |  
 |  Methods defined here:
(...)
 |  __init__(...)
 |      __init__(*args, **kwargs)
 |      Overloaded function.
 |      
 |      1. __init__(self: SofaTypes.SofaTypes.Quat) -> None
 |      
 |      2. __init__(self: SofaTypes.SofaTypes.Quat, x: float, y: float, z: float, w: float) -> None
 |      
 |      3. __init__(self: SofaTypes.SofaTypes.Quat, arg0: SofaTypes.SofaTypes.Quat) -> None
 |      
 |      4. __init__(self: SofaTypes.SofaTypes.Quat, axis: sofa::defaulttype::Vec<3, double>, angle: float) -> None
 |      
 |      5. __init__(self: SofaTypes.SofaTypes.Quat, arg0: list) -> None
 |      
 |      6. __init__(self: SofaTypes.SofaTypes.Quat, vFrom: sofa::defaulttype::Vec<3, double>, vTo: sofa::defaulttype::Vec<3, double>) -> None
|  axisToQuat(...)
 |      axisToQuat(self: SofaTypes.SofaTypes.Quat, a: sofa::defaulttype::Vec<3, double>, phi: float) -> SofaTypes.SofaTypes.Quat
 |  
 |  buildRotationMatrix(...)
 |      buildRotationMatrix(self: SofaTypes.SofaTypes.Quat, arg0: SofaTypes.SofaTypes.Mat4x4) -> None
 |  
 |  clear(...)
 |      clear(self: SofaTypes.SofaTypes.Quat) -> None
 |  
 |  fromFrame(...)
 |      fromFrame(self: SofaTypes.SofaTypes.Quat, x: sofa::defaulttype::Vec<3, double>, y: sofa::defaulttype::Vec<3, double>, z: sofa::defaulttype::Vec<3, double>) -> None
 |  
 |  fromMatrix(...)
 |      fromMatrix(self: SofaTypes.SofaTypes.Quat, m: SofaTypes.SofaTypes.Mat3x3) -> None
 |  
 |  identity(...)
 |      identity() -> SofaTypes.SofaTypes.Quat
 |  
 |  inverse(...)
 |      inverse(self: SofaTypes.SofaTypes.Quat) -> SofaTypes.SofaTypes.Quat
 |  
 |  inverseRotate(...)
 |      inverseRotate(self: SofaTypes.SofaTypes.Quat, v: sofa::defaulttype::Vec<3, double>) -> sofa::defaulttype::Vec<3, double>
 |  
 |  normalize(...)
 |      normalize(self: SofaTypes.SofaTypes.Quat) -> None
 |  
 |  quatToAxis(...)
 |      quatToAxis(self: SofaTypes.SofaTypes.Quat, a: sofa::defaulttype::Vec<3, double>, phi: float) -> None
 |  
 |  rotate(...)
 |      rotate(self: SofaTypes.SofaTypes.Quat, v: sofa::defaulttype::Vec<3, double>) -> sofa::defaulttype::Vec<3, double>
 |  
 |  set(...)
 |      set(self: SofaTypes.SofaTypes.Quat, x: float, y: float, z: float, w: float) -> None
 |  
 |  size(...)
 |      size() -> int
(...)

There is not so much documentation on those classes, but I guess you can easily infer their functionalities from their method names and arguments.

Hope that helps !
J-N

[jnbrunet]

Pull request is here.

We need to wait for the tests to pass and a review before merging the fix, but you can already checkout the PR’s branch. SofaPython3’s master branch should compile correctly with this fix on SOFA.

[jnbrunet]

Hey @stonkens,

You are not the only one having this issue, it seems I also have it. Looks to be caused by a recent change merged yesterday in the master branch of SOFA.

SOFA has been undergoing a lot of refactoring these past weeks, its compilation and the one of the plugins are a little bit unstable at the moment.

I’ll look into it and and update this thread once I’ve made a PR fixing it (probably tomorrow).

J-N

[jnbrunet]

Hey @stonkens,

Unfortunetly, the SofaPython3 plugin is following closely the master branch as it does not had an official release yet.

However, for this particular problem you have, it looks quite close to this thread.

You can deactivate the build of tests on SofaPython3 by setting the cmake variable SP3_BUILD_TEST=OFF.

JN

[jnbrunet]

Hi Owen,

Looks like the CGAL plugin is compiling with the c++11 standard, whereas the version of CGAL on ubuntu 20.04 (CGAL v5.0) is using c++14 features.

I’m guessing you are using the last stable version of SOFA (19.12)? This version set the c++ standard to c++11. This has changed in the development version, the next stable release of SOFA will be using c++17.

Meanwhile, you could:

1. Install an older version of CGAL (you can look on the CGAL website to learn how to get the source code and build/install it)

2. Or, you can manually specify your compiler to use the c++14 standard by editing the file sofa/applications/plugins/CGALPlugin/CMakeLists.txt, and anywhere after the add_library(${PROJECT_NAME} ...) (line 94 on the v19.12 source code), add the following :

target_compile_features(${PROJECT_NAME} PUBLIC cxx_std_14)

JN

[jnbrunet]

Hi @stonkens,

You can have a look at this thread, it should help you to set things right.

Let me know if you still have problem after this.
JN

[jnbrunet]

Hi Owen,

I’m not seeing any error message in your compilation output, only warnings. Did you truncate it?

JN

[jnbrunet]

Hi @amir,

It seems to be the tests of SofaRobots that are failing to link.

Edit the file SoftRobots/tests/CMakeLists.txt, at line 26 you will find something like:

target_link_libraries(${PROJECT_NAME} SofaTest SofaGTestMain SoftRobots SofaCore SofaConstraint SofaBaseMechanics SofaUserInteraction SofaComponentCommon)

Remove that SofaComponentCommon from there and replace it with SofaCommon.

If it solves your problem, don’t hesitate to create an issue on the github of SofaRobots

J-N

[jnbrunet]

Hi @eaparra

Looks like you are missing a package: sudo apt install libcgal-qt5-dev

If the problem persists, then you might have 2 versions of CGAL installed at the same time (maybe you installed it first by compiling it and doing sudo make install, and later on by doing sudo apt install libcgal-dev?).

J-N

[jnbrunet]

Hey @hugo,

Nice find!

Do you think we could add some documentation (maybe here) on these integration factors? In fact, all of those methods that need to be overridden by ODE solvers:

double OdeSolver::getPositionIntegrationFactor (int /*inputDerivative*/, int /*outputDerivative*/);
double OdeSolver::getSolutionIntegrationFactor (int /*outputDerivative*/);
double OdeSolver::getVelocityIntegrationFactor();
double OdeSolver::getPositionIntegrationFactor();

are very difficult to grasp…and the doxygen isn’t super clear.

Jean-Nico

[jnbrunet]

Hi @sarah

My guess would be that inflating a cube is a hard problem due to the sharp edges of the cube. To help it, you would probably need to “bevel” these edges so that you get a gradient of pressure normal between two of the cube’s faces.

Meanwhile, you can swap the LDLSolver to a CG solver that will be able to approximately solve your system, even if it is not well formed.

I’ve adapt and simplified your scene so that you can experiment things:

http://collabedit.com/eqk4h

If you turn on the printLog of the StaticSolver, you will see that your system never fully converge at each time step, but still eventually converge to a stable inflated state.

You could try with a sphere instead of a cube, you might have better convergence and might be able to swap back that LDLSolver.

Jean-Nicolas

[jnbrunet]

Hi @sarah,

Such behavior can come from multiple factors. To me, this clearly look like you are trying to solve an underdetermined system. By looking rapidly at your scene file, here’s what I would try, in order:

1. For the surface mesh on which you are applying pressure, try to use a subset of the trianglular faces from your tetrahedron mesh. This will remove the need for a barycentric mapping. Applying pressure on triangles that do not match their underlying tetrahedron’s faces can create regions of surface that have more, or less, of applied load than other surface regions. This will result in an non-uniform applied load, and therefore unbalanced system of you are not using boundary conditions.

2. Linear tetrahedrons, especially when used with a high value of Poisson ratio, can result in shear and pressure locking. If you can, use a hexahedral mesh which are tri-linear and suffer less from this phenomenon. If you can’t, than try to lower your Poisson ratio.

3. The corotational methods of Sofa are rough approximations of a real rotation extraction method. This can result in a badly conditioned matrix. Try to use a real geometric non-linear material such as those provided by the TetrahedronHyperelasticityFEMForceField component.

If your cube is rotating while applying pressure on the complete surface, I would really try my #1 suggestion first, as to me it is a strong sign of unbalanced applied load.

Jean-Nicolas

[jnbrunet]

Hi @pasquale94

Is it possible in SOFA to associate to each TetraHedron of the mesh topology an entire stress-strain curve?

Creating a new stress-strain curve would require you to implement your own ForceField. The TetrahedronFEMForceField can only represent the linear elasticity curve. When you set the method=”large” option, it extracts the rotational part of the strain before computing the stress, but it remains a linear elasticity curve.

There are more advanced stress-strain curves for hyperelasticity within the TetrahedronHyperelasticityFEMForceField component. You can have a look at the example file
“examples/Components/forcefield/TetrahedronHyperelasticityFEMForceField.scn“. Unfortunately, authors of this component did not give any documentation on how to correctly set material parameters. I can only say that the parameters of the StVenantKirchhoff, NeoHookean and ArrudaBoyce materials are given with ParameterSet=”mu lambda” where mu and lambda are the standard Lame’s coefficient.

Now, both TetrahedronFEMForceField and TetrahedronHyperelasticityFEMForceField components are applying a stress-strain curve to an entire subdomain of tetrahedrons. Nothing prevents you to create multiple of those force fields within the same node and assign each one with a different tetrahedron set container. Something like

<Node>
  <MechanicalObject />
  <TetrahedronSetTopologyContainer name="domain1" />
  <TetrahedronHyperelasticityFEMForceField ParameterSet="mu0 lambda0" materialName="StVenantKirchhoff" topology="@domain1"/>

  <TetrahedronSetTopologyContainer name="domain2" />
  <TetrahedronHyperelasticityFEMForceField ParameterSet="mu1 lambda1" materialName="StVenantKirchhoff" topology="@domain2"/>
</Node>

In any cases, creating new materials is not something very straightforward in Sofa. We are working on simplifying this process and allow people to easily create new curves.

Jean-Nicolas

[jnbrunet]

Hey @simon ,

Can you create a very simple python scene file with the following:

info.py

import sys
def createScene(root):
    print(sys.prefix)
    print(sys.executable)
    print(sys.path)

Then run it with runSofa and give us the output?

[jnbrunet]

Hi @timp,

Sofa is a framework that can be compiled without GUI, I just wanted to make sure that you compiled the GUI part since Sofa.Gui.GUIManager.ListSupportedGUI returned you an empty string.

I am unsure why you cannot get the GUI running from python, but in any cases, starting the Sofa’s GUI from the python script is probably not a good idea. It will simply steal the thread from python and resume it once you close the GUI. If you want a GUI, you are better off just starting the GUI directly with the runSofa executable (sofa/build/bin/runSofa) and open your python scene from there.

[jnbrunet]

Did you compile Sofa with the GUI support?

If you go inside your Sofa’s build directory, what is the output of
grep "SOFAGUI_.*VIEWER" CMakeCache.txt

[jnbrunet]

Hey @timp

My mistake, it is from Sofa import Simulation, and not from Sofa.Core import Simulation.

However, it seems there is a binding error on the return type of the Simulation.load(filename) call. I’ll look into it.

For now, if you want to load this scene, first remove the line
confignode.addObject('RequiredPlugin', name="SofaPython3", printLog=False)
from the ReadTheDocs_Example.py file, go in the example directory and do something like:

$ python3
>>> import Sofa
>>> import Sofa.Gui
>>> import Sofa.Simulation
>>> import SofaRuntime
>>> from ReadTheDocs_Example import createScene
>>> SofaRuntime.importPlugin('SofaOpenglVisual')
>>> root = Sofa.Core.Node()
>>> createScene(root)
>>> Sofa.Simulation.init(root)
>>> Sofa.Gui.GUIManager.Init("example", "qglviewer")
>>> Sofa.Gui.GUIManager.createGUI(root)
>>> Sofa.Gui.GUIManager.SetDimension(1080, 1080)
>>> Sofa.Gui.GUIManager.MainLoop(root)

[jnbrunet]

Hi @Tim,

When you start a scene with the runSofa executable, Sofa looks inside the path “../lib” relative to the runSofa executable path in order to find its core plugins.

When you load Sofa inside a python interpreter, Sofa has no idea where its core plugins are, since the only path it knows is the path of the python executable (/usr/bin/python3).

You can provide the path to Sofa’s plugins by either:

1. Set the environment variable SOFA_ROOT to the location of your Sofa build directory (ie, you should be able to find the Sofa’s plugins in $SOFA_ROOT/lib).

$ export SOFA_ROOT=/home/tim/sofa/build
$ python3
>>> import SofaRuntime
>>> from Sofa.Core import Simulation
>>> root = Simulation.load("scene.py")
>>> root.init()

or

2. Manually add the libraries path to the PluginRepository :

$ python3
>>> from SofaRuntime import PluginRepository
>>> from Sofa.Core import Simulation
>>> PluginRepository.addFirstPath("/home/tim/sofa/build/lib")
>>> root = Simulation.load("scene.py")
>>> root.init()

or

3. Use the AddPluginRepository component in your scene
<AddPluginRepository path="/home/tim/sofa/build/lib" />

[jnbrunet]

Hey @bobiko,

The Sofa’s libraries cannot automatically know what is your Sofa’s installation path, hence where the core plugins are located.

You can help them find it with the environment variable “SOFA_ROOT”, for example, if you built Sofa in the directory /home/bobiko/sofa/build:

$ export SOFA_ROOT=/home/bobiko/sofa/build
$ ./hystsim

Or by manually add the Sofa’s library path to the Plugin repository in your program:

main.cpp

sofa::helper::system::PluginRepository.addFirstPath("/home/bobiko/sofa/build/lib");
sofa::helper:system::PluginManager::get_instance().loadPlugin("SofaOpengVisual");

Hope that helped

[jnbrunet]

@Hugo no need 😉

https://github.com/SofaDefrost/plugin.SofaPython3/pull/149

[Author]

Posts