General questions about HM/Radioss usage
Hello everyone, I'm fairly new to Radioss and I'm simulating a drop analysis of a rigid dummy head in a bicycle helmet with a liner consisting of an elastomeric lattice liner instead of a foam liner. For the moment, the liner is modelled using first order beam elements for testing purposes and the material behaviour is linearly elastic. On to the questions:
1. How can a selection of 1D-elements be split (preferably n times)? Some TCL scripts can be found via Google, but they did not run correctly. The link to Script #1013: Split 1D beams mentioned here: https://insider.altairhyperworks.com/scripts-of-the-month-5/ leads to the signing in page and then not to the right page.
2. I noticed that with a type 20 interface and default Stfac of 0.1, the rigid dummy head (master) is penetrated severely by the lattice (slave). Increasing the Stfac to 100 or more remedies this, but seems to artificially stiffen the interface way too much. I'm aware that this is the intended behaviour, however how can the right balance be determined?
3. How can a large amount of energy loss during a simulation run be remedied? Depending on the lattice thickness, up to 50% seem to get lost.
4. What's the cause of a mass change of >10% already present in the first calculation cycle?
Answers
-
Hi,
2. The type 20 interface is obsolete. It uses a constant penalty stiffness which also makes interface timestep constant, but may not prevent contact penetration and model the contact properly. Use type 11 or 19 (7+11 combined) and make sure to define realistic material properties assigned to dummy head component, as it is used for contact stiffness calculation. The issue of modeling contact between Soft Part against Hard Part is covered in the Radioss ebook.
3. Identify the source of the energy dissipation by plotting energy graphs (also covered in the ebook). Besides hourglassing, contact with friction could be the source of major energy dissipation.
4. The cause of major mass change could be inappropriate mass scaling. There is a chapter in the ebook on how to properly use timestep control. A minor mass change could be caused by option Spotflag =1 used in the Interface TYPE2. In this case, make sure the slave node's height with respect to the master segments is as small as possible.
0 -
Simon Križnik said:
Hi,
2. The type 20 interface is obsolete. It uses a constant penalty stiffness which also makes interface timestep constant, but may not prevent contact penetration and model the contact properly. Use type 11 or 19 (7+11 combined) and make sure to define realistic material properties assigned to dummy head component, as it is used for contact stiffness calculation. The issue of modeling contact between Soft Part against Hard Part is covered in the Radioss ebook.
3. Identify the source of the energy dissipation by plotting energy graphs (also covered in the ebook). Besides hourglassing, contact with friction could be the source of major energy dissipation.
4. The cause of major mass change could be inappropriate mass scaling. There is a chapter in the ebook on how to properly use timestep control. A minor mass change could be caused by option Spotflag =1 used in the Interface TYPE2. In this case, make sure the slave node's height with respect to the master segments is as small as possible.
Hi Simon, I'm currently working through the ebook, however a few things remain unclear to me.
2. I would have used a type 19 interface, but I had troubles correctly defining the beam elements as slaves. Defining them via their component collector yields the error message 119 saying that the lagrangian surface is empty. When selecting elements, only shells or solid faces are allowed. Also, I don't know how which set type to define for it to be selectable as slave option. Apparently, it will only accept surface segments, but not line segments, GRNODE, GRBEAM or LINE sets. Trying to define the beam elements as surf segment yields error 78 in the check run. Please point me to a tutorial treating interface 19 for beam elements, because I did not find any at all. I'll look for other interface types as well, type 24 might be what is needed. I suspect that type 19 is exclusively for shells and solids, but not beams.
3. Would a fluctuation such as shown below be acceptable?
4. No mass scaling was used. Indeed Spotflag=1 is active, but setting it to 5 (default) yields negative mass/inertia errors on several nodes, and type 25 yields extremely small time steps and -99.9% energy error from the beginning. The recommendation I found in this forum was to set it to 1 in this case. What's your take on this?
0 -
Ingeniorator said:
Hi Simon, I'm currently working through the ebook, however a few things remain unclear to me.
2. I would have used a type 19 interface, but I had troubles correctly defining the beam elements as slaves. Defining them via their component collector yields the error message 119 saying that the lagrangian surface is empty. When selecting elements, only shells or solid faces are allowed. Also, I don't know how which set type to define for it to be selectable as slave option. Apparently, it will only accept surface segments, but not line segments, GRNODE, GRBEAM or LINE sets. Trying to define the beam elements as surf segment yields error 78 in the check run. Please point me to a tutorial treating interface 19 for beam elements, because I did not find any at all. I'll look for other interface types as well, type 24 might be what is needed. I suspect that type 19 is exclusively for shells and solids, but not beams.
3. Would a fluctuation such as shown below be acceptable?
4. No mass scaling was used. Indeed Spotflag=1 is active, but setting it to 5 (default) yields negative mass/inertia errors on several nodes, and type 25 yields extremely small time steps and -99.9% energy error from the beginning. The recommendation I found in this forum was to set it to 1 in this case. What's your take on this?
2. There are some software bugs with line segments creation. The procedure that works on my end is attached. A similar tutorial can be found, relevant from 17:00
https://www.youtube.com/watch?v=mLGwVwYSmt4
3. The attached energy graph is consistent with a drop test. There is no hourglass energy and the majority of energy dissipation is due to contact energy, which is too high (preferably below 5%, not more than 15%).High contact energy in case:
- Too soft contact stiffness
- Too stiff contact stiffness
To avoid high contact energy:
- Set physical material parameters (young modulus, thickness)
- Set recommended parameter for the contact definition
- Set “physical” contact interface gap value.
- Large contact energies relative to total energy can cause large negative Energy Errors because contact energy is not part of the Energy Error equation. If the simulation has friction and a lot of sliding contact, then the large contact energy and resulting energy error can be considered acceptable (verify by running simulation without friction).
The DTE energy is almost constant, but the reason for its fluctuation should be explained (probably contact issue). The difference between the initial total energy (3.5e5) and final (2.5e5) could be partially explained by the 1.5e5 energy lost due to contact, but there is an additional 5e4 work added to the system, probably by external forces work, mainly gravity (verify by plotting external forces work and running without gravity). For more details refer to this topic:
Altair Radioss - eNERGY eRROR - Altair Community
4. As mentioned previously, close proximity between the slave node and the master segment is necessary for Interface Type 2 to work normally, and will help to get a lower added mass when using Spotflag=1. Spotflag=5 is failing for the same reason, the mass/inertia of tied connection is causing the errors. Sptoflag=25 may sidestep the issue with a penalty formulation (stiffness, not kinematic condition) at a high computational cost. Check and resolve the tied slave node projection issues in Hypercrash>connections>spotweld0 -
Hi
about your fist item.
it seems link does not lead to any.
There is this script to split beams, on OptiStruct user profile.
" Splitting beam element in N-elements (OptiStruct User profile)"
I hope this is helpful.
Regards
0 -
Rogerio Nakano_21179 said:
Hi
about your fist item.
it seems link does not lead to any.
There is this script to split beams, on OptiStruct user profile.
" Splitting beam element in N-elements (OptiStruct User profile)"
I hope this is helpful.
Regards
Hi Rogerio, thank you very much for the script. It does work, however it creates a new property for each newly created element. Seeing that I'm working with approximately 55k beam elements, it seems to become quite unwieldy. It's running with half of the element count for now, but it's unresponsive and it may or may not finish. Is there a version of the script that's using the original property for all the new elements?
Edited: Nevermind, I found another route. Thank you nonetheless.
0 -
Simon Križnik said:
2. There are some software bugs with line segments creation. The procedure that works on my end is attached. A similar tutorial can be found, relevant from 17:00
https://www.youtube.com/watch?v=mLGwVwYSmt4
3. The attached energy graph is consistent with a drop test. There is no hourglass energy and the majority of energy dissipation is due to contact energy, which is too high (preferably below 5%, not more than 15%).High contact energy in case:
- Too soft contact stiffness
- Too stiff contact stiffness
To avoid high contact energy:
- Set physical material parameters (young modulus, thickness)
- Set recommended parameter for the contact definition
- Set “physical” contact interface gap value.
- Large contact energies relative to total energy can cause large negative Energy Errors because contact energy is not part of the Energy Error equation. If the simulation has friction and a lot of sliding contact, then the large contact energy and resulting energy error can be considered acceptable (verify by running simulation without friction).
The DTE energy is almost constant, but the reason for its fluctuation should be explained (probably contact issue). The difference between the initial total energy (3.5e5) and final (2.5e5) could be partially explained by the 1.5e5 energy lost due to contact, but there is an additional 5e4 work added to the system, probably by external forces work, mainly gravity (verify by plotting external forces work and running without gravity). For more details refer to this topic:
Altair Radioss - eNERGY eRROR - Altair Community
4. As mentioned previously, close proximity between the slave node and the master segment is necessary for Interface Type 2 to work normally, and will help to get a lower added mass when using Spotflag=1. Spotflag=5 is failing for the same reason, the mass/inertia of tied connection is causing the errors. Sptoflag=25 may sidestep the issue with a penalty formulation (stiffness, not kinematic condition) at a high computational cost. Check and resolve the tied slave node projection issues in Hypercrash>connections>spotweldHello Simon, thank you very much for your input.
2. The procedure shown in both videos is in the context of a type 11 interface, but a type 19 interface does not accept line segments, only surface segments. As mentioned above, I tried defining the 1D beams as a surface segment set, which was rejected by the pre-run model check.
3. Thanks for the summary, I will explore these points thoroughly.
4. I forgot to mention that, since I was not familiar enough with Radioss, I first set up a model with Optistruct explicit as a baseline, then ran it again with the Radioss integration option. I then imported the .rad input file to Hypermesh to investigate its settings and tried to replicate them with a model built from scratch. Interestingly, the model exported from OS to Radioss behaved as expected, showing a nice collapse of the lattice liner (with a type 2 interface, spotflag=1 and dsearch=2mm between lattice liner and helmet shell and type 20 interfaces between the remaining components), whereas the newly built model with (what I thought were) the same settings was much too stiff in the type 20 interface between the dummy head and the lattice liner, such that the liner barely deformed and the dummy head quickly bounced back. The stiffness factor in the type 20 interface had no influence on the overall lattice stiffness, and after switching the type 2 interface with spotflag=1 between the lattice liner and the helmet shell to a type 24 for testing purposes, it behaved as intended again. This was very odd since I just replicated the settings from the type 2 interface from the imported model. I will investigate this further and most likely rebuild the model again.
0 -
Ingeniorator said:
Hello Simon, thank you very much for your input.
2. The procedure shown in both videos is in the context of a type 11 interface, but a type 19 interface does not accept line segments, only surface segments. As mentioned above, I tried defining the 1D beams as a surface segment set, which was rejected by the pre-run model check.
3. Thanks for the summary, I will explore these points thoroughly.
4. I forgot to mention that, since I was not familiar enough with Radioss, I first set up a model with Optistruct explicit as a baseline, then ran it again with the Radioss integration option. I then imported the .rad input file to Hypermesh to investigate its settings and tried to replicate them with a model built from scratch. Interestingly, the model exported from OS to Radioss behaved as expected, showing a nice collapse of the lattice liner (with a type 2 interface, spotflag=1 and dsearch=2mm between lattice liner and helmet shell and type 20 interfaces between the remaining components), whereas the newly built model with (what I thought were) the same settings was much too stiff in the type 20 interface between the dummy head and the lattice liner, such that the liner barely deformed and the dummy head quickly bounced back. The stiffness factor in the type 20 interface had no influence on the overall lattice stiffness, and after switching the type 2 interface with spotflag=1 between the lattice liner and the helmet shell to a type 24 for testing purposes, it behaved as intended again. This was very odd since I just replicated the settings from the type 2 interface from the imported model. I will investigate this further and most likely rebuild the model again.
2. It seems there is a limitation with defining line segments in type 19. Since type 19 is just a combination of types 7 and 11, there is a workaround by creating separate type 7 and 11 interfaces. If you need to capture shell edges to beam contact, follow the procedure already shown to extract line segments from shells using the edges panel.
4. Without a model it is hard to assess the issues. There may be incompatible kinematic conditions between nodes tied to the master surface and contact interfaces, penetrations & intersections, and node height projection issues in the tied contact.
0 -
Simon Križnik said:
2. It seems there is a limitation with defining line segments in type 19. Since type 19 is just a combination of types 7 and 11, there is a workaround by creating separate type 7 and 11 interfaces. If you need to capture shell edges to beam contact, follow the procedure already shown to extract line segments from shells using the edges panel.
4. Without a model it is hard to assess the issues. There may be incompatible kinematic conditions between nodes tied to the master surface and contact interfaces, penetrations & intersections, and node height projection issues in the tied contact.
Thank you for your insights, unfortunately I can't share the model since it contains proprietary geometries. I will rebuild the model and if I don't find the error(s), I'll get back to you and share a similar model if possible.
Indeed there are quite a few initial penetrations between the beam elements and the helmet shell due to the way that both meshes are created. I'll remedy this issue if possible.
0