[jnbrunet]

Hey Mike,

Hum, I’m not sure why you are having PIC errors here… Did you try to wipe your SofaPython3 build directory after the update to v20.12 branches?

If yes, which compiler and compiler version are you using?

You can always disable the compilation of the unittest with cmake -DSP3_BUILD_TEST=OFF .. inside your build directory. This might get you a little bit further in the compilation.

[jnbrunet]

Hey @nhnhan,

Did you compile the plugin within the compilation of SOFA or as an out-of-tree plugin? Are you compiling the SofaPython(2) plugin at the same time?

These errors looks to me as if you are linking against a wrong python version (python 2 maybe?). During the cmake configure stage, it should have a some information on which python version is used for the compilation, something like :

$ cmake ..
(...)
-- Python:
    Version: 3.9.1
    Executable: /usr/bin/python3.9
    Headers: /usr/include/python3.9
    Libraries: /usr/lib64/libpython3.9.so
    User site: /home/jnbrunet/.local/lib/python3.9/site-packages
(...)
-- Configuring done
-- Generating done

[jnbrunet]

Hey @quantanovo,

There are some very recent changes in SOFA that broke SofaPython3 and there is a patch coming up to fix theses errors. The patch should be merge this weekend or soon next week.

Note that these kind of error will probably happen often if you are closely following the master branches of both SOFA and SofaPython3.

There are now “v20.12” branches available on both SOFA and SofaPython3 which should remain stable and ensure compatibility between the two of them. I would suggest you checkout these if you want to avoid errors.

J-N

[jnbrunet]

Hi @twxu

Sorry for the delay.

If the “from” keyword is causing you an issue in your python script, you could try the following:

kwargs = {'name':'exchangeData1', 'template':'vector<float>', 'from': '@finger/tetras.position', 'to': '@OBJECT/DOFS.position'}
rootNode.createObject('DataExchange', **kwargs)

[jnbrunet]

Hi @twxu,

Just a quick question: Did you compile SOFA yourself or did you use the precompiled version from the download section of this website?

If you compiled it yourself -> Make sure you did not compile it in debug mode but in release mode.

Also, on what system are your running your simulation (OS? CPU? How much RAM?)

J-N

[jnbrunet]

Hey Arthur,

Thanks for sharing your solution !

I agree that it is probably not the best for headless simulation. Some time ago, I made a fully OffscreenCamera that was able to render the SOFA scene into a QtOffscreenSurface. I will try to dig up this old code and bring it back to life. I’ll update this post when it is done.

J-N

[jnbrunet]

Hey @beichun

Indeed, you have to use the Qt viewer since the QGLViewer has its own internal camera.

For your error with the orientation, the data has to be converted to a python list. In your code, simply change cam_orientation = R.from_euler("x", np.pi/2).as_quat() to cam_orientation = R.from_euler("x", np.pi/2).as_quat().tolist().

J-N

[jnbrunet]

Hey Peter,

By default, SOFA is compiling using double precision. Hence the following:

sofa::component::mass::DiagonalMass<Vec3fTypes, float>::DiagonalMass()'

Won’t be able to link as it is not defined.

To fix it, you can do one of three solution:
1. In your code, use Vec3dTypes instead of Vec3fTypes and double instead of float. Or better, use Vec3Types to make sure you are using the same floating point type as the one used for the compilation of SOFA
2. Include in your cpp file the DiagonalMass.inl header file before using the DiagonalMass with a float type:

#include <SofaBaseMechanics/DiagonalMass.inl>
(...)
sofa::component::mass::DiagonalMass<Vec3fTypes,float> some_mass_component;

This will compile the DiagonalMass with float support in your .cpp file.
3. Compile SOFA yourself and set the CMake variable SOFA_FLOATING_POINT_TYPE to float

J-N

[jnbrunet]

Hey Arthur,

Yeah they are mutually exclusive since the GUI is stealing the main thread.

To be able to draw the scene without a GUI, you would have to create a GL context yourself. You can have a look at the following example which is using pygame to render the SOFA scene.

J-N

[jnbrunet]

Hey Francois,

Thank you for taking some time to investigate this. It could very well be a bug.

Could you tell me which version of SOFA you are using? Did you download the binaries from the website or did you compiled it? If you compiled SOFA, could you give me the last git commit (git log --oneline -n 1)?

J-N

[jnbrunet]

Hey Francois,

I’m not sure why you aren’t having the output. I just tried running it on the default scene (runSofa -g batch --computationTimeSampling 1) and I got the timer output. Could you also try it on the default scene (by not specifying any scene file)?

The option --computationTimeOutputType json will still output the timer on the stdout (your terminal), but using a json format.

J-N

[jnbrunet]

Hey @fleonard,

If I remember correctly, the computationTimeSampling option requires an integer and will set the frequency (in number of steps) at which the computation times are printed. For example, setting runSofa -g batch --computationTimeSampling 2 will print at every 2 steps. It is 0 by default, which means that it will never be printed.

The --computationTimeOutputType option will instead specify the format to be printed (text or json)

J-N

[jnbrunet]

Hey @amackeith,

My guess would be that this is caused by the OglModel, and probably related to the driver error you are having. The “Qt” viewer of SOFA is quite old and sensible to the OpenGL extensions available.

Could you try using the qglviewer instead of the Qt one? Simply change

Sofa.Gui.GUIManager.Init("simple_scene", "qt")

to

Sofa.Gui.GUIManager.Init("simple_scene", "qglviewer")

Note:

@scheikl has seen your post here and suggested the following for your driver problem (he had some problem replying directly here, spam filter issue):

could you check whether your user is part of the video group?
(is video in the output of $ groups?)

If not, that would explain the Permission denied part.
I never quite understood when this is necessary, and when not.
On my system, for example, it works without the video group :D.

You can add your user to the group with

$ sudo usermod -a -G video sofauser

Might not work, but it is worth a try.

This might fix the issue using the “qt” viewer.

J-N

[jnbrunet]

Hey @amackeith,

Crap, I think I know what’s going on. This is a bug on SOFA’s API side. Can you try swapping the following line:

Sofa.Gui.GUIManager.createGUI(root)

for

Sofa.Gui.GUIManager.createGUI(root, __file__)

We should fix this before the next release, I’ll create an issue on Github.

Let me know if it worked.
J-N

[jnbrunet]

Hey @amackeith,

Alright, I’ve missed the error on the ‘OglModel’ component.

Can you try adding the following at the beginning of your script:

import SofaRuntime
SofaRuntime.importPlugin('SofaOpenglVisual')

J-N

[jnbrunet]

Hey @amackeith,

Are you able to launch runSofa? Or any GUI application using OpenGL?

> libGL error: failed to open /dev/dri/card0: Permission denied
> libGL error: failed to load driver: nouveau

The error you are having here looks more to me as a driver problem than SOFA…

J-N

[jnbrunet]

Hi @scheikl,

Unfortunately, I haven’t had time to look at this yet. I just created a github issue here so that it doesn’t get lost.

Hopefully, I should be able to do it just after the holidays.

J-N

[jnbrunet]

Hi @amackeith ,

You could try the following:

import Sofa.Simulation

# (...)

# At some point in your script, reset the scene
Sofa.Simulation.reset(root)

This will launch a reset visitor on the scene graph starting from the root node, which should be the same as hitting the reset button in the GUI.

J-N

[jnbrunet]

Hi @amackeith,

Can you try to change the following line:

target.two_cell_robot.cavity1.SurfacePressureConstraint.findData('value').value = str(0.1)

To

with target.two_cell_robot.cavity1.SurfacePressureConstraint.value.writeableArray() as wa:
    wa[0] = 0.1

J-N

[jnbrunet]

Hey @scheikl ,

I think this is because the data spring is a vector of sofa::component::interactionforcefield::LinearSpring objects, and the latter class hasn’t been bound to python3 yet, hence why you are seeing a vector of empty values (SofaPython3 detects that it is a vector, but cannot convert the LinearSpring class).

If you have some time, would you be able to create a very basic python 3 scene using the StiffSpringForceField. By basic I mean with the minimum number of components and plugins (for example, two objects attached and created from a RegularGridTopology so that we don’t have to add mesh files to the scene). I will try to add bindings for the LinearSpring class and this will help me to test the bindings.

J-N

[jnbrunet]

Hi @amackeith

Can you post the complete output of the error so that we can see the call stack (history of called functions until the error)?

J-N

[jnbrunet]

Yes sorry, I’ve corrected it.

[jnbrunet]

Exact, you can use

sofa::simulation::MechanicalPropagateOnlyPositionAndVelocityVisitor(&mparams).execute(this->getContext());

to do so.

[jnbrunet]

Yeah this part isn’t very straightforward to understand.

Here, x.peq(dx); will store the new positions inside the mechanical object’s vector pointed by x. Now, which one is x? If you follow its definition, it is set to the solve() method’s parameter sofa::core::MultiVecCoordId xResult which is defaulted to VecCoordId::position(), hence the MechanicalObject.position datafield. Now, the x.peq(dx); operation starts a visitor that stops at every mapped mechanical objects, i.e. any mechanical object where a mechanical mapping is found.

Next, MechanicalPropagateOnlyPositionAndVelocityVisitor will go through all mapped mechanical objects and compute their new position (MechanicalObject.position datafield) using mapped_x = mapping.J*parent.x.

Let’s say you have this scene:

<Node name="root">
  <StaticSolver />
  <LinearSolver />
  <Node name="object1">
    <MechanicalObject name="mo" />
    <Forcefield name="volume_ff" />
    <Node name="surface">
      <MechanicalObject name="mo" />
      <Forcefield name="surface_ff" />
      <Mapping name='mapping'/>
    </Node>
  </Node>

  <Node name="object2">
    <MechanicalObject name="mo" />
    <Forcefield name="volume_ff" />
  </Node>
</Node>

It goes like this:

1. x.peq(dx);
root.object1.mo.position += root.object1.mo.dx
root.object2.mo.position += root.object2.mo.dx

2. MechanicalPropagateOnlyPositionAndVelocityVisitor
root.object1.surface.position = root.object1.surface.mapping.J * root.object1.mo.position

Hope that cleared things a little bit.
J-N

[jnbrunet]

Hey @jjcasmar,

You understood correctly.

mop.computeForces() is only responsible to propagate forces from the mapped mechanical object to their parent.

MechanicalPropagateOnlyPositionAndVelocityVisitor is responsible to propagate the position and velocity vectors from parent (top level, or system) vectors to mapped vectors.

You can have a look at this StaticSolver from the Caribou plugin. It is a little bit more advanced compared to the SOFA one and its documentation is also richer.

[Author]

Posts