Forum Replies Created
-
Posts
-
Hello Bani,
The solution mentioned by Hugo should indeed be merged soon (the update is under review). In the meantime, a workaround is to open your mesh with Gmsh, and export it with an older msh format (for instance version 2 ASCII).
When in Gmsh gui, you can go to File > Export, then select the msh format (Mesh – Gmsh MSH(*.msh) in the dropdown menu, and click “Save”. You should have a popup “MSH options” which appears, on which you can select the format with which you want to export the mesh. You can switch then from the default “Version 4 ASCII” to “Version 2 ASCII”, which is supported by SOFA v21.06Best,
Camille
Hi @Jonny,
Indeed, that was my issue, switching the view parameter to “OpenGL” works perfectly.
Thanks a lot !Hello,
Sorry once again for this late answer, but I managed to get plasticity deformation in your scene file @Andres.
I modified slightly the scene to get conditions close to the ones in TetrahedronFEMForceField_plasticity.scn, in order to understand what was going on. So I removed the FixedConstraint component, and added a PlaneForceField component so that the colon would just crash on the planeforcefield under it’s own weigth. I also multiplied by 10 the mass (from 0.7 to 7) in order to amplify this effect. The last thing I did was to apply a scale factor to the dimensions of the colon mesh : as the gravity you defined was expressed in SI units (9.81 m/s^2), the dimensions of the mesh are supposed to be in meters for coherency. The coordinate values I could see in the .obj were globally between 0 and 40, so I applied a 0.01 scale factor to stand for a colon with maximum dimensions around 40cm.
My guess is that there was nothing wrong with your scene, but that the values you used for the plasticity parameters did not allow plastic deformation, probably either because the deformation didn’t go above the plasticYieldThreshold you specified (although the one you used was pretty low), or (and more likely) because the plasticMaxThreshold was too low and therefore did not allow for much plastic deformation.
I used the following line for the TetrahedronFEMForceField parameters :
<TetrahedronFEMForceField name="FEM" youngModulus="4000" poissonRatio="0.4" method="large" computeGlobalMatrix="false" plasticYieldThreshold="2e-5" plasticMaxThreshold="2.5e-2" plasticCreep="0.1"/>
to see plastic deformation when the colon mesh hits the PlaneForceField. For instance if you switch the plasticYieldThreshold to “4e-5”, it will be too high for plastic deformation to occur.Hope this answers the issue.
Cheers
Camille
PS : I used
<PlaneForceField normal="0 1 0" d="-3e-1" stiffness="100000" showPlane="1" showPlaneSize="1"/>for the PlaneForceField andscale3d="1e-2 1e-2 1e-2"in the MeshObjLoader options.Hi Hugo, hi Andrés,
I’m also sorry for delaying this issue (which is indeed of interest to me, you poked right Hugo ;)). I have quiet a lot on my plate at the moment, but it should be better by the end of next week. I’ll gladly have a look on the issue then !
I’ll eventually update this tread if I find anything interesting.Regards,
Camille
Hello Edward,
It’s perfect then, if you spoke with Hugo about the plugin 🙂
For some reason my answer seems to have been deleted when I tried to edit the linked to the plugin, so I’ll just rewrite it here, for potential future readers.Kind regards,
Camille
——————————————–
Previous answer :
——————————————–
Hello,I can only speak from my user experience, but I think you can find in SOFA the tools to perform real time simulation of a guide-wire. More precisely, what has already been done is the simulation (in real time) of catheters or embolisation coils, using serially linked beam elements.
This is actually the purpose of a dedicated plugin (Catheters & Beams), which you can find here :
with example of applications and related publications. The plugin is private, but someone from SOFA (@hugo ?) should be able to give you more information about it.
Otherwise if you want a basic sample, the BeamFEMForceField component can be used in the same way (although probably with less features). My version of SOFA in not up-to-date, but you should find an example in BeamFEMForceField.scn.I would say that these serially linked beam models are fast enough to run in real time, even with a somewhat fine discretisation of the catheter. However I don’t know how much the simulation could be slowed down if contacts, for instance, were to be handled.
As for the last part of your message, unfortunately I’m not familiar with rigid-multibody systems in general (and in SOFA in particular).
I hope this helps,
Camille
Hello,
I can only speak from my user experience, but I think you can find in SOFA the tools to perform real time simulation of a guide-wire. More precisely, what has already been done is the simulation (in real time) of catheters or embolisation coils, using serially linked beam elements.
This is actually the purpose of a dedicated plugin (Catheters & Beams), which you can find here :
https://www.sofa-framework.org/applications/marketplace/catheters-and-beams/
with example of applications and related publications. The plugin is private, but someone from SOFA (@hugo ?) should be able to give you more information about it.
Otherwise if you want a basic sample, the BeamFEMForceField component can be used in the same way (although probably with less features). My version of SOFA in not up-to-date, but you should find an example in BeamFEMForceField.scn.I would say that these serially linked beam models are fast enough to run in real time, even with a somewhat fine discretisation of the catheter. However I don’t know how much the simulation could be slowed down if contacts, for instance, were to be handled.
As for the last part of your message, unfortunately I’m not familiar with rigid-multibody systems in general (and in SOFA in particular).
I hope this helps,
Camille
Indeed I used the pre-built Windows binaries! (which I got here, just in case)
I’ve never tried to build Boost from the source code to then use the libraries in SOFA, but if the installation directory is not the same, I guess it can cause some issues with SOFA CMakefiles.I hope it works fine with the binaries!
Cheers,
CamilleHi Alberto,
Thanks for the additional details. I’m no specialist, but I’m puzzled by the values that CMake gives to the Boost library directories in the screenshot you sent:
Boost_LIBRARY_DIR_DEBUG = “C:/Program Files/boost/boost_1_66_0/stage/lib”
Boost_LIBRARY_DIR_RELEASE = “C:/Program Files/boost/boost_1_66_0/stage/lib”In my Boost installation directory, there is no ‘stage’ directory mentioned above. And so my variables in CMake look like:
Boost_LIBRARY_DIR_DEBUG = “C:/dev/boost/boost_1_66_0/lib64-msvc-14.1”
Boost_LIBRARY_DIR_RELEASE = “C:/dev/boost/boost_1_66_0/lib64-msvc-14.1”Regarding your updates, if I’m not mistaking, the problem is that the libboost_xxx.lib files are the static versions of the boost libraries, while VS is trying to link dynamic libraries (of the form boost_xxx.lib). If so, changing the name of the library won’t change the fact that it is static, which doesn’t correspond to what the linker is looking for.
What you can try is to locate the dynamic boost libraries (such as boost_program_options-vc141-mt-x64-1_66.lib) in your Boost installation directory and manually change the CMake variables accordingly. That is:
– go in C:/Program Files/boost/boost_1_66_0/ and check whether you find the “lib64-msvc-14.1/” directory there;
– if you do, check that you find the dynamic libraries inside (boost_xxx.lib);
– if everything is there, you can try to manually change the values of CMake as:
Boost_LIBRARY_DIR_DEBUG = “C:/Program Files/boost/boost_1_66_0/lib64-msvc-14.1”
Boost_LIBRARY_DIR_RELEASE = “C:/Program Files/boost/boost_1_66_0/lib64-msvc-14.1”
and run Configure again, to see if CMake finds the dynamic libraries or goes back to the libboost_xxx.lib version.Tell me how it goes.
Cheers,
Camille
Hi Alberto,
I’m working under Windows as well (using VS2015 and Boost 1.62).
If everything is going well during the CMake configuration, Boost should be detected automatically, and the name of the corresponding libraries (such as boost_program_options-vc141-mt-x64-1_66.lib) should be filled automatically as well by CMake. To check what the real name of the library is, you can explore directly the Boost installation directory, where you should find the libraries in “lib64-msvc-14.1/”.What can happen is that Boost is not automatically detected by CMake. In this case, you can add an entry in CMake containing the path of your Boost installation folder. The procedure is detailed here:
SOFA documentation
Running “Configure” again should then set up the library files with the correct names.Does this correspond to your problem?
Cheers,
Camille
Hi @Hugo,
Thank you very much for your quick answer! Indeed changing the response type to “FrictionContact” solved the problem very efficiently.
I’ll mark the topic as closed.
Cheers,
Camille
Hi @Hugo,
Thanks for your answer!
Indeed this is not a bottleneck any more: thanks to the change of lines I mentioned in my second post, the IdentityMapping works well.
Yes, I imagined that there was something in the IdentityMapping which allowed to map Vec3d DoFs to the 3 positions DoFs of the Rigid3d nodes. I thought that this mechanism had been extended for the BarycentricMapping, as I was receiving an error message indicating that the template <Vec3d,Rigid3d> was available for the component:
[ERROR] [InfoComponent(Not created (BarycentricMapping))] Object type BarycentricMapping<Vec3d,Rigid3d> was not created The object is in the factory but cannot be created. Requested template: Vec3d,Rigid3d(Vec3d,Rigid3d) Available templates: Vec3d,ExtVec3d, Vec3d,Rigid3d, Vec3d,Vec3d,However I had a look in BarycentricMapping.cpp, and I have the impression that it is only instanciated on templates <Vec3d,vec3d> and <Vec3d,ExtVec3d>. Maybe there is just a problem in the error message ?
Regarding the IdentityMapping, is there something I’m doing wrong when specifying the input and output as in the following line ?
<IdentityMapping template="Rigid3d,Vec3d" input="@../DoFs" output="@collisionDOFs"/>
This raises an error at runtime, but not specifying anything doesn’t, and apparently the mapping is created on the same MechanicalObjects I wanted to explicitly give.
I dind’t check how the BeamLinearMapping works, but apparently it has the same issue (regardless of what happens once it is created).As my initial problem was to be able to create a mapping to associate a collision model to a BeamFEMForceField, I think we can close this topic.
Camille
Hello again,
I have some update regarding the IdentityMapping. By changing the line
<IdentityMapping template="Rigid3d,Vec3d" input="@../DoFs" output="@collisionDOFs"/>
into simply
<IdentityMapping />
the mapping is created normally and seems to work as expected.I still have no clue regarding the BeamLinearMapping and the BarycentricMapping. And I don’t know if I’m doing something wrong by specifying the input and output in the IdentityMapping.
Cheers,
Camille
Hi @Eleonora,
In your case, if you are using a BeamFEMForceField component, the behaviour you can simulate is – to the best of my knowledge – purely elastic (although it accounts for geometric nonlinearities).
Therefore the parameters mentioned by Zsolt (plasticMaxThreshold, plasticYieldThreshold and plasticCreep), which implement plasticity, do not exist in the BeamFEMForceField.Apart from the Young modulus and Poisson ratio, another parameter of the BeamFEMForceField which should affect the resulting behaviour is the radius of the section (circular by default) of your elements (parameter ‘radius’).
Although it is not represented visually in the beam elements, it is directly taken into account regarding the mechanical behaviour computation. Reducing this radius should result in a ‘softening’ of your beam element, and increasing it should result in a ‘hardening’.If you encounter further problems regarding this issue, it could be worth opening a dedicated topic. And maybe another one to know if there exist examples of comparison between SOFA and classic simulation softwares? (Which I would also be interested in)
Best,
Camille
[Update]
Finally I found the problem (which was a bad mistake on my side).During the tests I did, I compiled the OpenCascade library in different modes (Release, Debug, RelWithDebInfo) and for different versions. The problem came from the fact that the Release and Debug mode generate libraries in separate folders, and at some point the Release folder which I was using in my PATH was emptied.
Building once again OpenCascade in Release mode allowed my PATH to be correct again, and solved this issue. Sorry for taking your time with this…I’ll test my updated MeshSTEPLoader, and share it as soon as possible. In the meantime I’m setting this issue to solved
Thanks for your help!
Hi Erwan,
Thanks, I hadn’t notice the PR at the end of the GitHub discussion. I tried again with the fix, adding the modifications I had done to adapt the MeshSTEPLoader (which rose no conflict). The build went with no error, but the execution of runSofa failed to load several plugins, for instance :
[ERROR] [PluginManager] Plugin loading failed (C:\dev\sofa\master\bd\bin\RelWithDebInfo/.\/SofaPython.dll): La procÚdure spÚcifiÚe est introuvable.
(I’ll try to edit with the complete output, but for the moment it is considered as spam)As for the MeshSTEPLoader plugin, the behaviour seems to be exactly the same as I had before.
Hello Hugo,
Sorry for the delay. I had a look at the GitHub discussion, but I’m not sure the problem I have is the same.
I tried to update my Sofa sources with a more recent commit (573fc41 from 2018-01-14), and it resulted exactly in the error message Erwan Douaille first mentioned in the GitHub discussion (#561).
I then switched back to the former commit I was based on (2e29258, from 2017-11-22). I have indeed extra repositories (Debug, Release, RelWithDebInfo) added by Visual Studio in the build/bin repository, but most plugins are nonetheless successfully loaded (it’s the case for SofaPython, SofaSphFluid, SofaMiscCollision, image, Compliant, Flexible, CImgPlugin and SofaAllCommonComponents). Only the MeshSTEPLoader triggers the error I’m facing.
In addition to that, the plugin_list.conf is correctly generated and found by Sofa at execution time. In my case it is this file that triggers the automatic loading of all the plugins I mentioned above.Based on this, I would say that the problem I’m facing seems older than the one discussed in the associated GitHub issue. Do you think it is possible that the two issued are not directly related?
In any case I’ll follow closely the GitHub discussion and try again with the correction as soon as it is available.Best,
Camille
Hi Hugo,
I should have mentioned it actually, but yes the .dll file is indeed generated, and it is in the folder where the PluginManager is looking at by default (build/bin/RelWithDebInfo/MeshSTEPLoader.dll). I don’t know if it is worth mentioning, but the static library is generated as well in a different folder (build/lib/).
In fact, just before the call to the load method is made in PluginManager.cpp, a test is run:
FileSystem::exists(pluginPath)
with the same path I mentioned before, and it returns “true”.As I don’t understand this error, I’ll try to build and run SOFA in Debug or in Release mode, to see if it changes something (I’m currently in Release with Debug info)
Best,
Camille
Hi Hugo,
Thanks for your answer.
I tried to manually add the MeshSTEPLoader.dll via Edit->Plugin Manager->Add, but it resulted in the same error: a new window was displayed (“library loading error”) on which there was the same text (“Plugin loading failed (C:/dev/sofa/master/bd/bin/RelWithDebInfo/MeshSTEPLoader.dll): Le module spÚcifiÚ est introuvable.”).
The console output is also identical.Going into the code, it seems to me that this error does not occur at the SOFA level. More precisely, when the plugin is loaded, the call stack gives something like this :
– line 122 of SofaPluginManager.cpp > call to method
loadPluginByPath(pluginFile,&sstream)
of the PluginManager, with pluginFile=”C:/dev/sofa/master/bd/bin/RelWithDebInfo/MeshSTEPLoader.dll”
– line 148 of PluginManager.cpp > call to method
load(pluginPath)
of the DynamicLibrary (pluginPath=”C:/dev/sofa/master/bd/bin/RelWithDebInfo/MeshSTEPLoader.dll”)
– line 74 of DynamicLibrary.cpp > call to the Windows routine::LoadLibraryA(filename.c_str())
(filename=”C:/dev/sofa/master/bd/bin/RelWithDebInfo/MeshSTEPLoader.dll”)Apparently the pointer returned by this last routine is NULL, which triggers the display of the error message I’m getting.
The beginning of the call stack is slightly different when I get the error while launching SOFA, as the plugins are automatically loaded, but in the end the behaviour is the same.I’m not yet familiar with the pull-request process and the contributions to SOFA, but I’ll be sharing the update on the MeshSTEPLoader plugin as soon as possible!
Best,
Camille
