I have applied Radial Displacements to parts of a model. The boundary constraint symbols point in the correct directions, but when the analysis is run, the displacements are applied relative to the global coordinate system.
The top figure shows the expected result. The bottom figure shows the actual result.
The results are as expected if the displacements are applied directly to the cylinder top surfaces (top figure). But, if the cylinder top surfaces are rigidly attached to reference points, and the displacements are applied to the reference points, the result is as shown in the bottom figure.
Reason for creating rigid surfaces: When a displacement is applied directly to a cylinder top surface, all nodes on the surface move directly toward the coordinate system z-axis causing compression of the surface in the tangential direction. This results in stresses on the surface eight times higher than occur if the surface shape is rigidly retained.
If you check the CalculiX keywords generated by PrePoMax for this model, you will notice that the *TRANSFORM keyword doesn’t include rigid body reference nodes (and this keyword is not added at all when you remove the fixed BC at the bottom using the same local CSYS). Even if you create a node set with those reference nodes and define custom *TRANSFORM keyword referring to it in the Keyword Editor, the analysis will fails.
This means that most likely it’s CalculiX’s undocumented limitation (local coordinates systems can’t be used with rigid body reference nodes). Btw. Abaqus doesn’t have it:
If a nodal transformation is defined at the rigid body reference node, boundary conditions are applied in the local system.
FEAnalyst, thank you for the quick reply. Your knowledge about Calculix is very helpful. Now that I know the limitation, I can use some trigonometry for a fairly straight forward workaround.
After some testing, I can confirm the problem. The coordinate system at reference points works for loads - concentrated force, - but it does not work for boundary conditions.
I see three possible solutions:
Disable this option for BCs
Show a warning when such an option is used
Internally recompute the BCs to the selected coordinate system. This would work, but could give the user a feeling that the RP’s node is in local coordinates when analyzing the results (this is probably negligible).
In my opinion, option 3 would be the most user friendly, but any of the options would be fine. As long as the limitation is obvious to the user, the ability to use trigonometric functions directly in input field equations makes the workaround reasonable.
