Hi JMB
I concur with jean pierre aubry, that the sibling indeed is LIAISON_DDL. Similar stuff may be going on in other LIAISON functions, but they do not do the the job in the same way.
The RBE2 contraint is not very complicated, but laborious and error prone to write down - which is one reason why the RBE2 came into existence.
Looking at a simple example using 2points (A & B), that are separated by distance L and at an angle Phi from the X axis, with 3DOFs (X;Y;RZ) the RBE2 constraints looks like this when points A and B use the same cartesian coordinate system:
Ax = Bx + L*cos(Phi) - Brz*L*sin(Phi)
Ay = By + L*sin(Phi) + Brz*L*cos(Phi)
Arz = Brz
where Ax implies point A and dof X and so on.
The Master dof is A. If you want to constrain more slave points than B, you add these to the RHS and simply continue to build on the equation, e.g.
Ax = Bx + Lb*cos(Phiab) - Brz*Lb*sin(Phiab) + Cx + Lc*cos(Phiac) - Crz*Lc*sin(Phiac)
Brz = Crz
To sum up, the convenience in using RBE2s lies in it doing the geometry calculations for you and in it catering also for any coordinate transformation that may be involved between the nodes. I believe RBE2s would make a very useful addition to CA who has other constraints that are very convenient to use. .
{ The nasty thing with RBE2s is that if you connect solid elements (XYZ dofs each) to a single beam node (6dofs), the slaves must be on the solids. You want to use rotation in the RBE2. However, as the solids only carry translational dofs, the rotational dofs become constrained, i.e. the rotation dofs on the solids get blocked (Brz==0 in the example above), which in turn can lock the model. The workaround then is to add thin shell elements on the solid to get all 6dofs. }
The functionality is already in CA, but the convenience and 'robustness' clearly are missing. As jean pierre aubry states, one does hesitate to do the job manually as the risk of doing something wrong is high indeed.
Workarounds:
If nodes are separated a non negligible distance, I would not use an idealized spring element (type F = K*X) as a replacement to RBE2s - as such elements do not carry any information on the L variable. Spring elements with some form of length constraint in them may do the job (similar to CBUSH).
The old fashioned way, i.e in the near antique pre RBE2 time, was to use ordinary beam elements. Beam elements tend to increase the numerical span of the stiffness matrix and may make the model hard to run - which is the other reason why the RBE2 type constraints came to use.
I haven't looked into the matter, but - there are nice LIASON functions where you simply let the beam element end somewhere in the solid element volume and let the connection become constrained by some convenient commands. The gentlemen developing CA know what they are doing, so there is a more than fair chance such constraints are handled in a very nice manner.
What I am driving at is that a 'near RBE2' way of modeling may be a combo of a beam element and a convenient-to-use CA constraint on the slave side. This may have been what BL was driving at? Please report back on your finding if you choose to investigate.
The RBE3 is simpler on the face but the more cumersome to foresee actual outputs. It transfers a weighted force and moment load from the slave nodes onto the master node. The weighting factors are computed from the nodal geometry information. I haven't used it much as I wasn't comfortable with it.
Last but not least, RBE2s is a problem for Nastran/CA conversion as the RBE2s cannot be transferred without major effort into CA. I believe this problem does have industrial relevance due to Nastran being such a common code.
I guess the way to go the whole way on RBEs is for someone to write up a Python script?
Hope this helps
Claes
