Lattice compression test in Radioss implicit vs. Optistruct
Hello everyone,
for context: I'm investigating a polyamide lattice cube in quasi-static compression (10 seconds and more). Since the findings will be later transferred to another explicit model in Radioss, the best case would be to perform it with its implicit capabilities. The model works well with the explicit Radioss solver, but it is performed at high speed (0.01s total time) to reduce the run time and is thus not applicable.
So the problem I have is twofold: the contact options are limited in with the implicit Radioss solver, and I don't seem to have the right settings as the time step gets reduced further and further until the simulation is stopped. The cube is to be compressed by a plate meshed via shell elements, but since the lattice consists of beam elements, I converted the shell elements edges to beam elements, too. This way, the TYPE11 contact can be used, but it's unstable as mentioned. I tried using the beam elements as they are in the contact definition, or by using line segments.
As I could not get it to work with Radioss, I retried the model with Optistruct only to find that the contact does not seem to be possible between shell and beam elements. Is there a workaround to this? Is the contact definition possible between two sets of beam elements?
I attached both models, and hopefully someone may be able to guide me through these problems.
Answers
-
can't you run this in Radioss with a longer runtime (maybe not 10s, but 1s)?
As it is quasi-static, using some TimeStep control to increase it, would be helpful, maybe.
Even if some mass is added, i don't think this would be so bad as it is quasi static and dynamics wouldn't be a huge issue, probably.
0 -
Adriano A. Koga_21884 said:
can't you run this in Radioss with a longer runtime (maybe not 10s, but 1s)?
As it is quasi-static, using some TimeStep control to increase it, would be helpful, maybe.
Even if some mass is added, i don't think this would be so bad as it is quasi static and dynamics wouldn't be a huge issue, probably.
Hello @Adriano A. Koga, now I tried both AMS and CST versions of a displacement-controlled (40mm/s for the moment) compressed lattice, but it seems that there's some instability. When using a larger time step of 1e-6s instead of the 1e-7s that's stable with the CST and AMS time step control, the beam elements rupture directly upon touching the compressing plate, even when the default EPS_P_max value of 1e30 is used. Type24 is used for the contact formulation between the P18 beam elements and P1 shell plate. Could you please have a look? Thanks in advance.
0 -
Your CST model was still using AMS.. In attached I changed to CST, changed contact to TYPE 7 with fixed gap of 2 (so compression begins immediately) added a TYPE 11 for beam-beam contact
I set timestep as 5e-7
This runs ok, but your BCS at the bottom is only in DOF 123, so the cube pivots around the constraint during loading, is this intentional?
0 -
Paul Sharp_21301 said:
Your CST model was still using AMS.. In attached I changed to CST, changed contact to TYPE 7 with fixed gap of 2 (so compression begins immediately) added a TYPE 11 for beam-beam contact
I set timestep as 5e-7
This runs ok, but your BCS at the bottom is only in DOF 123, so the cube pivots around the constraint during loading, is this intentional?
Hello @Paul Sharp , it looks like my concentration is severely lacking today. The AMS model did not contain the updated settings as I apparently forgot to save it before uploading. I attached the model in question with a 1e-6s time step, AMS and failing beam elements upon contact when they should not. The gap should be left at the default value since the beam diameters will be varied during a DOE study, so a fixed gap is not applicable. It could, of course, be controlled in the DOE setup as a function of the upper beam component's thickness, too.
The BC at the bottom should, in fact, contain DOF1-6. That's another oversight on my part. The Type11 beam self contact is not necessary for the moment. Is there a specific reason why you changed the Type24 contact to a Type7?
0 -
Ingeniorator said:
Hello @Paul Sharp , it looks like my concentration is severely lacking today. The AMS model did not contain the updated settings as I apparently forgot to save it before uploading. I attached the model in question with a 1e-6s time step, AMS and failing beam elements upon contact when they should not. The gap should be left at the default value since the beam diameters will be varied during a DOE study, so a fixed gap is not applicable. It could, of course, be controlled in the DOE setup as a function of the upper beam component's thickness, too.
The BC at the bottom should, in fact, contain DOF1-6. That's another oversight on my part. The Type11 beam self contact is not necessary for the moment. Is there a specific reason why you changed the Type24 contact to a Type7?
Hi, no, it was the other way around, your model flagged as CST did have the AMS settings
If you are varying the beam diameters with your DOE, that is why you do want to leave the gap as constant between plate and beams, otherwise the gap between the cube and the loading plate will change as you change the beam diameters. Setting it as constant as I did, the plate will contact at the same point regardless of the cube properties.
I used type7, as in that you are able to set the gap manually (type 24 is always automatic)
0 -
Paul Sharp_21301 said:
Hi, no, it was the other way around, your model flagged as CST did have the AMS settings
If you are varying the beam diameters with your DOE, that is why you do want to leave the gap as constant between plate and beams, otherwise the gap between the cube and the loading plate will change as you change the beam diameters. Setting it as constant as I did, the plate will contact at the same point regardless of the cube properties.
I used type7, as in that you are able to set the gap manually (type 24 is always automatic)
Well I see my concentration won't get any better today.
Thanks for your explanation, that makes sense of course. Do you happen to know why none of the models, with RADIOSS implicit/explicit with CST/AMS or Optistruct, work? Especially the exploding beam elements with RADIOSS explicit and CST/AMS at larger time steps are an oddity. Ideally the total simulation time would need to be somewhere between 5-10 seconds in order for the model to be comparable with the planned tests, and waiting >1hr per simulation with not even 10k elements when using a small but stable time step is not very efficient.
0 -
Ingeniorator said:
Well I see my concentration won't get any better today.
Thanks for your explanation, that makes sense of course. Do you happen to know why none of the models, with RADIOSS implicit/explicit with CST/AMS or Optistruct, work? Especially the exploding beam elements with RADIOSS explicit and CST/AMS at larger time steps are an oddity. Ideally the total simulation time would need to be somewhere between 5-10 seconds in order for the model to be comparable with the planned tests, and waiting >1hr per simulation with not even 10k elements when using a small but stable time step is not very efficient.
You aren't using implicit here, just explicit, and it works ok so long as you use a reasonable timestep, attached version has the BCS corrected and timestep of 1e-5, added mass is at 25000x so you probably don't want to go too much further! but kinetic energy is still relatively low. It will takes around 1 minute to run on my laptop, io is a significant contribution then (if I reduce output frequency for animations to 1e-2 it only takes 28s)
0 -
Paul Sharp_21301 said:
You aren't using implicit here, just explicit, and it works ok so long as you use a reasonable timestep, attached version has the BCS corrected and timestep of 1e-5, added mass is at 25000x so you probably don't want to go too much further! but kinetic energy is still relatively low. It will takes around 1 minute to run on my laptop, io is a significant contribution then (if I reduce output frequency for animations to 1e-2 it only takes 28s)
Yes, the implicit models (RADIOSS/Optistruct) are attached in the opening post.
It's very odd that the model works as expected with the Type7 contact, but not with the Type20 or Type24. Thank you very much for your input, it's greatly appreciated as always. I'll try to see where the error comes from exactly and also to get it to work with AMS.
0 -
As Adriano said, I think explicit is the way to do this, rather than going back to Implicit, Radioss implicit is very limited in its capabilities and wouldn't be a good choice here. TYPE 20 is an older deprecated contact. The only issue with using TYPE24 here is that the contact thickness is very small and will vary with your DOE
Attached is set up for TYPE24, plate is moved down to closer to the beams and Inacti set 5, it runs, but is slower than with TYPE7 with fixed gap.
AMS is likely of little benefit here, you would get lower added mass, but each cycle would take longer to solve, since KE is low relative to the total in any case AMS isn't really needed, all you will do is slow your run down I think
0 -
Paul Sharp_21301 said:
As Adriano said, I think explicit is the way to do this, rather than going back to Implicit, Radioss implicit is very limited in its capabilities and wouldn't be a good choice here. TYPE 20 is an older deprecated contact. The only issue with using TYPE24 here is that the contact thickness is very small and will vary with your DOE
Attached is set up for TYPE24, plate is moved down to closer to the beams and Inacti set 5, it runs, but is slower than with TYPE7 with fixed gap.
AMS is likely of little benefit here, you would get lower added mass, but each cycle would take longer to solve, since KE is low relative to the total in any case AMS isn't really needed, all you will do is slow your run down I think
Type7 seems to be the way to go, then. I chose Type20/24 before because I was unaware that you could use a LINE set in Type7 for shell/beam contact, too.
Radioss implicit is indeed pretty restricted, my assumption was that any setting from the implicit solver could be transferred.
The explicit solver with CST time step control does seem to run pretty well and fast enough. Oddly, applying the AMS setting with a 1e-5s time step to your previous model (LatticeGradingDispCST_PS_1e-5.hm) fails after only a few cycles. I find this to be strange as I expected AMS to be more stable than the CST setting. Additionally, you used CST_0 instead of CST_2. Is there a specific reason you chose CST_0 over the other for this case?
0 -
Ingeniorator said:
Type7 seems to be the way to go, then. I chose Type20/24 before because I was unaware that you could use a LINE set in Type7 for shell/beam contact, too.
Radioss implicit is indeed pretty restricted, my assumption was that any setting from the implicit solver could be transferred.
The explicit solver with CST time step control does seem to run pretty well and fast enough. Oddly, applying the AMS setting with a 1e-5s time step to your previous model (LatticeGradingDispCST_PS_1e-5.hm) fails after only a few cycles. I find this to be strange as I expected AMS to be more stable than the CST setting. Additionally, you used CST_0 instead of CST_2. Is there a specific reason you chose CST_0 over the other for this case?
Type 7 does not have 'LINE' input for beams, only shells on main side, nodes on secondary, that is all you need with a flat loading plate as you have here if you are not considering beam to beam contact (in that case you could add TYPE11 as I did before)
'CST' is 'CST2' by default so there is no need to explicitly set it CST2
0
Altair Employee