I am trying to simulate a honeycomb-like material, and though that perhaps MAT_HONEYCOMB would work.
I went to test that this material model, and found unexpected (to me) behaviour: The stress is dependent on the strain rate. Looking through the manuals, I see that the material can be strain rate dependent (using the variable LCSR), but does not have to be.
To test the material, I made a single hexahedral element of the material, fixed one side, and applied prescribed motion to the other side. This used MAT_HONEYCOMB, for which I used a load curve with a constant value to define the various stress load curves. I did not set the strain rate dependent curve, LCSR.
After running this simulation, I find that the stress in the material is higher than the value set in the load curves. I find that the boundary force recorded to compress the element agrees with the reported stress, higher than what is configured in the model. By changing the rate of the boundary motion, I find that the amount the stress exceeds the limit I set in the model is proportional to the strain rate.
This is unexpected to me. According to equations 22.26.6 and 22.26.7 in the theory manual, I expect the stress to be limited to the value set in the load curve, and not dependent on strain rate.
Can anyone shed light on an effect I am missing, or do these materials simply not behave as documented?
I have made a simple example model to demonstrate the effect, which is attached. In this model, 6 single element parts are crushed by prescribed motion. Two cubes are MAT_HONEYCOMB, two are MAT_CRUSHABLE_FOAM, and two are MAT_SOIL_AND_FOAM. One piece of each material is crushed quickly, and one is crushed more slowly. Both MAT_HONEYCOMB and MAT_CRUSHABLE_FOAM show greater stress when crushed quickly, while MAT_SOIL_AND_FOAM behaves as expected, ignoring strain rate [side note: to make the SOIL_AND_FOAM work, I had to constrain its nodes to not move except in the direction of crushing, to stop the material simply spreading out]
PS Further experimentation indicates that the magnitude of this effect is proportional to the density assigned to the material.
Hi @mrsmith,
Interesting question. I'm not familiar with this particular material but it looks like there might be other factors at play in terms of influencing the perceived strain-rate. I don't know your units but it looks like you have a defined displacement of 1 over the course of your simulation but your elements are only 0.1. The honeycomb material also has a relative volume defined for when it's fully compacted, which I understand has the same elastic modulus as the uncompacted state. Maybe try changing your displacement to be less than the point of where that material would be considered compacted and see if you get the same results. You can also try Mat_modified_honeycomb 126 and look at your results there too.
Below is an old paper I found that was pretty interesting as well.
https://www.dynalook.com/conferences/international-conf-2002/Session_7-1.pdf
Thanks for taking the time to look at this, and the reference to the paper.
I dug a little further. It turns out that LS-dyna interprets a value of "0.0" for material viscosity (MU) as "Use the default of 0.05". If I set it to a very low number (e.g. 1e-5), the strain rate dependency just about disappears.
There is also a parameter called BULK, for bulk viscosity, which has some confusing wording about setting MU to zero, but it seems this is not true - or I misunderstand it.
I was wrong when I said earlier the magnitude of the effect is proportional to density. It's actually proportional to sqrt(Density * E_compressed) * strain_rate ; and is also affected by Poisson's Ratio. But I stopped investigating when I found the viscosity was the problem, so didn't find the exact formula.
Anyway, I get the behaviour I desire if I set mu to be very small and BULK to zero (the second I only do because the doco's say that's recommended).
PS I realise I should have posted the charts instead of the keyword file. But the displacement is scaled to 0.07 by sf in *BOUNDARY_PRESCRIBED_MOTION, so it doesn't enter the fully compressed state.