I meant mesh from Case02a not Case02. Jean Pierre's comm file plus mesh from 088-case02-QUAD4.zip (Case02) works without modification. It seems that removing TOUT='OUI', adding 2D mesh groups and LOADD_EL to DKT formulation does the job. I have never added 1D element group to DKT formulation. But I understand that this will create SEG2 elements on LOADD_EL edge. A neat way to create less elements in the study.

From *.mess file you referred to you can find in "Modelisation" column "-", which means that that despite MEBODKT being applied to "hollow 1D mesh" no stiffness is added to SEG2.
I've always used TOUT="OUI" in "Modelisation" and took advantage of overwriting rule. I have never thought that it might make any difference. So I leaned something new also.

I see what you mean. It's weird, but I did not specify any modelisation to SEG2, so those elements should be "transparent" for the solver. Correct me please if I'm wrong.

The other weird thing is that my last mesh doesn't contain any additional SEG2 elements in those holes and I'm still getting rigid body motion. Well I should have sticked to one mesh and make adjustments where needed.

What is even weirder:
Degré de liberté physique associé au noeud N2212 et à la composante DZ.
This node is in the middle of RHS beam.

I'm sorry, I didn't fully understand the first time.

Yes, you're right, I picked only 3/4 of hole edge to that HE4 group.

It seems that there's a rigid body motion, but I don't know why. Every connection seems all right.
I attach the most recent files. I changed mesh, changed M_RT_D_N to K_TR_D_N with all 6 stiffness components equal 1. I'll get back to it in the evening.

Line 345 in mess file "à la ligne 1640 qui correspond au degré de liberté" - ligne 1640 reffers to SEG2 element number 1640?

...so for LOADD_EL as well, I'll check that. I thought that DKT applies to 2D elements only, not their "border". LOADD_EL is group containing line elements.

Geometrical Group_14 was used to control submesh, it landed in the mesh group automatically, and I didn't notice that it's there. I'll delete it from final mesh.

As for the M_TR_D_N, this is taken from an example I was given during training. Since I'm not using PESANTEUR this, as stiffness, would not be taken into account. I don't know how else I could create LIASON_SOLIDE. I tried using nodal group without POI1 element, but solver reported orphan mesh. Then it was explained to me,  that I need any sort of element in that central node (which was kind of obvious, when it was pointed out). I don't know how to simplify it.

I changed the mesh to QUAD4 and made it almost exactly the same as the "original" from training (except for 4 triangles). I named the groups as in case of TRIA3 study and run the simulation. Now I'm getting error, that some edge elements were created but they are not attached to any with the stiffness. This information is new for me and I don't know how to deal with it. Please look at line 174 in mess file. The element, and next few to which the error refers to are at the far end of the RHS beam. I attach the mesh, comm, export and mess file. Could you explain what I did wrong?

I'm aware of that. M_TR_D_N is used to apply DDL_IMPO only. Johannes told me during training that I'll get this error in mess file and in this case I may omit that. I don't see any other things in my comm file that could lead to different results. I don't understand why Nastran's and C_A's results differ so much. I'm curious why there's a discontinuity in stress propagation between beam and c channel? Especially if they share the same node where the singularity may occur. I can only guess.

displacement

von Mises stress from Femap/Nastran

I'll post the view from Femap as soon as I get permission. I asked for it and I'm still waiting. I paid for a general FEM training some time ago. Now I'm back to C_A (this time for real) and I wanted to replicate the study.

I'll change back to TRIA3 or QUAD4 (if I manage to mesh it correctly) and I'll paste results.

Johannes mentioned the difference between SIEQ_ELNO and SIEQ_NOEU several times and I additionally read documentation regarding this matter. I understand the difference how the fields are obtained but still I don't understand why are those two fields present instead of just one. The values represent the same place in space, but since the values are obtained differently they must differ. So which one is "true"? For instance If you're using less advanced software and you choose von Mises stress you are presented with only one field. Why NOEU in this case is meaningless for you? Is it related to singularity in this region?

I changed the model back to what was before.

well... for part of this conversation I tried to solve already solved problem. By mistake I discovered that I don't have to run singularity inside wsl "VM". Well, this has already been prepared and if you are using what Hassan Berro prepared, after running

wsl -d smeca

you simply run

as_run exampleexportfile.export

and that's it. It works flawlessly...

So to sum up -
all I have written before applies to singularity installed directly on Linux machine. There's no need to change anything in shared "VM".

attached study