Rigid-body constraint convergance problems

1

I was solving a larger shell model using a rigid-body constraint and could not solve the problem successfully when I used the NLGEOM setting. I was able to determine that the rigid-body constraint was causing convergence problems. I was able to reduce the larger model to a model of only three shell quadrilateral elements for the comparison with the solid approach. It turns out that the equivalent solid model does not have any convergence problems. So, it might be that my approach to shell modelling is somehow wrong or that the rigid constraint works differently for shell and solid models. It makes the use of rigid body constraint almost unusable for the shell models and NLGEOM.

The solid model (Solid.inp) is a plate of dimensions x: 30; y: 10; z: 1; meshed with three C3D20 elements. The material has elastic properties of E = 200000 and a Poisson’s ratio of 0. The node-set (a) is fixed (d), the node-set (b) has a prescribed displacement of 0.01 in the displayed direction (e), and the node-set © is used in the rigid body constraint (f). The constraint uses the reference nodes “Ref node” and “Rot node” positioned on the centre of the rightmost face of the model (x, y, z: 5, 30, 0.5). This solid model can be solved using NLGEOM in 3 iterations. Moving the reference nodes around does not affect the solution.

The shell model (g) (Shell.inp) is a plate of dimensions x: 30; y: 10; z: 0; meshed with three S8 elements. Everything else is the same. The reference nodes are positioned at x, y, z: 5, 30, 0. With the default settings for the NLGEOM incrementation, the problem cannot be solved. If the reference nodes are moved around, this affects the convergence of the solution (it should not!). At the reference nodes positioned at x, y, z: 5, 24.5, 0 the solution converges with the default incrementation but uses much larger number of increments.

So what is wrong with the rigid-body constraint? Any suggestions, ideas?

Solid and Shell
Solid and Shell873Ă—605 86.7 KB

The .inp files:

Solid model: https://www.dropbox.com/s/e4j46ygxeatu94i/Solid.inp?dl=0
Shell model: https://www.dropbox.com/s/hzciamw00xagoof/Shell.inp?dl=0

2

I’ve also found that *RIGID BODY and *COUPLING don’t work consistently with shell and beam elements. I think it’s something to do with the MPCs conflicting. Generally, any features that use MPCs don’t work reliably with shells.

3

Thanks for the answer. I can imagine it can be a problem combining all the different MPCs and that is why I tried to make the example as simple as possible. If my understanding of the code is correct, the shell finite elements are expanded in bricks. So in this case, where all elements lie in a plane, the resulting mesh should contain no knots (angle smaller than 0.5°, the same thickness, and the same offset) and should be the same as the solid mesh. So I thought the rigid body constraint should work.

4

Yea that confused me too but I seem to remember Guido saying that shells always have knots now, not only if they’re at steep angles. Not to sure about that though.

5

I did not try the *Coupling yet but that is really unfortunate. I found this problem for the Nlgeom option only. Does it cause problems even for linear cases? How do you solve such problems in CalculiX then?

6

*** deleted my previous comment, due to inconsistency

  • displacement bc only, not work
  • add cload at reff. nodes combine with displacement bc, work with some limitation values
  • cload only, not work
7

hi @Matej

alternatively, you could solve these problem using coupling keywords. solved fast by 3 iteration only, as can be seen in attachment picture below.

best,

2020-12-30 00_30_29-ShellDC
2020-12-30 00_30_29-ShellDC1280Ă—981 60.2 KB

8

Hi,

thanks for the answer. I thought of testing it so thank you for doing it. I am afraid that this is not a universal solution since Victor wrote that there are also problems with the *Distributing keyword.

I will have to try it out to see how it works. Did you have any experience with *Distributing cousin problems?

9

hi,

did not know @vicmw is talking about, are for *coupling keywords only or it’s all coupling features also? i did not see any simple example problems has posted.

in my previous analysis cases ran, some versions of CCX (2.13) doesn’t work properly if the boundary conditions are rotational (e.g concentered moment/torque) with *coupling keywords type distributing.

in case translation bc’s and using solid element, all coupling features gave expected results and works properly. also i was tried for face of edge shell element. for CCX version 2.12 is works normally also for rotational bc’s, need to be review for the latest versions.

to be generalize i look the possibilities using coupling features with *distributing keywords, since it has weight factors. i need to try and take many cases to validates further.

benefit of using coupling features rather than rigid body are avoidance of over constrained conditions and additional infinity stiffness. it’s exist on the face or node groups of element being considered.

best,

10

Ok, thanks for the answers. I am still bothered by the *RIGID BODY, NLGEOM and shell combination. Maybe I will look into it in more detail.

11

i found it works when rotational node is removed, document says let the solver generated internally. but results are bit different from previous, and took more iterations. need a solved known problems to verify.

2021-01-04 07_01_02-CalculiX GraphiX
2021-01-04 07_01_02-CalculiX GraphiX786Ă—706 9.07 KB

12

Yes, that is something that I was also able to determine. In the case, where the reference node is not defined by the user, it is automatically determined by the CalculiX since it should not affect the result. But unfortunately it affects the result. And that is a problem that cannot be disregarded.

13

I have made some investigations on how to apply large rotations to models

I guess that the problems are not only related to conflicting constraints but also to inconsistent linearization of some of the coupling mechanisms, which might explain the increasing problems with increasing rotations.

Martin Kraska

1 Like
14

That’s an interesting example. I am intrigued by the analytical solution in this case. I didn’t realize that standard formulas known from mechanics of materials can give correct results also for latge deformations. I thought that with NLGEOM on and such large rotations, the analytical calculations wouldn’t be so easy (if possible at all). But shouldn’t the strains be converted to Green-Lagrange strains used in CalculiX if we want to compare them ?

1 Like
15

The point is that actually the strains are small, as long as the thickness is small compared to the radius of curvature. As long as you compare invariants (equivalent stress or principal values) and not individual components, any rotational effects are not relevant for comparison. That is why I plotted the von Mises stress. You would get weird plots for SX and the like.

2 Likes
16

Regarding the issues shown with *RIGID BODY working with beams or shells I have found something that could explain the issue.

I have identified and split two sources of error which once corrected makes rigid body with shells and beams work properly (at least in Static 3D):

1-Boundary conditions imposed to the REF NODE need to be split for each direction. A displacement like (500,500,0) doesn’t work. It has to be imposed like two displacements of (500,0,0) and (0,500,0)

“Any constraint on the reference node must be aligned AND BE IMPOSED SEPARATELY for each global axis”

Once this is fixed:

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 of what is happening ( sorry for the neuby language) :

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.

I would impose to the user the CREATION of the ROT NOTE for Shells and beams and expose the need to split any BC on the REF NODE as one on each direction.

EDITED: Nonlinear probably doesn’t work due to the issue number 1. At the end of the first step the geometry is updated in one step with arbitrary direction of displacements producing issue number 1. The problem could be solved fixing issue n1 or updating the geometry in 3 steps, (Ax,0,0) + (0,Ay,0) +(0,0,Az)

17

All those comments are valid for the NSET option. ELSET produces solutions dependent on the REF NODE position with respect to the centroid of the Rigid Surface.

18

hi disla,

i wanted to chime in on the topic of shell expansion. i too have had issues with this breaking things. i wish that the expansion happened ahead of the solve. so that the pre-processor knew all the nodes, elements, locations, etc… one thing this would provide is the ability to apply loads at the correct locations in the model. another is the ability to calculate the mesh quality prior to solve. output=2d command would also work for laminates. i’m sure there would be other benefits too.

the shell expansion with laminates, in it’s present state, is painful. due to the fact of so many unknown nodes, elements, etc… this is something that really needs to be improved, in my opinion. otherwise, a true shell element would suffice. the mystery expansion at solve is just not a good way to do things.

oops, i should add that the original node locations still need to be maintained. i currently apply loads to those and it works. so i wouldn’t want to break that aspect of how it currently works. just add in the new nodes, elements, etc… should help fix a lot of issues.

anthony

1 Like
19

So if I understand correctly, there is a difference in using NSET or ELSET? As I remember the Calculix documentation, the ELSET is internally converted to NSET so the result should be the same.

20

Static 3D works nice with NSET if some precautions are taken.
Same model with ELSET fails to me.
Nonlinear doesn’t work with any of the options.That’s normal. If static fails, NLGEOM will fail.
I think the source of error of the overall RIGID BODY with shells and beams could be that some displacements are silently applied to the ROT NODE. It is not intuitive, but it should be understood that any displacement on the ROT NODE generates a ROTATION in the Rigid Body . (ccx manual pag.521 v2.18).
By other hand , any rotation induced by the ROT NODE on the Rigid Body is done around the REF NODE as Centre. That’s why different positions of the REF NODE give different results. For me that’s a clear sign that the ROT NODE is acting on the BODY.