Stuck? 
support@mecway.com
support@mecway.com
Mecway
FEA
*RIGID BODY issues with Beams and Shells
Hi,
Regarding the issues shown with *RIGID BODY working with beams or shells I have found something that could be a solution.
I have identified and split two sources of error which once corrected makes rigid body with shells and beams work properly (as far as I tested):
1-Boundary conditions imposed to the REF NODE need to be splited as one for each direction. A displacement like (500,500,0) doesn’t work. It has to be imposed like (500,0,0) and (0,500,0)
“Any constraint on the reference node must be aligned AND MUST BE IMPOSED SEPARATELY for each global axis”
Once this is clear and fixed we can proceed to fix the second source.
2-*RIGID BODY works perfect with solids but not with shells and beams. One big difference between shells and solids in ccx is that shells and beams are expanded so new nodes are created.
When the *RIGID BODY card is set in the custom model definition and the ROT NODE is defined by the user (Node number reserved as it is a physical node in the model) , *RIGID BODY works and perform as expected with shells and beams . When the ROT NODE is not set by the user the *RIGID BODY works but the results have no sense.
This is my hypothesis and how to fix it.
When the ROT node is not set by the user, Ccx automatically assigns a number to the ROT NODE (=number of nodes + 1) BEFORE expanding the shell or beam to solid so the ROT NODE ends up in a node that belongs to the body once expanded. If additionally, some displacements are imposed to the rigid body, displacements are transmitted into the ROT NODE which, as we know, is related with the Rigid Body rotation. That’s why if the ROT NODE is not set by the user, the result is distorted, rotated or even incompatible with the rest of the BC producing no result.
Victor: I would impose to the user the CREATION of the ROT NOTE for Shells and beams and split any BC on the REF NODE as one on each direction in the pre-processor.
Regarding the issues shown with *RIGID BODY working with beams or shells I have found something that could be a solution.
I have identified and split two sources of error which once corrected makes rigid body with shells and beams work properly (as far as I tested):
1-Boundary conditions imposed to the REF NODE need to be splited as one for each direction. A displacement like (500,500,0) doesn’t work. It has to be imposed like (500,0,0) and (0,500,0)
“Any constraint on the reference node must be aligned AND MUST BE IMPOSED SEPARATELY for each global axis”
Once this is clear and fixed we can proceed to fix the second source.
2-*RIGID BODY works perfect with solids but not with shells and beams. One big difference between shells and solids in ccx is that shells and beams are expanded so new nodes are created.
When the *RIGID BODY card is set in the custom model definition and the ROT NODE is defined by the user (Node number reserved as it is a physical node in the model) , *RIGID BODY works and perform as expected with shells and beams . When the ROT NODE is not set by the user the *RIGID BODY works but the results have no sense.
This is my hypothesis and how to fix it.
When the ROT node is not set by the user, Ccx automatically assigns a number to the ROT NODE (=number of nodes + 1) BEFORE expanding the shell or beam to solid so the ROT NODE ends up in a node that belongs to the body once expanded. If additionally, some displacements are imposed to the rigid body, displacements are transmitted into the ROT NODE which, as we know, is related with the Rigid Body rotation. That’s why if the ROT NODE is not set by the user, the result is distorted, rotated or even incompatible with the rest of the BC producing no result.
Victor: I would impose to the user the CREATION of the ROT NOTE for Shells and beams and split any BC on the REF NODE as one on each direction in the pre-processor.
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
As MECWAY noticed and warn, displacement BC on shells and beams sometimes causses incorrect stresses in ccx. This issue is the same, it is related and can be fixed the same way. If BC's are imposed at once, the displacement/stresses will be wrong. It needs to be introduced in tree, one for each direction. I post it in Calculix forum as it affects Nonlinear too. The model geometry cannot be updated correctly so it fails. Hope it is this and can be fixed.
A displacement like (500,500,0) doesn't mean the same thing as (500,0,0) and (0,500,0). The latter constrains two directions (X and Y) while the former is a single direction at 45 degrees between the X and Y axes. This problem with rotated constraints is what the note in node-surface coupling of "Any displacement constraints on the references node should be aligned with the global axes." refers to.
Mecway generates the ROT NODE for node-surface coupling, and it wouldn't conflict with expanded nodes because it exists in the CCX .inp file's mesh so I guess that should work OK if you don't write the cards by hand.
I don't want to expose the ROT NODE in the GUI because it breaks the meaning of DOFs, even though it would enable some useful capabilities like your torsion spring. Instead, Mecway quietly moves rotational loads and constraints on the exposed reference node to the hidden ROT NODE behind your back.
The non-zero displacement bug occurs with single axis-aligned constraints too, so this may help sometimes but doesn't completely eliminate it.
¿Is that right?. That is exactly what I’m exposing. I thought that was happening because the ROT NODE end up in the body during the expansion process and constrains were then applied to the ROT by accident but seems it is not an accident. ¿Why are you quietly moving constrains from one node to the other? Any displacement moved to the ROT node will induce a rotation on the rigid body.
I'm starting to see this was a really confusing design choice on my part. You're not the first to be blindsided by it. The general idea is that the features in the main GUI (ie. not in the CCX branch) are supposed to make sense without knowing anything about CCX. So if you don't know that ROT NODE is a thing, you can still use rotations and moments and they get applied correctly, as well as displacements and forces. But if you expect Reference node to be the same as REF NODE then it would be full of surprising behavior.
HI Victor,
Ok. Let's consider I forget about ROT NODE for a while. We don't talk about it, and I never meet him. I don't know about the custom model definition option. If I introduce three displacements into the Mecway Reference node of a Node-Surface coupling I have the same problem. The shell surface is rotated and deformed and Nonlinear doesn't work.
Seems the ROT NODE is receiving values from somewhere to its DOF 1-3 that are inducing rotations into the rigid body. The ref node can’t do that by itself.
Check this .liml file and what I have found.
If you constrain all three rotations of the Reference Node along its displacement, the problem is solved in Static 3D and Nonlinear at least runs up to 1.
I now think that while displacing the reference node some undesired or unnoticed rotations appear on it which are silently transmitted to the ROT node.
Bear in mind that *RIGID BODY isn't known to work reliably on shells. It sometimes does but also sometimes doesn't.
EDIT: Perhaps I misunderstood you. Without the rotation constraints, I do get rotations but that looks like rigid body rotation that commonly and correctly happens with an under-constrained model.
I would understand some rotation maybe but not distortion.
¿Is there any way to check if the ROT Node coordinates have change since it was originally created by Mecway?
Maybe the solution would be to check if the user has imposed any rotation or Moment to the reference node and if not, constrain those values to avoid any disturbance from the ROT NODE (rotations and moments).
I'm running v2.19 which is supposed that do not work with Rigid body shells or beams and I can do it even Nonlinear just constraining rotations.
i also ran the previous model you posted and got what you applied as well 500mm about x, y, and z.
the first model you posted where you said it was working, i actually don't understand what is supposed to be going on there. so i don't have any thoughts on it. the last two models seem pretty clear and appear to work to me.
You can add an element to the ROT NODE in CCX -> custom model definition so that it survives into the solution. I've done it here by connecting a 0 stiffness spring to an arbitrary other node. I also put one on the REF NODE.
It would be wrong if Mecway put rotation constraints on it because you might want it to rotate freely about that point.
@prop_design you can see in the picture I'm getting 4951mm of displacement.ccx V2.19 on Windows 10.
@prop_design. You can download by clicking the rectangle bar that shows the filename instead of the sheet-of-paper icon. I know it's weird but somehow that's how the forum ended up working.
The file ROT NODE VISIBLE shows clear that the Rot Node is moving when the user only wants a displacement of a Rigid Free Body. That's from my point of view something weird. ROT NODE can not move if the user do not request it or the surrounding bodies force the rigid body to rotate.
I'm trying to understand why Rigid Body is not working as expected for me with shells and beams. Some behaviours seem random but now I understand what is going on much better and I will be able to sort some of the issues I was experiencing and avoid them in the future. I can make nonlinear work now with Rigid Shells with very few changes and knowing the price to pay for it. Anyway, let's see what Victor says as there are some points still not clear.
It also happens when I extrude the mesh to solids. I'd rather focus on the solids first because shells aren't technically supposed to work reliably but solids are. Now I'm trying the attached model that has solids, no rotation constraints, and explicitly ramped displacements. I'll get back to you when I find more.
Overall, I think everything's working correctly here and both versions of CCX seem to be equivalent, at least for *RIGID BODY. I haven't looked at *DISTRIBUTING in CCX 2.19 yet.