10 May 2020 at 22 h 45 min #16084
I have been using SOFA for the last half year and would like to start using the Python3 integration as it has a lot of interesting new features: https://github.com/SofaDefrost/plugin.SofaPython3
In the link, they recommend using an out-of-tree build if you want to maintain the possibility of using SofaPython plugin (the regular Python2 plugin). I have spent a significant amount of time trying to understand and implement an out-of-tree build, but am having some difficulty with it. Is there someone who could provide me with an easy-to-follow step-by-step process for this?
However, I went instead and did cmake and build without SofaPython plugin, but was faced with the error that I hadn’t set SOFA_ROOT when trying to import Sofa. I hence set SOFA_ROOT in my zshrc/bashrc file to [HOME_DIR]/dev/sofa/build/master but to no avail. I managed to successfully do import Sofa when adding the path [HOME_DIR]/dev/sofa/build/master/lib to PYTHONPATH in zshrc/bashrc file, but it gave the error ‘No module named Sofa.Helper’
Given my limited background in developing applications, it would be great to have some guidance on this. Thank you very much and I really appreciate the help10 May 2020 at 22 h 47 min #16148HugoKeymaster
- SOFA Consortium
Your post was marked as spam. Sorry about the process delay.
We will get on your topic early this week.
Hugo11 May 2020 at 6 h 41 min #1615412 May 2020 at 22 h 10 min #16175
Thank you very much for the detailed information. I have some errors, unfortunately. After git pull from master and adding the plugins I want (SoftRobots, ModelOrderReduction, STLIB, note that SoftRobots requires SofaPython) I got the following errors when building (running ninja command):
/usr/bin/ld: cannot find -lSofaComponentCommon
collect2: error: ld returned 1 exit status
I assume this is due to some mismatch between the Sofa versions –> Is there a way to use a released build of Sofa instead of pulling from master?
I also tried building without the test scripts (GTestMain etc.) but this gives error when running ninja on the SofaPython3 plugin (Step 2).
Sander13 May 2020 at 9 h 16 min #16176
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
JN13 May 2020 at 20 h 13 min #16198
Thanks again for helping out. I am getting a better understanding of the inner workings, but still require some help unfortunately.
I am now at status with origin master branches for SoftRobots, Sofa, SofaPython3. I have successfully run build and complete Step 1.
For step 2 when configuring SofaPython3 I get the following error: CMake Error at /home/stonkens/dev/sofa/build/install/lib/cmake/SofaGui/SofaGuiConfig.cmake:43 (find_package): Found package configuration file: /home/stonkens/dev/sofa/build/install/lib/cmake/SofaMisc/SofaMiscConfig.cmake but it set SofaMisc_FOUND to FALSE so package "SofaMisc" is considered to be NOT FOUND. Reason given by package: The following imported targets are referenced, but are missing: SofaNonUniformFem Call Stack (most recent call first): bindings/SofaGui/CMakeLists.txt:15 (find_package)
I checked and SofaNonUniformFEM is in the plugins within $SOFA_BLD/install.
I have checked both the sofa forum and the issues on github but have not found a similar issue unfortunately.
I’m happy to email instead (given this seems to be an issue that only I am having), which may allow for a bit faster debugging.
EDIT: What might help, I get this warning when configuring in step 1 of your first linked post (building dev version of Sofa):
CMake Deprecation Warning at SofaAdvanced/CMakeLists.txt:15 (message): SofaAdvanced is deprecated. You should now explicitely find (find_package) and link (target_link_library) each module you need within: SofaNonUniformFem13 May 2020 at 22 h 14 min #16201
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-N14 May 2020 at 14 h 16 min #16209
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.19 May 2020 at 2 h 20 min #16319
Thank you very much @jnbrunet.
Final question, splib (part of STLIB: Sofa Template library) has less functionality in SofaPython3. Is this done intentionally? Particularly, I rely on Vec3 and Quat classes –> I have found a workaround so definitely no need to resolve this, but was wondering what the underlying reason was.
Sander19 May 2020 at 9 h 05 min #16320
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-N19 May 2020 at 15 h 11 min #16324sescaidaParticipant
regarding your questions about splib (and STLIB): SPLIB basically has to be ported to python 3. For now SofaPython3’s functionality is mostly related to the bindings and scripting. We are slowly populating SPLIB with the functionality it had before. SPLIB is now a part of SP3 and there could eventually be a separate STLIB for python 3 to complement the SoftRobots plugin.
In any case, I think porting the code from the old STLIB (which includes SPLIB) should not be soo difficult. If you happen to do some porting for SPLIB, you can even create a pull-request!
Stefan27 May 2020 at 2 h 11 min #16393
- You must be logged in to reply to this topic.