A program to recognize and reward our most engaged community members
So, I know exactly how the material direction is assigned in OptiStruct, starting from G1-G2 and rotating in respect to the normal of a shell element.
But what about Radioss? Is phi exactly the same? Daniele
Hi,
In Radioss, it depends on the approach you select to define the reference direction (usually called V), through Ip parameter (in the property).
To get same modeling as OptiStruct, use Ip = 20 (direction from element connectivity (N1,N2) of the shell element).
There is a clear difference between the N1-N2 direction for an element and the direction obtained by rotating that same vector by…0 degrees!
The results stays the same using Ip = 0 (or blank) or Ip = 20 in HyperMesh. It just seems to me HyperMesh is transparent to that particular field. Look at the picture below:
The big red arrow represents the N1-N2 vector for a particular element. The small red arrow represents the material direction for that element by using phi_s = 0. How's that possible? What am I missing?
In HyperCrash instead, with a phi_s equal to 0, the material direction remains parallel to the N1-N2 vector, both using Ip = 0 or Ip = 20. Can you give me a clear understanding of the logic behind? Thanks in advance,
Daniele
Which version of HM are you using? For 'Square' elements as shown in your image, there would be no practical difference between ip = 0 and ip = 20 anyway (since in this case mid N1-N4 -> mid N2-N3 is the same as N1-N2) both should have a material direction parallel to N1-N2 for phi_s of 0. All else being equal (i.e. no drape or other influences) can you share an hm file of just those few elements?
The problem is completely independent from the version but I'll try to pose a more general question: how do phi angles work in Radioss? The visualization seems completely off in HM where I'm expecting the material direction to be exactly equal to N1-N2 but instead I'm obtaining a slightly angled direction. Also, the def_orth parameter is not available anymore…
That was why I was asking, it isn't independent of the version (Radioss or HM), since the behaviour has been updated over the last couple of releases. As you mention, def_orth used to be required in older Radioss versions in order for phi to be read/used at all, but in todays version (2025.1), def_orth is no longer used/available and phi_s is always read. The specific usage of skew/Vector/phi_s etc is controlled by the Ip flag: per below image from help, but in older releases this was not the case, and visualisation of the different IP options have different levels of support in different HM versions also (even now only IP = blank and IP = 20 are supported I think)
If you are using IP = 20 and have a phi_s, then it should be the same as a THETA for OS (or a BETA for LS-DYNA) and be relative to the N1-N2 direction of the element. Historically the reference system of a Radioss element was from midside to midside of the element (so, for square elements, no different, but a skewed element would have a different reference (per image in upper corner above)
Thanks for per precise answer. I'm working with a much older model and def_orth is still available to me. What do I have to expect? Can I run an older model into HM '25.1? What's going to happen?
Also, can you be more specific in respect to what parameters are taken into account in every version? Thanks again!
Def_Orth was dropped from v2024, if your model is older than that (v2023 or earlier) then the element phi_s is relative to the older midside-midside radioss orientation and would not be directly interchangeable with an OS THETA or DYNA BETA (IP = 20 still existed, but in fact, setting def_orth = 1 caused it to be ignored and only phi_s to be used), this is why the updates were made in more recent versions to make the syntax/usage more similar to other codes (OS, Dyna etc). The older workaround was to use def_orth = 2 and IP=20 and drape angles in drape settings. If you read the older model into HM 2025.1 as v 2023 or 2022 it should read/write unmodfiied in that orientation regard I believe, but there will be other changes, such as updating groups - sets, you should check the rads that is output. If you read the older model into 2024 or 2025 format in HM2025, I am not sure what it does (def_orth will certainly be lost, but I don't think it will update your angles accordingly)
In short, if you need to run something now, It is safest to use the latest syntax version and convention, since, a number of modifications have been made over the last few releases, correcting bugs and clarifying ambiguities for orientations. The new methods give far more flexibility and control, more easily than what was available in the older releases. If you do retain the older input syntax, (i.e. 2023 or earlier) for continuity from older models, you can refer to the manuals for that version and running it in current release should give same behaviour as previously. If you need help for your specific model and you cannot share it here, then if you contact technical support, they ought to be able to help you.
Thanks for the precise answer Paul, actually I did open a ticket this morning 'cause things are getting misterious quickly here. HM '19 does visualize the N1-N2 direction correctly but the material direction seems to be far away from the correct one. On the other side, HM '25 gets the N1-N2 direction wrong but the material direction is parallel to it, what I was expecting with phi_s equal to 0.
You can see a square element in HM'19 in the first photo with angle phi_s equal to 0. At the bottom, the same exact square, in HM '25. The big red arrows are indicating N1-N2 directions, the little ones are indicating material directions.
