Large Rotations with NL solvers - observations / questions

jacob

Sound_Spinning
I get your point, just saying that for our simple pendulum example it shouldn't matter if we use rigid or distributed and that sometimes is better to use rigid.
https://youtu.be/MefaK1vpUYY?list=PLtt6-ZgUFmMKdzJIohbfiQyYSCAU42ZAO&t=516

Regarding the large rotations I couldn't find it in the posted abaqus documentation so I asked AI.
I think the LIAISON_DDL is correctly at least.
https://chatgpt.com/share/69309829-14a4-8006-847d-561186b1f9a6

Sound_Spinning

jacob
That's a good 'ol school equation; i.e. a model definition linear constraint, and as your link info told you, it won't work in CA for large rots. And it's a rigid link.
Round in circles, my 1st post question/statement stands: CA cannot do true large rots as a general method. It'll only work on very specific cases, and making stuff rigid. When it (kind of) works, it won't report rots properly.

jacob

Hello,
using DKT for the hinge seems to work for postprocessing rotation and applying torque.

url=https://forum.code-aster.org/public/assets/files/2025-12-15/1765784037-489482-org-2.7z

Sound_Spinning

jacob
Thanks, I'll have a proper look in the new year, 'am off for a bit soon.
Have a good break over Xmas!

Sound_Spinning

jacob
Hi; I just had a look at your (made up) mesh & deck. The NL solver you had doesn't work with V16.7.9.
Which solver are you on?

Changing the solver to GREEN_LAGRANGE, which is what I had in the model I sent you (together with comments on all the other NL solvers I tried...) doesn't even get the pendulum going, it gets stuck at the top.
So, where is the evidence that this model of yours handles large rots?

jacob

16.2

for 16.4 I tried this

COMPORTEMENT=(_F(DEFORMATION='GREEN_LAGRANGE',
GROUP_MA=('ALL_VOLUMES', ),
RELATION='ELAS'),
_F(DEFORMATION='GROT_GDEP',
GROUP_MA=('HINGE', ),
RELATION='ELAS')),

for

COMPORTEMENT=(_F(DEFORMATION='GREEN_LAGRANGE',
GROUP_MA=('ALL_VOLUMES', ),
RELATION='ELAS'),
_F(DEFORMATION='GREEN_LAGRANGE',
GROUP_MA=('HINGE', ),
RELATION='ELAS')),

it does not work, behaves like you said

I think we can conclude code_aster supports large rotations, but not for rbe2/3, and beams

Sound_Spinning

jacob
Thanks for the graph, that's more interesting. I'll have another look at some point.

AsterO'dactyle
That table we were aware of (posted in thread), but see my PS in 1st post: the rigid coupling, even with follower loads, didn't work any better (it was even worse) vs _RBE3. So, this area is rather confusing at the moment.
The question now is: why having some dummy shells, like in Jacob's model, gives some sensible angles, but all else, as described in this thread (see 1st post, etc) gives some random angle history? The maths involved are the same; is it an updating of the angle during load increments?

Also, why Jacob's model runs on older versions than mine, and fails to solve in newer ones?

AsterO'dactyle

Hello,

https://codeaster.gitlab.io/doc/docaster/manuals/man_u/u4/u4.44.01/G_n_ralit_s.html#cas-des-grandes-transformations

jacob

Hello, yes we know, so maybe it would be nice to implement at least rbe2 for large rotations.

AsterO'dactyle

Hello,

It's hard to say, I need to read the entire exchange.
Here are a few points:

RBE3 is a feature that was not developed in-house, but by the open source community. Its implementation is complex and difficult to maintain. However, I don't think it has been touched in a very long time.
POU_D_T_GD models are known for not being very robust.
There have been changes to the time schemes in DYNA_NON_LINE, that's for sure.
We are in the process of modifying LIAISON_SOLIDE (RBE2) for large transformations.

Sound_Spinning

AsterO'dactyle
Thanks for the notes, we'll keep an eye on future updates on couplings (RBE2/3), both are very important as general methods to pull structural assemblies together fast, in all relevant FEA solvers; linear & non-linear models.

The other area on *_NON_LINE solvers is the list of 'names' available. When I 1st started reading about them, I found:
GROT_GDEP, GDEF_LOG, PETIT_REAC, GREEN_LAGRANGE, SIMO_MIEHE
I tested them all as much as I could, but it is not clear to newcomers to CA when/how to use each. Is there a consensus going forwards in the DEVs team for next release (is it V18 this year?) with some defaults or similar to improve the UX part of the solver on these, since both statics & dynamics NL solver can be so powerful for general applications?

Cheers,
Jesus
PS: let me know if it'd help to list/post test models on these so far.

« Previous Page