Hello team
First I would like to thank you for your great job.
I just played with the new coordinate system and made a small test case. Aplaying a surface traction on a face unsing 2 Steps (1. Step Load applyed in global coord. system, 2. Step the load is given in local coord. system). The 2. step was created by duplicate and then the load was modified.
Alter solving I observed different results for Step1 and Step 2 which I don’t understand.
Than I saved the test-file to test1.pxm, where i deleted step 2) and I saved it to test2.pxm, where I deleted step 1. Solving both will lead to the same results.
Is ther anay expalnation, what I am doing wrong?
Files are here WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free
Thank you
For the Rectangular coordinate system the manual figure suguest the X’ axis is build form origin to point a
How is the X’ axis build in the Cylindrical coordinate system?. Being othogonal to the Z’ axis (vector connecting a to b) doesn’t seem enought to define it.
2 points are not enough. Not even for the rectangular system.
However, it is unnecessary since all data regarding coordinate systems are directions not actual displacements. For a cylindrical system, only the position of the axis is needed. Then radial, transversal, and axial directions can be determined.
Thanks Matej.
Then it’s probably assumed local X’ Cylindrical Axis is internally built as a vector orthogonal to Z’ and passing through the node.
That would make it difficult to plot a unique symbol for the whole Nset as RR’ and TT’ changes direction for each node on the Nset.
One option could be to plot a unique common Z’ axis and the local RR’ and TT’ on top of each node.(Not sure how much it could overload the screen with vectors)
That’s not the case for the new X’ Y’ and Z’ in Rectangular. New Rectangular Coordinates system is common for all nodes in the NSet.
I’m not Abaqus user but it looks like the procedure to define a new Global Cylindrical Coordinate System.
That can be useful in the geometry module to input nodes using Cylindrical coordinates for example (That’s why an origin is requested).
The cylindrical coordinate system generated by ccx *Transform is Local (one per node on the Nset). Only two points are needed (Z’ Axis) and the RR’ is individually/automatically build from each node coordinate.
If I define a load in direction 1 (RR’) , the load vector will be transformed to point in different directions radially from Z’ to the node. The model will expand.
There is not a unique RR’ axis as it seems in the vid. If there would be, all the model would move in the same direction.
I haven’t had time to look at the new Prepomax version. I will try tonight the Cylindrical transformation.
No, it’s for local (datum) coordinate systems. You can then select them to define BCs/loads or transform the results.
At least that’s how it’s defined in GUI. The rest happens internally when writing the input file. The *TRANSFORM keyword in Abaqus is also based on points a and b.
Just created a new one. I can’t find it.
I’m loading in RR direction (1) with Z’ axis pasing through the center of the disc. Radial expansion as expected.
I’m curious what Abaqus result is using that coordinate system. If one has defined R axis pointing in direction (1,0,0) I would expect disc going in that direction.
The representation of a cylindrical coordinate system as a cartesian one with r,t,a notation is common in many other FEM softwares too.
However, personally I would prefer the representation as it’s done in Ansys and keep the notation 1,2,3 for the axes:
Yes, that is true. The nodes at 0,0,0 in a cylindrical coordinate system R,T,Z have a problem with the direction of the T axis. This can be seen in PrePoMax when displaying the BC or load symbols. If the R,T,Z system is used instead of one symbol, multiple symbols are shown at selected node positions oriented in a local coordinate direction. When the node is on the axis (numerically, it is never exactly on the axis), different results might be produced, depending on the direction of the distance away from the axis.
I think this representation is misleading for CalculiX. CalculiX does not have a real cylindrical system where the second axis is curved but uses a rectangular system at each node oriented appropriately. These directions do not change during the analysis.
So you can do linear simulations with the cylindrical system and get the expected result - like using a real cylindrical system. However, for Nlgeom this does not work since the local coordinate directions of the nodes do not change. Moving in R and Z directions is OK, but moving in the T direction is not OK. The T direction is straight and not curved.
In CalculiX the coordinate system definition is model based which means it is active for all steps of the analysis. So when you use a local coordinate system in a BC or Load, in any step of the analysis (first to last or any in between), this system is permanent for the selected nodes. To make things interesting, the default field output (.frd output) is global, while the default history output (.dat output) is local. I changed the defaults to global for both but this can be changed by the user.
I was afraid of all the problems that would arise, so I postponed the coordinate system support.
I plan to add a check to see if the same nodes are used in different items and show a warning to the user, but it is not implemented yet.
thanks for your brilliant work!!! The coordinate systems are very usefull.
I am trying to use it for optics positions in a raytracing simulation!
What would be a nice addition:
Coordinate systems move between model and result (Now i just redefined the coordinate systems)
Data (e.g. text format) export of the 6DOFs of each coordinate system to use the position and orientation in raytracing
Currently, there is a bug when using a cylindrical coordinate system, which is not positioned in points 0, 0, 0. I fixed it, and it will be included in the next release.
Thank you. I could not get it to work on an example I had, and so was getting rather frustrated. The Keyword Editor worked perfectly.
I was meaning to raise a bug report but went on holiday, so just forgot about it … looking forward to the next release now.
Again, many thanks for your reply and sorry for the incomplete desciption.
I try to use the coordinate systems to get the position and orientation of optical elements to use this information for ray tracing. Therfore I define corrdinate systems in the “FE Model” tab on the meshed geometry. This coordinate system dont move with the displaced elements.
To get the position and orientation of the diplaced elements in the results tab i have to redefine the corrdinate systems because they do not move. I am pretty sure I use the coordinate system in a wrong way or in a way it is not intended to be used. I do fully understand that there is no reason to change anything for such a special (wrongly used) case.
Do you know any other way to get the positional and angular change of displaced elements?
Is it possible to get all data from cooridnate systems out with copy and past?
. I had in mind a test I made a long ago. I will search it.
… looking forward to the next release now.