28 September 2015 at 10 h 52 min #3679
I have an issue modelling pure elastic behaviour with TetrahedronFEMForcField. I have a piece of metallic component and all I’m trying to do is to lift it up a bit vertically (at the top) and then lower it to its original position. The model has quite a few nodes (~10 000).
I’m trying to use the TetrahedronFEMForcField, however the model always seem to be plastic, with the bottom bit hardly moving. I tried to play around with the parameters plasticMaxThreshold, plasticYieldThreshold and plasticCreep, but no luck. Any ideas?
I try to attach an image showing it at the start, at the lifted and at the final position.
Link28 September 2015 at 11 h 14 min #3680
First, you should write your scene with the components in the right order:
and the visual is usually defined in a subnode (with the identity mapping).
If it is still not working, could you send us a link to the scene + mesh so that we can reproduce your issue ?
Hugo28 September 2015 at 13 h 00 min #3681
Changing the order did not help.
I uploaded the files, they’re here.
(I removed TPointModel as that is not needed yet)
Zsolt28 September 2015 at 20 h 07 min #3682
From the simulation it is hard to see if the deformation is plastic or elastic. The only way to assess the nature of the deformation is to track the stress/strain evolution. Then, you could know the type of deformation.
Are you tracking those values ?
Hugo29 September 2015 at 10 h 19 min #3697
No I’m not monitoring stress and strain (I know how to get the Mises stress, but not the strain actually)
However, the component is made of steel. It can/should not behave like this (E=2e11, nu=0.3).
The only load is gravity really and the lifting is slow.
I did an ANSYS analysis and the total displacement is about 5 mm (while the length of this component is about 15m) for its own weight. So it should be really rigid.
So what I’m suspecting that maybe it’s one of those parameters (plasticMaxThreshold, plasticYieldThreshold and plasticCreep) that are not set properly and that’s why it looks so rubbery/jelly like. Is there a setting for pure elastic behaviour? For now, that would be a good enough approach. Or what their physical meaning is? Should plasticYieldThreshold be 0.002 (0.2%) for most metals? Or is it something completely different.
Zsolt2 October 2015 at 14 h 18 min #3728
That’s good to make comparison of SOFA with other simulation softwares: we are currently starting new work in that direction to validate our codes.
In your SOFA simulation, you defined a LinearMMovementConstraint: so you are constraining the motion in displacement. Since no fixed constraint is defined, your object is following this motion constraint.
I am not sure to understand the mechanical test you want to compute: could you explain me the boundary conditions of your simulation ?
I will try to get more information for you.
Hugo5 October 2015 at 10 h 14 min #3735
Well this just only part of the problem that I have built so far. There will be other components and then the component would be moved around on a given path so that it should not collide with other components. It may be even possible that there are more moving flexible bodies that will have to avoid collision of the stationary rigid bodies (or the other moving flexible bodies).
In this simple test I just move the component up and down, before setting up anything more complicated. My problem is that the object is not following the prescribed motion. Although it is a flexible body it’s quite rigid due to its properties, so nothing exciting should be happening really. But when the lifting happens only the top part seem to be moving, it stretches a lot while the bottom seems to be stuck in place. Later on there is a lot of movement happening everywhere, but it looks quite unrealistic for steel. That’s why I’m suspecting that something setting the plastic behaviour is wrong.
I tried other FEM forcefields (like fastTetrahedralCorotational), but then the max Young’s modulus is limited to 9e+10 (Aluminium has that kind of E). Actually that too produces a quite surprising result. I’d expect a stiffer behaviour for that too.
Zsolt16 November 2015 at 17 h 39 min #4153
Ok, your final goal sounds a bit complicated (or complicated to explain through the forum!). I created a video of what you are computing, it seems quite unrealistic indeed !
Did you check the units of your simulation. I see 9.81 m/s as a gravity acceleration and I opened your mesh which is about 16 meters long ! is that normal ?
Hugo17 November 2015 at 13 h 36 min #4157
Yes, I checked the dimensions and they should be OK.
Indeed, the height of the model is about that. The final goal is complicated, but we don’t have to do it by tomorrow. 🙂
Did you change some settings in the model? Your simulation looks far better than what I can do. I’ll try to do a video as well, so you can have a look (probably later this week).
In the meantime, I tried to set up some verification examples. A simple 3D beam with gravity acting on it. I compare the results (nodal reaction forces) with ANSYS (because that’s what we use normally). And it seems that for the same problem the difference between the two increases if I increase the mesh density. Normally I would expect an increased accuracy with more elements. So it’s a bit odd.
I will set up a few more test cases to see if this is a general behaviour or specific to the problem.
Zsolt10 December 2015 at 9 h 21 min #4845
Thanks for your feedback.
As mentionned above, we are currently starting new work in that direction to validate our codes. So I’ll let you know about our own advances in comparing Abaqus (in our case) and SOFA.
Hugo2 October 2018 at 15 h 24 min #12074EleonoraParticipant
- University of Verona
I have found this quite old topic and I wanted to ask if you’ve ever succeeded in comparing SOFA solutions with those of other softwares in the meanwhile.
I was indeed trying to simulate the same scenario mentioned above (3D linear elastic beam with gravity, fixed at one end) but results are not exactly as I expected. As Zsolt was mentioning, maybe there are some parameters (apart from the elastic modulus and Poisson ratio) that should be considered and tuned.
Eleonora3 October 2018 at 12 h 07 min #12081CamilleKParticipant
- PhD student
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)
Camille3 October 2018 at 12 h 47 min #12082EleonoraParticipant
- University of Verona
Thank you for your reply.
Actually I have been a bit vague by calling it “beam”, indeed what I am trying to simulate is a parallelepiped (thus, beam-shaped) modelled with a TetrahedralCorotationalFEM (which does not implement plasticity, likewise the BeamFEM). I guess I’m just having some discretization/numerical issues, but in order to be sure of that, it would be interesting to have some reference validations of SOFA implementations with those of other softwares. We could definitely open another topic on this.
Eleonora3 October 2018 at 20 h 46 min #12091
I think the starting a common project around SOFA validation (against other solutions and analytical solutions when existing) would be a great idea. We have many interested partners for this.
- You must be logged in to reply to this topic.