Methods from Simbody library appear to be not accessible through OpenSim API

[itbellix]

Dear OpenSim developers, @adamkewley and I are encountering a weird behaviour when trying to access the simbody library through the OpenSim API (in Python). What I wish to do is manipulate moments of inertias (inertia matrixes) of various bodies, to express them with respect to a frame that is different from the bodies' centers of mass. I have found some simbody methods that should allow to do precisely that (in particular, I want to use shiftFromMassCenter). Below you find a non-working snippet of my code, to give an idea of what I am doing:

# import opensim
import opensim as osim

# load model
...

# select body of interest
...

# retrieve body's moment of inertia
body_inertia = body.getInertia()

# instantiate an Inertia simbody object, to access related methods 
inertia_simbody = osim.simbody.Inertia(body_inertia.get(0), body_inertia.get(1), body_inertia.get(2), body_inertia.get(3), body_inertia.get(4), body.get(5) )

However, it appears that many methods that the object inertia_simbody should have access to are actually not exposed by the OpenSim API (just a few of them are available, but not the ones allowing to manipulate the body's inertia for instance).

Having a look at the way in which OpenSim makes those methods available, we found that they are indeed listed in https://github.com/opensim-org/opensim-core/blob/main/Bindings/SWIGSimTK/MassProperties.h (e.g., the function I am interested in is at this line), but there appears to be an if statement that is probably preventing those methods to be streamed through the API.

I hope that my explanation is clear enough for you to reproduce the issue. Let me know otherwise.

Now, my questions are: do you confirm that those methods cannot be accessed currently? If so, is there any workaround?

Looking forward to your comments on this!

Best regards, Italo

cc @aseth1

[adamkewley]

@aymanhab I was suggesting to @itbellix that we could perhaps uncomment some of the methods he needs, soo that they're available via the API directly (for now, @itbellix is having to re-write them in python), but I suggested that he opens this ticket because it's unclear to me what the impact of emitting those methods would be (e.g. on the Java bindings)

[aymanhab]

@adamkewley good idea. Historically we did the "customization" of these simbody headers to allow them to go through SWIG years ago in SWIG version 3, many of these commented out methods could be handled by the latest SWIG version. If @itbellix is interested he can start by uncommenting (removing #ifdef SWIG) from around the methods he needs and see what happens. As long as the build for both python and java bindings completes successfully there should be little side effects other than new methods exposed which is typically not harmful ;) Hope this helps. Ideally we can remove all the #ifdef SWIG and use the simbody proper methods directly but it depends on what SWIG can absorb now.

[adamkewley]

(note: #3551 was closed because moving the SWIG ifndef blocks isn't necessarily a one-and-done thing: the SWIG compiler only accepts very specific constructs and it's easier to figure out which ones by separately running MassProperties through SWIG offline and mutating it until SWIG stops crying)