Frontal crash simulation with %ERR too big
Hey there,
I'm trying to make a simulation of a frontal crash but whenever I am simulating I get a final ERR=-45.9%. I'm no expert on Radioss, but I've done some simulations and never had such a big value in the ERR, is it normal or is there something that I'm missing out?
Thanks in advance
Best Answer
-
Albert Grima said:
Hey there! Tried so but didn't get much of a difference... Any other idea?
I took a look at your model, there are a few things I would change (the contacts with gapmin of 0.1mm, the node-surf contact between plate and support should have a symmetric copy, and the law 36 material curve does not begin at 0 plastic strain) but none of them are responsible for the energy error I don't think, rather I think in this case it is purely a numerical issue in code (a bug) related to the offsets in the composite, the global energy plots for the model and energy in FBH part look like this for my run with offsets (energy in GBH goes down sharply, ending negative, dragging TTE with it)
whereas, with no offset (ipos = 0) the energy looks fine, otherwise the model behaves pretty much identically (this part has minimal deformation)
I think in this case, your model is largely ok (you should correct the LAW36 curve and symmetric contact) and the energy error isn't genuine, I know you are an academic user, so I have raised a ticket for the bug with commercial support.
My version of your model is attached (still has the offset, so you will still get an anomalous large energy error, but you can verify my curve above by setting ipos = 0 on the stack)
2
Altair EmployeeAnswers
-
Hi Albert,
It is true that an error of 45% is a bit much. It may be due to contact friction. Friction is not taken into account in the error calculation.
Maybe you can try to run the simulation without any friction in your contact to check if the error level is coming from the friction.
Regards,
Mathis.
0 -
Hey there! Tried so but didn't get much of a difference... Any other idea?
0 -
Albert Grima said:
Hey there! Tried so but didn't get much of a difference... Any other idea?
I took a look at your model, there are a few things I would change (the contacts with gapmin of 0.1mm, the node-surf contact between plate and support should have a symmetric copy, and the law 36 material curve does not begin at 0 plastic strain) but none of them are responsible for the energy error I don't think, rather I think in this case it is purely a numerical issue in code (a bug) related to the offsets in the composite, the global energy plots for the model and energy in FBH part look like this for my run with offsets (energy in GBH goes down sharply, ending negative, dragging TTE with it)
whereas, with no offset (ipos = 0) the energy looks fine, otherwise the model behaves pretty much identically (this part has minimal deformation)
I think in this case, your model is largely ok (you should correct the LAW36 curve and symmetric contact) and the energy error isn't genuine, I know you are an academic user, so I have raised a ticket for the bug with commercial support.
My version of your model is attached (still has the offset, so you will still get an anomalous large energy error, but you can verify my curve above by setting ipos = 0 on the stack)
2 -
Paul Sharp_21301 said:
I took a look at your model, there are a few things I would change (the contacts with gapmin of 0.1mm, the node-surf contact between plate and support should have a symmetric copy, and the law 36 material curve does not begin at 0 plastic strain) but none of them are responsible for the energy error I don't think, rather I think in this case it is purely a numerical issue in code (a bug) related to the offsets in the composite, the global energy plots for the model and energy in FBH part look like this for my run with offsets (energy in GBH goes down sharply, ending negative, dragging TTE with it)
whereas, with no offset (ipos = 0) the energy looks fine, otherwise the model behaves pretty much identically (this part has minimal deformation)
I think in this case, your model is largely ok (you should correct the LAW36 curve and symmetric contact) and the energy error isn't genuine, I know you are an academic user, so I have raised a ticket for the bug with commercial support.
My version of your model is attached (still has the offset, so you will still get an anomalous large energy error, but you can verify my curve above by setting ipos = 0 on the stack)
Lovely! Made the changes to my model and it's now running. Can't see the pictures you attached but I will verify by myself as you said.
Thank you very much!
0 -
Paul Sharp_21301 said:
I took a look at your model, there are a few things I would change (the contacts with gapmin of 0.1mm, the node-surf contact between plate and support should have a symmetric copy, and the law 36 material curve does not begin at 0 plastic strain) but none of them are responsible for the energy error I don't think, rather I think in this case it is purely a numerical issue in code (a bug) related to the offsets in the composite, the global energy plots for the model and energy in FBH part look like this for my run with offsets (energy in GBH goes down sharply, ending negative, dragging TTE with it)
whereas, with no offset (ipos = 0) the energy looks fine, otherwise the model behaves pretty much identically (this part has minimal deformation)
I think in this case, your model is largely ok (you should correct the LAW36 curve and symmetric contact) and the energy error isn't genuine, I know you are an academic user, so I have raised a ticket for the bug with commercial support.
My version of your model is attached (still has the offset, so you will still get an anomalous large energy error, but you can verify my curve above by setting ipos = 0 on the stack)
Hey there!
I'm working on a similar simulation and it looks like the contact between aip & crashbox ain't working ok, as whenever I check the results it looks like it's getting through it. Any help?0 -
Albert Grima said:
Hey there!
I'm working on a similar simulation and it looks like the contact between aip & crashbox ain't working ok, as whenever I check the results it looks like it's getting through it. Any help?Hi Albert,
I have reviewed your model! You did not set the /BEGIN/CARD so your units are kg, m, s! With respect to that I have shown some of the parameters you have set for your materials:
- For EN AW 5754 material you have set rho = 2.7e-06 and E = 64.47, I think that these values correspond to the unit system (kg, mm, ms) in order to be Kg/mm^3 and GPa respectfully.
- For Honeycomb material I think that the values you use are a bit low, I would expect 1 order of magnitude higher at least. This can make your material behavior too soft.
- Your model dimensions are in m, because you have not set a /BEGIN Card. So if you measure your model in HyperMesh is something like 350 m in maximum direction, which is not correct.
So set the proper /BEGIN Card and keep in mind that any value you see corresponds to this system. I think that this strange behavior comes from this fact.
Additionally, I want to recommend some other good practices for your model interfaces. Using the recommended values shown in the following picture will help you have a better model behavior.
All the values that have dimensions should be again in the /BEGIN Card system values.
Finally for the Honeycomb material, you have set functions that describe the stress-strain diagram for compression (see the following picture):
These diagrams are not describe the tension region (positive values) and they shouldn't necessarily. During crash simulation, some of your elements can deform in a way that tension loads will applied. Radioss will calculate the stress-strain diagram for tension by extrapolating the diagram you provided for compression with the same slope at the edges of the diagram. So, this can also be a problem for your model.
Polyvios
0 -
Polyvios Romanidis said:
Hi Albert,
I have reviewed your model! You did not set the /BEGIN/CARD so your units are kg, m, s! With respect to that I have shown some of the parameters you have set for your materials:
- For EN AW 5754 material you have set rho = 2.7e-06 and E = 64.47, I think that these values correspond to the unit system (kg, mm, ms) in order to be Kg/mm^3 and GPa respectfully.
- For Honeycomb material I think that the values you use are a bit low, I would expect 1 order of magnitude higher at least. This can make your material behavior too soft.
- Your model dimensions are in m, because you have not set a /BEGIN Card. So if you measure your model in HyperMesh is something like 350 m in maximum direction, which is not correct.
So set the proper /BEGIN Card and keep in mind that any value you see corresponds to this system. I think that this strange behavior comes from this fact.
Additionally, I want to recommend some other good practices for your model interfaces. Using the recommended values shown in the following picture will help you have a better model behavior.
All the values that have dimensions should be again in the /BEGIN Card system values.
Finally for the Honeycomb material, you have set functions that describe the stress-strain diagram for compression (see the following picture):
These diagrams are not describe the tension region (positive values) and they shouldn't necessarily. During crash simulation, some of your elements can deform in a way that tension loads will applied. Radioss will calculate the stress-strain diagram for tension by extrapolating the diagram you provided for compression with the same slope at the edges of the diagram. So, this can also be a problem for your model.
Polyvios
I thought that even if you don't use the BEGIN CARD, as long as you use one of the criterias allowed, results would be ok. Thanks!
0