Hi Prepomax,
Let me first compliment the team/Matej for the amazing improvement this already excellent code is undergoing. A lot of new features every month or so is really like candy land. Many thanks !
I’d like to submit some erratic behaviour with coordinate systems. I introduced a cylindrical coordinate system which, supposedly, is radial, tangential and axial. Please note that a graphical system is drawn on the screen which, however, is not very informative because, unless I am mistaken, in practice the radial direction is defined according to the position vector from the coordinate origin to the point of interest.
When I introduce a nodal force in such system, it seems to me, unless I am mistaken, that there are some inconsistencies.
First, three fields are available, the radial, tangential and axial part of this force. If I give the radial part only for a concentrated force at a reference point, I get some force that is not aligned with the radial axis on the screen, or so it seems.
It appears that tiny miscentering of the load application point with respect to the coordinate system origin cases such random direction.
Say the coordinate system is centered in (Xs,0,0) and the force application point is (Xp,Yp 10^-13,Zp 10^-12) in the global system.
Then you get a radial force which is directed in an unpredictable manner.
So in general, Prepomax should offer a roundoff feature by which very small numbers are set to zero, on request.
But even correcting this issue, there’s still a problem.
Indeed, if I try to set the cylindrical coordinate system right on a reference point, the code moves it away, and rightly so.
This behaviour is intended to define what is radial, tangential and axial at the reference point. But even so, the code moves the origin of the system away from the reference point in the X direction only (say) but not in the Y and Z and therefore it is not clear what it is radial in this case.
In fact, the cylindrical system is undefined for any point on the system axis. For such points, I suggest adding an angle to specify where R lies (with respect to the global system axis, say X).
Still three numbers would be required, the axial, the radial and the angle that the radial axis forms with the global X (or Y or Z) axis.
Alternatively, it should not be available for points that lie right on the coordinate system axis.
However, in my application I need to apply a force at different angles and right on the axis of an axis-symmetric problem. In this case, the cylindrical system would be very helpful and precisely in this very special situation of my reference point laying on the coordinate system axis.
Thank you for all your efforts,
Andrea
PS: Why not add “deg” for the degree unit system ? It seems a small circle is used instead but not all keyboards have it.
No. The radial direction is built orthogonal to the new Z axis, passing through the point of interest and through the new Z axis.
No matter the Z coordinate of the Point of interest, Radial vector is always orthogonal to the new Z.
If you still find any disagreement considering this let us know.
EDITED: I just want to add that I don’t like the cylindrical coordinate system symbol or how it is defined, but it has been done this way to follow the ABAQUS convention.
I have seen this behavior in my test.
The problem is that I do not know the correct solution. So the question is, what direction has a concentrated load specified in the origin of the cylindrical coordinate system with only the second component defined? The direction of such force is undefined. Should it be set equal to zero? It probably depends on the model.
I don’t understand what you mean. The code does not move the coordinate system (it should not).
If you have a reference point on the axis, why use a cylindrical system al all?
The ° symbol is easy to add using AltGr + 5 followed by space on my Slovenian keyboard. I think all keyboards have such shortcuts.
Hi Guys,
We should be careful here.
First, the code DOES move the reference system.
Just open PPM and create a ref point at (0,0,0) and then create a new cylindrical coordinate system at (0,0,0).
It will work.
Then move the ref point at (10,0,0) by changing its coordinates manually.
Then try to do the same with the cylindrical system and you’ll find that it returns to (0,0,0).
Or the software crashes.
Second, concerning the cylindrical coordinate system, this is defined once you give a point (the origin O) and an axis, say Z, with unit vector k.
That’s all you need.
Then, given a point P not on the axis, its axial coordinate Z_P is obtained by Z_P=(P-O) scalar k and the radial direction is obviously
(P-O) - Z_P k
Of course this is orthogonal to the Z axis, but this was not the issue I was reporting.
What I am reporting is that if you create (in that very strange way) a cylindrical system and then want to apply a force at a point P in cylindrical coordinates, where P is not on the Z axis, the behaviour should be like I described.
In other words, the radial direction depends on P and not on the original choice of the radial direction for the cylindrical system.
If the point P is ON the Z axis, we have a problem in defining what the radial direction is. For this you need to specify the angle to define what is radial for you.
Hope this helps,
Andrea
I confirmed this behaviour. It appears in version v2.1.5. dev. It is a bug and not a feature 
It seems this happens when a rectangular coordinate system is created and added. If this coordinate system is changed to a cylindrical coordinate system, this change is discarded, and the coordinate system remains rectangular. That is why you thought the direction is wrong. Try creating a cylindrical system in the first place, and the direction will be OK. Obviously, changing the coordinate system does not work. It is the same bug as in the first case.
So we would need a field for: Radial direction angle for points on the axis (close to 1E-6 of the model size or something).
Your explanation is probably more clear and with better English than mine. Hope you convince Matej.
That’s why I don’t like the Cylindrical coordinate system symbol. It may lead to incorrect interpretation. There is not a unique R or T direction. Once Z’ axis is created , ccx generates the local cylindrical coordinate system from where all the local radial and tangential directions are generated. Axial direction is the only common to all the Nset.
¿May I ask you, which kind of problem requires a radial load to be applied to nodes on top of the z axis?. I just exclude them from the NSET.
When you say REF node, ¿is there an underlaying Rigid Body or Distributing card associated?
A new version of PrePoMax contains the bug fix for updating the coordinate systems.
Hi Matej, you are too good to be true! But watch out for the new calculix release (Guido rules) I’d use that for the new PPM release, there’s a bit of juicy staff we’d all love to experiment with.
Andrea
May I close this bug report? I think it works as expected.
Hi Matej, sure, it seems alright to me. It is still not very clear how the cylindrical system is set (I mean how to give the points so that the system is as one wants), I can only suggest to add a note in this direction in the windows that pops up when setting up the new system. Regards.
Ok, I am closing the bug report.