Spring orientation with LAW108 is not correct. about openradioss

[sebastienVilleneuve]

@SonSiont
Merged

33cce08

Sébastien

[PaulAltair]

Hi, LAW108 isn't equivalent to PROP TYPE13, it is equivalent to PROP TYPE8, if you change to LAW113 which is equivalent to PROP TYPE13 then it behaves per your prop based model see bushing1M13 in this zip: springdir.zip that would be my recommendation for a finite length spring.

Explanation of why 108/8 behave differently:

With LAW 108/PROP 8 because your spring tension compression direction (but NOT 'orientation') are defined by node 1-2 and in effect it is acting as though it is zero length, the positions of the nodes don't really matter, and your springs nodes are oriented opposite to one another, they are actually both in compression (you can see that the force is -ve in both springs),

This is because the spring system is global x (since no local skew is defined)

for 91, it is clear enough spring force direction is same sense as global X and spring is 'shortening' so it is in compression
but for 97, the sense of tension/compression is inverted relative to the global system, so it is actually 'shortening' too

So If you reverse the direction of one of your springs (so they both face the same way, then the behaviour will be correct (if you align them both with global system, or... both springs will be wrong if you reverse the other one)

So: If I reverse spring 91, then you get the reduced force, but actually in the 'compression' spring (model bushing1MR), if I instead reverse the 2nd spring (model bushing1MRR), then the behaviour is 'correct' (tension is now low, compression high) as both compression/tension systems are aligned with the spring system

Hope this makes sense

[SonSiont]

Hi,
I had the problem with an LS-DYNA file. A cutting out of my model which was based on the NHTSA iss2023 model is here:
bushing.k.gz ,

Maybe I change the question a bit: What can I do to make the LS-DYNA file running as I expect?
In the meantime I look into your suggestion.
best regards

[PaulAltair]

I think your DYNA setup is slightly incorrect anyway (for DYNA) SCOOR should be set = 2 in beam section if you have finite length springs to get the expected behaviour?
This wouldn't help running it in OpenRadioss though as SCOOR isn't considered on *SECTION_BEAM today

For this usecase we need to have a look at how we interpret input for this type of setup (non linear finite length spring beams)
I don't know of a way to get the behaviour you want right now (in OpenRadioss) using Dyna input for this scenario, the only workaround I can think of, is to use the very latest builds and the (as yet undocumented) *INCLUDE_RADIOSS in the dyna input to include the 'correct' set up in Radioss format for the springs (LAW_113 so the spring orientations are set using nodes 1-2), you can define the springs and their mats/props in a radioss format file and include that in your dyna model (removing the equivalent bits from dyna format) in attached model (based on your file), the springs, mat, prop and functions are in a radioss format include, you run the .k file as before, and it picks up the radioss include
INCLUDE_RADIOSS.zip

[SonSiont]

Hi,
you are right with SCOOR I have not filled in the value.
The include solution looks promising. My job produce results:
,
.
I am not able to postprocess springs with something like /ANIM/SPRING/FORC with paraview while beams are working. Do you have an hint how to do it?
best regards

[PaulAltair]

Yes, it seems the /ANIM/SPRING/FORC output is not coming across in vtk conversion (it is there in the original Annn files) I guess it needs to be added to the vtk conversion tool, I'll ask!

[sebastienVilleneuve]

@SonSiont

I'm working to correct this .
We will let you know soon , but I found a bug .

Regards,
Sébastien

[sebastienVilleneuve]

@SonSiont

Correction ongoing
#1574

Sébastien

[SonSiont]

Thanks,
it works well:


Now I can highlight the difference between a rigid spider and the spring solution. In the picture above the tear off is visible.

I struggle a bit with the *INCLUDE_RADIOSS with the pilot node in RADIOSS for rigids while these are not in LS-DYNA but I try to handle it.

[PaulAltair]

Do you mean you are now also including radioss format /RBODY? and that the main node should be 'free'? Or some other issue?

[SonSiont]

When an rigid body is translated to RADIOSS, the pilot node is a new node with arbitrary number. When apply a load to it, the pilot node should be used for the load. At the moment it seems to be that I can put the load alternative to an extra_node.

[PaulAltair]

If the load input on the Rigid is valid for Dyna then it should also work after translation, the main node of the Rbody should be created automatically, if you have a use case where it isn't working as expected can you share more details?