It seams there are some limits on my account. Don't know why. Since a while I experience such problems. It seams short replies go through, but not a longer one with code-spinets and attached files.

This is no fun... If I am banned, at least would like to know why. As it is, it feels like there is some kind of censorship...

]]>I've got the same result by applying twist in a more reasonable way. The procedure is based on test case zzzz364a, where a rotation is applied via rotation matrix (see for example en.wikipedia.org/wiki/Rotation_matrix -- the formula in use is related with the one found under the topic "Rotation matrix from axis and angle" and is the same as the one found in the previously attached file: Dhondt2004__pp155-159.pdf).

]]>in the attached document disk;comm the formulaes for tournex and tourney seems valid with:

1- DTH= 2*PI radians is the total amount of rotation at the end of the problem (over 2Pi would lead to a nasty behavior)

2- the applied load is an imposed rotation angle, not a force or moment

3- are related to a certain spatial position of the object

try to calculate the result of the formulaes for a given node from INST=0 to INST=1 to find out in your case

]]>x = r cos(theta)

y = r sin(theta)

with:

r = sqrt(X^2+Y^2)

the radius of the node on a XY plane and

theta = atan2(Y,X) + DHT*INST

the angular increase on the increment.

That was my interpretation.

Maybe AsterO'dactyle can clarify better as he proposed such formula on the post as a

"rotational" boundary condition

without further explanation.

]]>tournex produces a non null value for FX at X=0

i suppose DTH is the nodal tangential load

do not le the tree hide you the forest

]]>These formulas were copied from other forum posts and can be found on some official example test (ssnv507) always with TYPE_CHARGE='FIXE_CSTE'.

However, noticed that the formula for large rotations might be other than the assumed:

vec_r = vec_r0 + theta*(vec_n x vec_r0 )

see attached pdf taken from:

Dhondt, G. "The Finite Element Method for Three-dimensional Thermomechanical Applications", John Wiley & Sons Ltd, 2004

]]>My calculation does also not reach the end. The last computed time step is about 0.7482. I include a plot for the computed torsional stiffness (load path). In this simulation the instability is occurring for an angle of about 2.86 rad (163 deg) at a twist moment of about 92 kN.m. I guess the strange results you are refering to relate with the disagreement with expected analytical calculation. The curious thing is that the load path computed with CalculiX agrees pretty well (check the load_path_calculix.png also inside the calculix.zip on a previous post of this topic). The other curious thing is, by following your suggestion, and by using coarser mesh (6269 tetrahedral elements) the instability is reached at an even larger twist angle of about 7 rad and moment of 200kN.m with both simulations having a comparable torsional stiffness. That said I think valid results, are much dependent on the mesh and our current mesh is already quite coarse.

PS: The shared files include in addition to the plot for the load path, (i.e torsional_stiffness.png), a plot of the trajectory of a node on the cLoad group (selected randomly), a table with the computed total forces/moments and twist angle (same data as the used in the torsional_stiffness plot) and a python script. The python script might be useful for others to read and merge code_aster tables as such should be done to compute the moments when considering large displacement hypothesis. Note that for this case tables DEPL and REAC_NODE need to be read and merged (i.e. synchronized) on the nodes to give access to compute the actualised position of the node to be used in the computation of the reaction moment on each node (i.e: vec_M(t) = _vec_r(t) x vec_F(t)). The toal reaction moment/forces is obtained by summing up the forces/moments on all nodes of the selected nodeset (in this case the loaded nodes on cLoad)

]]>i had to interrupt the calculation before the end because of non convergence around INST=7

however the results which i cannot understand seem very strange to me

do you get valid results with these files]]>

I can not really argue about begin consistent by using such options. But sometimes unknown inconsistencies lead to great discoveries (probably not this time!).

I think the use of these options should not affect much the result.

AFFE_CHAR_CINE instead of AFFE_CHAR_MECA because remember to read somewhere that such type of condition should be computationally more efficient if using homogeneous boundary conditions.

U4.44.03:

Cette commande peut être utilisée avec un modèle mécanique, thermique ou acoustique. Le traitement de ces conditions "cinématiques" se fera sans dualisation et donc sans ajout de degrés de liberté de Lagrange.

The non use of FONC_MULT with CHARGE=load, can not justify other than saying that followed an example (see Rotation.zip) in the following post.

The reason for a relative fine mesh is because, I think the buckling condition will not be captured if using a coarser mesh. This is because the simulation will stop with some convergence problem (large distortion of elements) before reaching buckling. Also a large tube is required for buckling to occur which implies a considerable number of elements. I must say, I also tried an adjusted version of the 2d example you provided without success. (But maybe here the problem is the structured mesh?)

However, I understand your point and will try to provide a coarser mesh where we reach the buckling phenomena.

]]>i am really interested in your problem

but for god's shake consider providing a less refined mesh, many (10 ?) times coarser to speed up the conclusion

for trials we do not care that much about things like the stress refinement near the boundary condition

once we have a conclusion we can revert to a more realistic mesh

and spending well over half a hour on each trial calculation on my modest komputer is for me a waste of time!

two practical questions while i am waiting my first run to finish

why is there no FONC_MULT with CHARGE=load,

why using AFFE_CHAR_CINE

jean pierre aubry

]]>I must say I am quite disappointed and frustrated for not having any additional reply on this topic. I was hopping to get some justification/hint from someone with the knowledge (including the development team) to why things are not working as expected when using the large deformations formulation, specifically why LIAISON_SOLIDE is not working for rotations or why POST_RELEVE_T operator is not able to compute the reaction moments correctly.

Anyway, by playing with options, I've managed to perform a simulation in code-aster where the such said buckling condition is achieved (see attached Figure). The files for the simulation are also attached (bellow). There is only a small change in the geometry (in relation to tryC) which is meant to simplify the analysis. A new physical group (cLoad) is created to apply the torsion load along the outer line of the driven top surface of the cylinder. (This way the number of loaded nodes decreases substantially). The other more important change (in the command file) was to change the TYPE_CHARGE from 'FIXE_CSTE' to 'DIDI'. i.e:

```
result=STAT_NON_LINE( ...
EXCIT=( _F(CHARGE=fix,),
_F(CHARGE=load, TYPE_CHARGE='DIDI'),
),
...
);
```

I don't really understand what such type of loading is doing. U4.51.03-Opérateur STAT_NON_LINE (pp.15) states:

Si TYPE_CHARGE vaut 'DIDI' alors les conditions de Dirichlet (déplacements imposés,

conditions linéaires) s'appliqueront sur l'incrément de déplacement à partir de l'instant donné

sous ETAT_INIT/NUME_DIDI (par défaut l'instant de reprise du calcul) et non sur le

déplacement total. Par exemple pour un déplacement imposé (mot clé DDL_IMPO de

l'opérateur AFFE_CHAR_MECA) la condition sera de la forme u−u 0 =d où u 0 est le

déplacement défini par NUME_DIDI et non u=d .

The automatic translation into English did not really help!!!.

I would expect that the right option to apply is TYPE_CHARGE='SUIV', as such option (as I understood)

applies the loading on the actualized geometry: But doing so, I get the following error:

╔═══════════════════════════════════════════════════════════════

║ <EXCEPTION> <DVP_1>

║

║ Program error.

║

║ Condition not met:

║ .false.

║ File

║ /home/salome/workspace/SALOME-MECA_V2021_PLATFORM/3/salome/V2021/tools/src/Code_aster_stable-1

║ 540/bibfor/load_util/ischar_iden.F90, line 99

║

║

║ Il y a probablement une erreur dans la programmation.

║ Veuillez contacter votre assistance technique.

╚════════════════════════════════════════════════════════════

Any hint on what DIDI is really doing or why SUIV is not working is very welcome and appreciated.

]]>