search

opensim-org / opensim-core

SimTK OpenSim C++ libraries and command-line applications, and Java/Python wrapping.
https://opensim.stanford.edu
Apache License 2.0
783 stars 316 forks source link

Suggestion for resolving DLL conflicts in OpenSim #3681

Closed mrrezaie closed 8 months ago

mrrezaie commented 8 months ago

Hi, Last week, I installed CasADi Python package in the same environment where OpenSim Moco package existed and I noticed a significant slowdown in my code that heavily employed OpenSim API. For instance, the execution took 60s instead of typical 15s. I found that installing CasADi replaced some of the OpenSim DLL files, because they have identical names. I realized that this is a common problem that has been reported by other users with EZC3D package as well : https://github.com/opensim-org/opensim-core/issues/3066, https://github.com/pyomeca/ezc3d/issues/220, https://github.com/pyomeca/ezc3d/issues/201, https://github.com/opensim-org/opensim-core/issues/3209.

I was wondering if it would be possible for OpenSim to rename the DLL files of the third-party dependencies and distinguish them from the original packages by adding a prefix to the DLL files after building, for example, osimezc3d.dll. This way, no such interferences will occur in the future for MATLAB\Python users. I understand that this might require a lot of work, but I think it would be a valuable improvement for the OpenSim community.

Thank you for your time and attention. -Mohammadreza

aymanhab commented 8 months ago

Thanks for the proposal. A while ago we implemented this approach for simbody by prepending OpenSim prefix to dll names and that led to many problems downstream, primarily that stock releases/updates of simbody or local builds were not usable. out of the box. It's understood that the way windows resolves DLLs is less than perfect but the lessons learned from that previous experience that we had to undo later still stand.

mrrezaie commented 8 months ago

Hi @aymanhab, thank for your response. I see how tricky it might be.

A workaround might be to let users have access to the original packages through OpenSim, e.g., from opensim import casadi in Python. So users will be able to have OpenSim and its built third-party packages in a same environment and use them simultaneously without issue. I'm not a developer, but this method seems to be much more straightforward. I had seen similar thing in casadi and numpy: import casadi.numpy as np.