[jnbrunet]

Hey Juan José,

You are right, it is not simple to have a global idea of the available components and their templates/datas. In my case, I always have the source code of Sofa close and look at the constructors of the component for which I want to see their data. The available templates are usually in the .cpp of the component (looking for RegisterObject calls).

I think it would not be too hard to implement a python bindings that look through the object factory of Sofa and gives you the list of registered components and their template, I’ll have a look at this.

For the data values requiring a list, it is up to you to give a string or a list. For example, both

node.addObject("GridMeshCreator", resolution="2 2")

and

node.addObject("GridMeshCreator", resolution=[2,2])

should work.

Thanks for your feedback !

[jnbrunet]

Hi @jjcasmar

Make sure you are including the following header:

#include <sofa/core/MultiMapping.inl>

(note the ‘.inl’ file extension here)

[jnbrunet]

You could use a subset mapping for this. Here is an example to visually track nodes number 1, 5, 25 and 40 from a given scene:

<node name="mechanical">
    <MechanicalObject position="@mesh.position" />
    <!-- (...) -->
    <node name="tracking">
        <MechanicalObject showObject="true" showObjectScale="5" showColor="1 0 0 1" />
        <SubsetMapping indices="1 5 25 40" />
    </node>
</node>

[jnbrunet]

Are you sure it is a python-related error? The same scene with a .scn file works?

[jnbrunet]

Hi Harris,

Could you post the link errors from your compilation output?

[jnbrunet]

Hi Wong,

The “get” function from the Context class only search for components contained inside a Node, but not the nodes themselves. Unfortunately, I don’t think such search function for nodes exists. You can however convert your current context to a “DAGNode”:

#include <SofaSimulationGraph/DAGNode.h>
auto DNode = dynamic_cast<const sofa::simulation::graph::DAGNode *> (context);

And then, use the following methods from your DAGNode to traverse the simulation tree:

sofa::helper::vector< BaseNode* > getParents() const override;
BaseNode* getFirstParent() const;
sofa::helper::vector< BaseNode* >  getChildren() const override;
bool hasTag( Tag t ) const;
const TagSet& getTags() const;

Hope this helps,
Jean-Nicolas

[jnbrunet]

CGAL 4.12+ now forward declares its package Polyhedron (see CGAL/cgal@76ccc9a , hence the implicit instantiation of undefined template compilation error you see here.

I’ve added a PR to fix this : https://github.com/sofa-framework/sofa/pull/812

Until then, you can simply add the following line
#include <CGAL/Polyhedron_3.h>

At the beginning of the file
applications/plugins/CGALPlugin/TriangularConvexHull3D.inl

[jnbrunet]

There is a compilation issue with the current Sofa CGALPlugin and the CGAL library versions 4.10+

I’ve just submitted the following PR to fix it : https://github.com/sofa-framework/sofa/pull/783

Until the PR is merged, you can try to manually add the changes from the PR into your Sofa’s source code.

[jnbrunet]

Hey @Hugo

Tetra2TriangleTopologicalMapping will be able to retrieve the surface mesh. In fact, it will retrieve the triangles that only got one tangent tetrahedron. If this is your case,
Tetra2TriangleTopologicalMapping is good enough to get the surface representation. The MeshExporter will then find the mesh topology in the context of the exporter’s object. You can then toggle which elements you want exported.

As for the ObjExporter, it will export the triangles only if a VisualModel can be found. I don’t think there is one better than the other, they both inherits from the same base exporter. It really depends on your application.

Jean-Nicolas

[jnbrunet]

Hi @Zahra

I’m not sure why you’re getting the whole volume’s triangle set. I just tried adding the mesh exporter to the “T” node and it works fine on my side. I disabled the edges export to really get only the positions and triangle indices:

<?xml version="1.0" ?>
<Node name="root" dt="0.05" showBoundingTree="0" gravity="0 0 0">
    <VisualStyle displayFlags="showBehaviorModels showVisual" />
    <CollisionPipeline verbose="0" />
    <BruteForceDetection name="N2" />
    <CollisionResponse response="default" />
    <MinProximityIntersection name="Proximity" alarmDistance="0.8" contactDistance="0.5" />
    <CollisionGroup />
    <Node name="TT">
        <EulerImplicit name="cg_odesolver" printLog="false"  rayleighStiffness="0.1" rayleighMass="0.1" />
        <CGLinearSolver iterations="25" name="linear solver" tolerance="1.0e-9" threshold="1.0e-9" />
        <MeshGmshLoader name="loader" filename="mesh/cylinder.msh" />
        <MechanicalObject src="@loader" name="Volume" />
        <include href="Objects/TetrahedronSetTopology.xml" src="@loader" tags=" " />
        <DiagonalMass massDensity="0.5" />
        <FixedPlaneConstraint direction="0 0 1" dmin="-0.1" dmax="0.1" />
        <FixedConstraint indices="0" />
        <TetrahedralCorotationalFEMForceField name="FEM" youngModulus="360" poissonRatio="0.3" method="large" />
        <Node name="T">
            <MeshExporter format="vtk" filename="cylinder_surface" exportAtBegin="true" edges="false"/>
            <include href="Objects/TriangleSetTopology.xml" src="@" tags=" " />
            <Tetra2TriangleTopologicalMapping input="@../Container" output="@Container" />
            <TriangularFEMForceField name="FEM" youngModulus="60" poissonRatio="0.3" method="large" />
            <TriangularBendingSprings name="FEM-Bend" stiffness="300" damping="1.0" />
            <TrianglePressureForceField normal="0 0 1" dmin="0.9" dmax="1.1" pressure="0.4 0 0" />
            <TriangleSet />
            <Node name="Visu">
                <OglModel name="Visual" color="blue" />
                <IdentityMapping input="@../../Volume" output="@Visual" />
            </Node>
        </Node>
    </Node>
</Node>

Let me know if you’re still having difficulties to get it right.

[jnbrunet]

Hi Quentin,

Yes, you can use a pythonController and change the value of either the totalForce attribute (vector 1×3) if you want that the force be split among all vertices, the force attribute (vector 1×3) if you want to apply the same force to all vertices, or the forces attribute (vector nx3) to apply different forces to each vertices.

Using a pythonController, simply change the attribute value of the forcefield at each onBeginAnimationStep event (you can find examples in the applications/plugins/SofaPython/examples directory)

Hope that helps.
Jean-Nicolas

[jnbrunet]

Hi,

Instead of manually specify ‘SofaFramework_DIR’ and other Sofa CMAKE dependencies, you can simply set the CMAKE variable ‘CMAKE_PREFIX_PATH’ to the sofa’s CMAKE installation path.

1. In your sofa’s build directory, make sure your ran ‘make’ and ‘make install’ commands. Note the sofa’s install directory path (it seems that in your case, it should be /home/agniv/Code/sofa/build/install)

2. In your scene project, add the ‘CMAKE_PREFIX_PATH’ variable and set its value to /home/agniv/Code/sofa/build/install/lib/cmake

3. Rerun ‘cmake’ and ‘make’ in your scene project build directory

[jnbrunet]

Awesome, also thanks for reporting this GCC bug. If you don’t mind marking this discussion as solved, it may help others.

[jnbrunet]

The error output is typical to gcc. Also, the cp/pt.c is the c++ (directory cp) parameterized types (file pt.c, means c++ template) of the gcc compiler.

[jnbrunet]

It seems there is a problem with this GCC version. I will look into it later, for now can you try with clang?

[jnbrunet]

Well, I’ve just tested with a clean fedora 28 vm. I saved the exact commands used from the freshly installed OS to the compilation of Sofa:

1. $ sudo dnf update -y
2. $ sudo dnf install -y gcc-c++ clang cmake cmake-gui git qt5-devel boost-devel python2-devel libpng-devel libjpeg-turbo-devel libtiff-devel zlib-devel glew-devel
3. $ git clone https://github.com/sofa-framework/sofa.git
4. $ cd sofa
5. $ mkdir build
6. $ cd build
7. $ cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ..
8. $ make

I’ve compiled successfully with both v17.12 and master branches. I’ve also tried with glibc-static and glibc-devel to see if there is a confusion in the dependencies, and everything built fine. Here is the versions of the tool installed:

cmake: 3.11.2
clang: 6.0.0
glibc: 2.27

Maybe you could try reinstall the cmake and clang packages… Make sure that you only use the tools from the fedora repositories, and not the ones you compiled yourself.

[jnbrunet]

Then I’m not really sure where your problem comes from. From your results, everything seems fine, you even linked the same test program from cmake without the linked error…

The only difference I have with you is that I don’t have that static package installed, but this should not make a difference since the linker should use the dynamic library by default, unless you manually imposed static linking, which I don’t even think it’s possible with sofa.

Can you try again the compilation with an empty build directory of sofa? Try to put the least cmake options as possible (plugins, etc). Maybe add the -DCMAKE_VERBOSE_MAKEFILE=ON to the cmake command to get more hints.

[jnbrunet]

Not sure where you got those libpthread stubs files and the static static library.

Did you installed glibc-devel package?

Can you give me the output of
1. rpm -qf /usr/lib64/libpthread-stubs.so.0
2. rpm -qf /usr/lib64/libpthread.a
3. cat /usr/lib64/libpthread.so

[jnbrunet]

Also, the output of

ll /usr/lib64 | grep -i pthread

[jnbrunet]

Maybe, can you give me the output of the following commands:

1. /usr/bin/clang --version
2. /usr/bin/ld --verbose | grep SEARCH
3. CURDIR=$PWD; cd /tmp && cp /usr/share/cmake/Modules/CheckFunctionExists.c . && /usr/bin/clang -DCHECK_FUNCTION_EXISTS=pthread_create -o CheckFunctionExists.c.o -c CheckFunctionExists.c && /usr/bin/clang -DCHECK_FUNCTION_EXISTS=pthread_create -rdynamic CheckFunctionExists.c.o -o CheckFunctionExists -lpthread -v; rm CheckFunctionExists*; cd $CURDIR

Edit:
Also, the output of
4. ll /usr/lib64 | grep -i pthread

[jnbrunet]

Hello,

I’m not sure about fedora 28, but with fedora 27 I have:

$ ldd bin/runSofa | grep -i pthread
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff9c41fb000)

$ rpm -qf /lib64/libpthread.so.0
glibc-2.26-28.fc27.x86_64

And

$ namei /lib64/libpthread.so.0
f: /lib64/libpthread.so.0
 d /
 l lib64 -> usr/lib64
   d usr
   d lib64
 l libpthread.so.0 -> libpthread-2.26.so
   - libpthread-2.26.so

Which means my /lib64/libpthread.so.0 was imported by the glib-2.26 package. I find it very strange that nm didn’t found any symbol in your libpthread.so.0 file. Maybe try to reinstall the glib package?

[jnbrunet]

It looks like it, but still hard to say. This remains a rather obscure part of sofa that could use some light 😉

[jnbrunet]

Hi Catherine,

Unfortunately this is not possible with the LinearForceField component. I’m not sure if there is another component that would do that. If you are comfortable enough with c++, you could try to extend the LinearForceField class to add this feature.

Otherwise, I would suggest to look at python scenes, you can have a look at the various examples in the SofaPython plugin directory (sofa/applications/plugins/SofaPython/examples). You could, for instance, use a ConstantForceField component and change the values inside its vector of forces at each step with your python script.

Let me know if you still struggle with this.
Jean-Nicolas

[jnbrunet]

Hi Catherine,

You can look at the LinearForceField component. If “Volume” is the name of your MechanicalObject, you could write:

<LinearForceField points="@Volume.indices" forces="0 -1 0 0 -5 0 0 -10 0" times="0 10 20" />

This will set the forces to (0,-1,0) at time 0, (0, -5, 0) at time 10 and (0, -10, 0) at time 20. Between those times, the force will be linearly interpolated.

If you want to apply the forces on a subset of your domain, you can specify the indices of your dofs in the points attribute of the LinearForceField. For exemple,

<BoxROI name="f_indices" box="0 0 0 10 10 10"/>
<LinearForceField points="@f_indices.indices" forces="0 -1 0   0 -5 0  0 -10 0" times="0 10 20" />

will set the forces contained in the box (xmin, ymin, zmin, xmax, ymax, zmax) = (0,0,0,10,10,10)

If you need more than this, then I would suggest you to look at python scenes.

Let me know if you need more details.
Jean-Nicolas

[jnbrunet]

Hi Wendy,

It seems the Sofa’s include directory was not added to your project compilation.

Are you using CMake to configure your plugin compilation? If that’s the case, then you should have somewhere in your CMakeLists.txt file:

find_package(SofaGeneral REQUIRED)
find_package(SofaBase REQUIRED)

That should automatically add the sofa’s include directory to your project.

Also, the installation path of sofa should be used as the cmake prefix path in order for it to find SofaGeneral and SofaBase. For example, if your Sofa’s installation path is “/home/wendy/sofa/build/install”, you would run cmake on your project with:

cmake -DCMAKE_PREFIX_PATH=/home/wendy/sofa/build/install/lib/cmake CMakeLists.txt

Let me know if that helped.

[Author]

Posts