[SMApp] - RBE3

[DrexlerTUM]

---

name: RBE3 Process & Test
about: creates a RBE3 coupling between a reference and connected nodes within the StructuralMechanicsApplication

---

📝 Description

RBE3_process.py:
The process generates a coupling, which defines the motion at a "reference" node as the weighted average of the motions at a set of connected nodes.
The coupling is similar to RBE3 elements in Nastran. The motion of the reference node of an RBE3-coupling is defined as a weighted interpolation of the connected nodes.

The motion of the reference node $u_{ref}$ is expressed as
$u_{ref} = C \cdot u_{con}$
with $C = (A^T \cdot W \cdot A)^{-1} \cdot A^T \cdot W$

where $u_{con}$ contains the displacments of the connected nodes, $W$ is the weighing matrix and $A$ is the relation matrix between the reference and the connected nodes.

The coupling is implemented using the Kratos LinearMasterSlaveConstraint class. Hereby the reference node represents the slave node and the connected nodes the master nodes.

Key changes

implementation of RBE3 for FE-applications

Validation

test_RBE3.py:
The test verifies the RBE3 connection between a reference node and multiple connected nodes.
Therefore a simple panel model is created in Kratos, which is fixed on one side. On the other side some nodes of the panel are connected to a master node via the RBE3-coupling. A prescribed force ($F_x, F_y, F_z$) or moment ($M_x, M_y, M_z$) is applied to the reference node, and the resulting displacements and rotations of the connected nodes are compared against reference results obtained from Nastran.
The test verifies similar results with a relative tolerance between Nastran and Kratos within the range 0.07.

🆕 Changelog

/

[AlejandroCornejo]

@RiccardoRossi

[matekelemen]

Please use doxygen annotations. Also, a mathematical expression exaplaining what you're actually imposing would be nice.

[matekelemen]

Both here and in your RBE2 constraint, I'm confused about this part. Do these variables only refer to the connected nodes? Or also the reference node?

In my mind, the reference node always needs the rotational components, but the connected ones only need them when they're part of at least one element that has rotational DoFs.

Not every node might be connected to the same types of elements though. Imagine that one connected node is part of a shell with rotations, while another one is only part of a solid. You'd be inserting rotational DoFs into the solid then that have no stiffness contributions. If you don't want to deal with such scenarios, you need to either check that such a situation never occurs (preferable) or explicitly state in the docs that you don't support it.

How about 2D cases? Then I'd only want the ref node to have DISPLACEMENT_[XY] and ROTATION_Z constrained. However, a user can now set any weird combination of variables, which you wouldn't be able to deal with.

The bottom line is that you should either shrink your contract (e.g.: you only support 3D problems with connected nodes that are only contained in a single type of element) and explicitly document what you support/don't support, or think of a more robust interface+implementation.

[DrexlerTUM]

Thanks for your comments!

I’ve updated the "constrained_dofs" part of the RBE3 process. The user can now specify the "constrained_dofs_ref" of the reference node. These DOFs are interpolated from the specified DOFs of the connected nodes.

For the connected nodes, I introduced subgroups with individual weighting factors. This makes it possible to distinguish between different groups of connected nodes and control how and with which DOFs each group contributes to the motion of the reference node.

I’ve also implemented a RuntimeError for cases where rotational DOFs are specified by the user but the corresponding node does not have these rotational DOFs (for example for solid elements).

For 2D problems, I don’t think an additional RuntimeError is necessary, since the user explicitly defines which DOFs should be constrained.

[matekelemen]

I’ve also implemented a RuntimeError for cases where rotational DOFs are specified by the user but the corresponding node does not have these rotational DOFs (for example for solid elements).

Conceptually the right direction, but unfortunately Kratos does not work that way.

Lists of DoFs are shared between nodes belonging to the same model part tree. So if you have a single shell element with rotations and a million solid elements without them, all nodes have to carry rotations.

The only way to collect all DoFs a node actually contributes to the system, is to loop over all elements that contain it and query their DoFs.

I imagine you wouldn't want to do this, which is why I suggested narrowing the scope of this process (e.g.: rename the class to ShellRBE3 or something).

[DrexlerTUM]

Thank you for the feedback. I removed the RuntimeError and replaced it with a user message. If rotational DOFs are selected, the user is now informed that the constrained DOFs for the RBE3 coupling must be specified explicitly.

In my opinion, it is the user's responsibility to define the model correctly. This includes assigning different DOFs and submodel parts for solid and shell nodes when required. The same principle applies in Nastran, where the user must ensure that the RBE3 definition matches the connected element types.

This approach allows the same RBE3 implementation to be used for both shell and solid models while keeping the setup flexible. However, the user is responsible for defining the coupling appropriately.