Welcome to the forums. Please post in English or French.

You are not logged in.

#1 Re: Code_Aster development » Singularity is Apptainer? » 2022-09-23 09:40:25

have anyone tried this?

https://github.com/apptainer/apptainer/blob/main/dist/debian/DEBIAN_PACKAGE.md

#2 Re: Code_Aster installation » Tfel and Mumps compilation issues - code_aster 14.6 » 2022-09-23 09:36:38

Hello,

Earlier this year I've posted the problem...

compilation errors of code-aster on debian bullseye

no one offered solution. The developing team seams to be putting the effort into the 5-8GB singularity containers which they declare to be the panacea to solve all installation problems.

The gfortran v10 compilation errors seam to get sorted when the following flag is included:

-fallow-argument-mismatch

I've managed to get mumps to compile by adding such file, but on a separate compilation without the waf system, which I do not understand. By editing the Makefile.inc and adding the mentioned flag to OPTF, ie:

#Begin Optimized options
OPTF    = -O -O2 -fPIC -O -DPORD_INTSIZE64 -fopenmp -fallow-argument-mismatc

tfel did not manage to sort out.

Meanwhile, I got used to the singularity containers and indeed is possible to launch code aster without evoking salome, see my post on topic:
viewtopic.php?pid=67668#p67668

I think there might be an alternative way to install the singularity/apptainer container on debian11. apptainer  seams to be the follower from singularity. Currently is still not on the repositories, but the website shows how to proceed to get it packaged for debian.
Singularity is Apptainer?

#3 Re: Code_Aster usage » Creating .comm file with Python » 2022-09-21 13:01:03

Hello,

On a different context, It is possible to associate element wise local directions, giving those directions on each element through the following construction:

cara = AFFE_CARA_ELEM(DISCRET=_F(CARA='K_TR_D_N',
                                 GROUP_MA=('RotP', ),
                                 VALE=(0.1, 0.1, 0.1, 0.1, 0.1, 0.1)),
                      MASSIF=[ _F(MAILLE='M%d'%el, ANGL_REP=(psi,theta,phi) ) for el,psi,theta,phi in orient ],
                      MODELE=model,
                      INFO=1)

in your case you would need to do something like

beams = ...
AFFE_CARA_ELEM(
[...]
POUTRE=[ _F(CARA=('HY', 'HZ'), GROUP_MA=b, SECTION='RECTANGLE', VALE=(10.0, 50.0)) for b in beams],
[...]
);

I recommend you to try first separately a similar construction on a common python interpreter, in order to debug it properly, for example something like:

do_something = lambda x: print(x)
beams = range(100)
[ do_something(b) for b in beams] 

#5 Code_Aster development » Singularity is Apptainer? » 2022-08-29 08:19:16

jlucas
Replies: 1

Hello,

I guess most of you already know about this.

http://apptainer.org/news/community-announcement-20211130

#6 Re: Salome-Meca installation » Container creation failed (Salome Meca) » 2022-08-24 08:51:12

Hello,

Maybe try running without installing.

Example:

$ singularity run -B /media/secondSSD,/tmp:/local00/tmp /usr/local/salome/salome_meca-lgpl-2021.0.0-2-20211014-scibian-9.sif

Notes:
This is the command I am running on my computer, so you need to do the appropriate translation to yours. In My computer I have the container in the following folder: /usr/local/salome/. So any user in the computer can access it without any problem.

-B option allows access to local folders. In my case to a mounted partition on /media/secondSSD and a temporary local folder.


To be honest I do not use salome as it is. I prefer to use only code-aster and paraview separately. I do that with the following commands:

$ singularity run -B /media/secondSSD,/tmp:/local00/tmp /usr/local/salome/salome_meca-lgpl-2021.0.0-2-20211014-scibian-9.sif shell -- as_run --run study.export

$ singularity run -B /media/secondSSD,/tmp:/local00/tmp /usr/local/salome/salome_meca-lgpl-2021.0.0-2-20211014-scibian-9.sif shell paraview&

Note that in case you don't have GPU you need to export the following variables before running paraview:

$ export VTK_DISABLE_VISRTX=1
$ export VTK_DISABLE_OSPRAY=1

Hope it helps.

#7 Re: Code_Aster usage » Print Base after killing job » 2022-08-20 11:01:39

Hi,

Maybe, try to enclose your analysis within a python try block.

DEBUT(...)

[...]

try:

    result = STAT_NON_LINE(...);

except Exception as e:
    print ('================')
    print (e)
    print ('================')
[...]
FIN()

#8 Re: Code_Aster usage » = Buckling of a tube under twist (non-linear) calculix vs code-aster = » 2022-08-19 10:08:55

Thank you Jean Pierre Aubry for looking more deeply into this and for simplifying the problem. It might help to grasp it easily.

I totally agree that the silence on this topic from development team is quite uncomfortable. (I guess most members might be on Holiday?)

I post here some selected links with related topics:

Challenge: Buckling of a tube under twisting moment...
(can not offer any other prize than personal gratification and honor mention in present post!)

Steel tube under twist moment. Large deformations. (code-aster v15.4)

Buckling of a cylinder under a twist moment.

Also might help:
LIAISON_SOLIDE with TYPE_CHARGE='SUIV' and GROT_GDEP

Rotation of a cylinder

DEFORMATION='GROT_GDEP’ and FORC_NODA moment equilibrium

#9 Code_Aster development » Challenge: Buckling of a tube under twisting moment... » 2022-08-17 09:08:28

jlucas
Replies: 0

Hello,

I recently posted a "challenge" on Code_Aster usage forum, and so far did not get any valid solution.

(see Buckling of a tube under twist (non-linear) calculix vs code-aster )

That is why decided to address directly the Code_Aster development forum.

===
Can Code-Aster perform a (non-linear) simulation of the buckling of a tube under twisting moment as described in the link above?
===

If so, shall I propose to add such example into the distributed code-aster tests/examples?

If not, shall I ask why such apparently simple simulation is so difficult to perform?


Thank you in advance,
Best Regards,
Jorge

#11 Re: Code_Aster usage » = Buckling of a tube under twist (non-linear) calculix vs code-aster = » 2022-08-15 18:32:27

== Code-Aster: Try C ==

Trying a "rotational" boundary condition on all nodes as in example ssnv507 (V6.04.507: Rotation d'une inclusion rigide avec X- FEM)

DTH=6.0;

tournex = FORMULE(VALE='sqrt(X*X+Y*Y)*cos(atan2(Y,X)+DTH*INST)-X',
                  DTH=DTH,
                  NOM_PARA=['X', 'Y', 'INST'],)

tourney = FORMULE(VALE='sqrt(X*X+Y*Y)*sin(atan2(Y,X)+DTH*INST)-Y',
                  DTH=DTH,
                  NOM_PARA=['X', 'Y', 'INST'],)



load=AFFE_CHAR_MECA_F( MODELE=model,
                       DDL_IMPO=(_F(GROUP_MA='sLoad',
                                    DX=tournex,DY=tourney)),
);
 

Results are still not right. See load path and deformation. Also, I don't know with this formulation how to specify in addtion that all other degrees of freedom except twist are fixed.

#13 Re: Code_Aster usage » = Buckling of a tube under twist (non-linear) calculix vs code-aster = » 2022-08-15 18:28:35

== Code-Aster: Try B ==
Mainly the same as Try A, but setting the deformation as "GROT_GDEP".

Looking at the load path and the deformation obviously something is wrong. Help is welcome and appreciated.

The doc U4.44.01 (AFFE_CHAR_MECA) (section 3.6) specifies that to use LIAISON_SOLIDE with large deformation hypothesis, the loading needs to be specified as TYPE_CHARGE='SUIV'. But by specifying such leads to the following error:

║ Erreur utilisateur :   
║   Le chargement contient des relations cinématiques LIAISON_SOLIDE qui sont non-linéaires
║ lorsque l'on utilise EXCIT / TYPE_CHARGE='SUIV'.   
║   Mais ce cas n'est pas traité car il y a au moins un noeud qui porte les degrés de liberté
║ DRX, DRY et DRZ.

So TYPE_CHARGE='SUIV' is not compatible with a rotation?

#15 Re: Code_Aster usage » = Buckling of a tube under twist (non-linear) calculix vs code-aster = » 2022-08-15 18:25:45

== Code-Aster: Try A ==

The loading is applied via a discrete element connected with LIAISON_SOLID to the nodes on the face where twist is to be applied. Deformation is set as PETIT, so not really expected to give valid results.

#17 Re: Code_Aster usage » = Buckling of a tube under twist (non-linear) calculix vs code-aster = » 2022-08-15 18:22:31

== CalculiX. ==
Enclosed are the simulation files, load path and an animation of the deformation.

(Note: The input files from CalculiX are compatible with Abaqus, so it should be easy to adapt and run the simulation using this software (in case someone wants to try)).

The loading is applied by connecting all dofs of a reference node with a surface using a *COUPLING/KINEMATIC card (see manual for reference).

****
*COUPLING, REF NODE=7430,SURFACE=sLoad,CONSTRAINT NAME=CN1
*KINEMATIC
1,2,3
****

Output files are converted to vtu in order to be viewed with paraview. Load path shows clearly stability loss associated with buckling and the following animation shows the result of the deformation. Qualitatively as expected.

#18 Code_Aster usage » = Buckling of a tube under twist (non-linear) calculix vs code-aster = » 2022-08-15 18:12:37

jlucas
Replies: 11

Hello,

I'm trying to perform a simulation to identify buckling of a tube under a twist moment. So far I did not manage to achieve this with code-aster, mainly, because I could not get right the formalism to apply large rotations. I present bellow my progress starting with the achievement using calculix and then each of my failed tries with code-aster. Any help/comment is welcome.

* Geometry of the tube:
  radius (m): 0.030
  thickness (m): 0.002
  lenght (m): 0.950
* Material properties (carbon steel):
  E (N/m^2): 207000000000.0
  nu: 0.290
* Boundary conditions:
  Fixed in one side;
  Twist moment is applied on the other side (0 - 6. rad).
  All other degrees of freedom except twist are supposed fixed on the loaded face.

The mesh is made of solid 1st order tetrahedral, so very accurate results are not to be expected.
The main objective at present stage, is only to check qualitatively that I the simulation is giving some sensible results.

#19 Re: Code_Aster usage » Steel tube under twist moment. Large deformations. (code-aster v15.4) » 2022-08-12 22:14:38

Hello

Apologies for the trouble.

The spreadsheet was mostly for a quick check and sorry I forgot to make it more user friendly. Also noticed that the moment formula on my post is not entirely correct. It should be instead:
Mz = SUM ((x+dx)*fy -y+dy)*fx ),

Nowadays I mostly use pandas to to this type of check. Maybe things would be clearer if I had done so. Attached a python script which might make the point a bit clearer.

The moment across the origin, without taking the deformation into account is computed at each node by:

df0['RMZ0'] = (df0['X'])*df0['RFY']-(df0['Y'])*df0['RFX']

The sum on all nodes on node set sLoad is given by:

df0['RMZ0'].sum()

>> 19999.97552466303

Taking the deformation into account:

df0['RMZ'] = (df0['X']+df0['DX'])*df0['RFY']-(df0['Y']+df0['DY'])*df0['RFX']

df0['RMZ'].sum()

>> 8181.999109394444

Trying a "rotational" boundary condition on all nodes as in example ssnv507 is giving me strange results, but will probably open a new topic related with this...

#20 Re: Code_Aster usage » Steel tube under twist moment. Large deformations. (code-aster v15.4) » 2022-08-12 12:10:15

Hello Jean Pierre Aubry,

Thank you for your reply,

and sorry, I still did not manage to make it work the way you suggested.

I enclose the try in case you want to give it a look or check.

However, I think your suggestion would still not solve the problem.

This is because I want to compute the reaction forces under the hypothesis of large deformations. The deformation needs then to be taken into account as it should be the result of vec_M(t) = vec_r(t) x vec_f(t). But what we are getting when asking for the reaction forces is vec_M(t) = vec_r(t=0) x vec_f(t).

When computing the moment by hand (see enclosed spreadsheet check.ods) as:

Mz = SUM (y+dy)*fx -(x+dx)*fy ),

(the sum is over all nodes in sLoad nodeset), I get 8182 N.m and not the 20000 N.m as specified with FORCE_NODALE.

I think in case your suggestion was working, I would still get a wrong computation, because the small deformation hypothesis was still being used.

Document U4.44.01, Section 3.2 lists the hypothesis and limitations of AFFE_CHAR_MECA.

Section 3.6 is dedicated to "Cas des grandes transformations".

If I understood correctly, LIAISON_SOLIDE can be used with large deformation hypothesis, but the loading needs to be specified as TYPE_CHARGE='SUIV'. But when I do that I get an error message that can not be applied to a rotation.

╔════════════════════════════════════════════════════════════════════════════════════════════════╗
║ <EXCEPTION> <CHARGES_36>   
║       
║ Erreur utilisateur :   
║   Le chargement contient des relations cinématiques LIAISON_SOLIDE qui sont non-linéaires
║ lorsque l'on utilise EXCIT / TYPE_CHARGE='SUIV'.   
║   Mais ce cas n'est pas traité car il y a au moins un noeud qui porte les degrés de liberté 
║ DRX, DRY et DRZ.                                                                       
╚════════════════════════════════════════════════════════════════════════════════════════════════╝


Another issue, on the present formulation in order to run smoothly without warnings, I need to declare the discrete element where I am applying the rotation as following a small deformation hypothesis, i.e:

_F(RELATION='ELAS',
    GROUP_MA=('nFix','nLoad'),
    DEFORMATION='PETIT',),

otherwise I get the following warning:
╔════════════════════════════════════════════════════════════════════════════════════════════════╗
║ <A> <DISCRETS_18>       
║ 
║ Only DEFORMATION ='PETIT' is possible for the discrete elements.   
║                                                                                               
║                                                                                               
║ This is a warning. If you do not understand the meaning of this   
║  warning, you can obtain unexpected results!                           
╚════════════════════════════════════════════════════════════════════════════════════════════════╝

which again does not feel right!

So, may I ask again

** How to apply torque for the case of large deformations and how to compute the reaction forces correctly? **

#21 Re: Code_Aster usage » using LIAISON_MAIL » 2022-08-12 07:58:39

Hello,

I had also a fight with this. The file is located within the temporary folder that is created to run the simulation. But this folder is deleted as soon as the simulation finishes and results are copied into your working folder. The workaround I've found was to copy the file during the simulation once available. You can specify the temporary folder where code-aster runs the simulation by editing the ".export file" and change/add the following lines.

P  proxy_dir  /tmp
P  rep_trav   /tmp/[temporary folder to run simulation]

I guess there might be proper ways to do this... probably some option in the export file to flag that the REP_OUT folder is also to be copied into the working folder... but could not find such option.

#22 Re: Code_Aster usage » Mesh formulation for hyperelastic case » 2022-07-15 12:14:34

Hello,

I have a very similar problem.  But recently, I've found a test example ssnv187e which uses MFRONT to define an hyperelastic material law with SIMO_MIEHE type of deformation. Then with this type of deformation it is possible to use the mixed formulation type of elements (INCO_UPG).

However I did not manage to make this work with code-aster version 14.6 only with 15.4 from the singularity container.

If you need to run the simulation through the command line, the following works with me:

$ singularity run -B  /tmp:/local00/tmp  salome_meca-lgpl-2021.0.0-2-20211014-scibian-9.sif shell -- as_run --run study.export

Basically you need to copy the mfront file "SignoriniSimoMiehe.mfront", located in the examples folder (also attached) into your simulations folder and add the following line into the corresponding*export file:

F libr [path_to_simulation_folder/]SignoriniSimoMiehe.mfront D  38

In the command file:

DEBUT();

# to compile the mfront material file use:
CREA_LIB_MFRONT(UNITE_MFRONT=38,UNITE_LIBRAIRIE=39)
[...]

# define the material using the mfront material law as:             
# change coefficients to material model values...
mat = DEFI_MATERIAU(ELAS_HYPER=_F(C10=_C10,C01=_C01,C20=_C20,K=_K,RHO=1000.),
                       MFRONT=_F( LISTE_COEF=[_C01,_C10,_C20,_K]),
);

[...]
STAT_NON_LINE(
                              [...]
                              COMPORTEMENT=(    _F( RELATION='MFRONT',
                                                                        DEFORMATION='SIMO_MIEHE',
                                                                        NOM_ROUTINE     = 'astersignorini',
                                                                        UNITE_LIBRAIRIE = 39,
                                                                        RESI_INTE_MAXI  = 1e-11,
                                                                        [...]
                                                                      ),),
                                [...]
);
[...]
FIN()

========
I am still verifying results, so can not give any assurance about this procedure, but so far it seems to perform well.

If you go through this procedure, please let me know if you find any unexpected/unattended results, or any other difficulty, so to take caution.

Regards,
Jorge

#23 Re: Code_Aster usage » internal variables for path_etude or path to mesh file in *.comm file » 2022-07-15 08:58:07

Hello,

I manage to read a file located in the same folder as the comm file by doing the following:

=== COMM FILE ===:

import pickle
# == Read data associated with geometry . ==
filename = 'fort.2'
with open(filename,"rb") as ifid:
    data = pickle.load(ifid)

DEBUT()
...
FIN()


==== EXPORT FILE ===:
[...]
F comm [path_to_file]/filename.pckl D  2
[...]

In my case I am reading information which is stored in a numpy pickle file.

By specifying the file with unit 2 in the export file. this file will be copied to the temporary folder where command files are executed as fort.2  and then can be accessed in the command file by this name.


also as alternative, I think you can specify this temporary folder in the export file by changing the following line:
P rep_trav /tmp/fea-computername-caster

regards,
Jorge.

#24 Code_Aster usage » Steel tube under twist moment. Large deformations. (code-aster v15.4) » 2022-07-15 00:38:58

jlucas
Replies: 4

Hello.

First let me give thanks to many users in this forum who have posted multiple useful examples and workarounds, which sometimes allowed me to understand and progress with code aster. Still progress is quite slow and sometimes frustrating...

I have a long steel cylinder tube fixed in one side, to which I apply a twist moment on the other side. For this model i know buckling should occur at around 19 kN. (see for example: Roark’s Formulas Ch.15.).

Now, I am applying a load of 20 kN and performing a non-linear static simulation (STAT_NON_LINE) with "GROT_GDEP" type of deformation.

I attach the mesh and command file for this simulation.


Question 1: How to extract the twist angle and reaction forces?

My first try: Use POST_RELEVE_T to extract these quantities.

code snippet:

twist__0 = POST_RELEVE_T(ACTION= _F( INTITULE='TWIST',
                                      OPERATION='MOYENNE_ARITH',
                                      GROUP_NO='pRot',
                                      NOM_CHAM='DEPL',
                                      NOM_CMP='DRZ',
                                      RESULTAT=result,),
);

# reaction force on the driving side.
rLoad__0=POST_RELEVE_T(ACTION=_F(OPERATION='EXTRACTION',
                                  INTITULE='SumReacForceLoad',
                                  RESULTAT=result,
                                  NOM_CHAM='REAC_NODA',
                                  GROUP_NO=( 'sLoad' ),
                                  RESULTANTE=('DX','DY','DZ',),
                                  MOMENT=('DRX','DRY','DRZ',),
                                  POINT=(0,0,0.95,),),)

# reaction force on the fixed side.
rFix__0=POST_RELEVE_T(ACTION=_F(OPERATION='EXTRACTION',
                                 INTITULE='SumReacForceFix',
                                 RESULTAT=result,
                                 NOM_CHAM='REAC_NODA',
                                 GROUP_NO=('sFix' ),   
                                 RESULTANTE=('DX','DY','DZ',),
                                 MOMENT=('DRX','DRY','DRZ',),
                                 POINT=(0,0,0,),),)

# print tables with IMPR_TABLE


Then I get the following result (for legibility columns are side by side).
                      
NUME                 TWIST      SumReacForceLoad   SumReacForceFix
ORDRE   INST       MOYENNE    MOMENT_Z        MOMENT_Z
0          0.000   0.000             0.000                0.000
1          0.100   0.058       1999.990               -1870.170
2          0.200   0.101       3999.990               -3289.110
3          0.300   0.134       5999.990               -4346.760
4          0.400   0.161       7999.980               -5180.430
5          0.500   0.182       9999.980               -5869.450
6          0.600   0.201      12000.000                   -6458.550
7          0.700   0.218      14000.000                 -6974.680
8          0.800   0.233      16000.000               -7435.130
9          0.900   0.246      18000.000               -7851.650
10          1.000   0.258      20000.000               -8232.560


Problem. Force Balance does not seem right. There is a quite large mismatch between the driven side and the fixed side, so something must be wrong...
Ah Ah!!! The deformation is not being taken into account!!! Also note that on the fixed side where the deformation is lower, the reaction load is quite far from the specified 20kN.

Question: How to sort this out in a nice way? I guess i am not applying the torque load correctly...

In the forum I've found a relatively nice workaround which worked for me with code aster v14.6, but not with v15.

This workaround suggests to apply the deformation to the mesh before computing/extracting the moments. To get the same information as in the previous table, the deformation needs to be applied on every time step.

My code snippet:

# == get twist angle and reaction forces into a table  == #
# == taking the deformation into account   == #

# this is to check on how many time steps are there
var_acc = result.LIST_VARI_ACCES();
nsteps = len(var_acc['NUME_ORDRE']);
res ={}

twist = [None]*nsteps;
rLoad = [None]*nsteps;
rFix = [None]*nsteps;

# for each time step add the deformation to the mesh and extract twist angle and moments.
for kk in range(nsteps):
   
    depl = CREA_CHAMP(OPERATION = 'EXTR',
                      NOM_CHAM = 'DEPL',
                      TYPE_CHAM = 'NOEU_DEPL_R',
                       RESULTAT = result,
                       NUME_ORDRE = kk,
    )

    _mesh = COPIER(CONCEPT=mesh)
   
    mesh = MODI_MAILLAGE(reuse = mesh,
                          MAILLAGE = mesh,
                          DEFORME = _F(OPTION = 'TRAN',
                                       DEPL = depl),);

    twist[kk] = POST_RELEVE_T(ACTION= _F( INTITULE='TWIST',
                                        OPERATION='MOYENNE_ARITH',
                                          GROUP_NO='pRot',
                                        NOM_CHAM='DEPL',
                                        NOM_CMP='DRZ',
                                        RESULTAT=result,
                                        NUME_ORDRE=kk,),
    );
   
    rLoad[kk]=POST_RELEVE_T(ACTION=_F(OPERATION='EXTRACTION',
                                     INTITULE='SumReacForceLoad',
                                     RESULTAT=result,
                                     NOM_CHAM='REAC_NODA',
                                     NUME_ORDRE=kk,
                                     GROUP_NO=( 'sLoad' ),
                                     RESULTANTE=('DX','DY','DZ',),
                                     MOMENT=('DRX','DRY','DRZ',),
                                     POINT=(0,0,0.088,),),)

    rFix[kk]=POST_RELEVE_T(ACTION=_F(OPERATION='EXTRACTION',
                                      INTITULE='SumReacForceFix',
                                      RESULTAT=result,
                                      NOM_CHAM='REAC_NODA',
                                      NUME_ORDRE=kk,
                                      GROUP_NO=('sFix' ),   
                                      RESULTANTE=('DX','DY','DZ',),
                                      MOMENT=('DRX','DRY','DRZ',),
                                      POINT=(0,0,0,),),)

    DETRUIRE( CONCEPT=_F( NOM=(depl,mesh) ) )
    mesh = COPIER(CONCEPT=_mesh)
    DETRUIRE( CONCEPT=_F( NOM=(_mesh) ) )


Which gives the following result:

                TWIST      SumReacForceLoad   SumReacForceFix
NUME_ORDRE  INST    MOYENNE      MOMENT_Z         MOMENT_Z
0        0.000    0.000      0.000                 0.000
1        0.100    0.058      1870.170         -1870.170
2        0.200    0.101      3289.110         -3289.110
3        0.300    0.134      4346.760         -4346.760
4        0.400    0.161      5180.430         -5180.430
5        0.500    0.182      5869.440         -5869.450
6        0.600    0.201      6458.550         -6458.550
7        0.700    0.218      6974.670         -6974.680
8        0.800    0.233      7435.120         -7435.130
9        0.900    0.246      7851.640         -7851.650
10        1.000    0.258      8232.550         -8232.560

Nice!!! now the force balance seems to be right, but the reaction force is quite far from the specified 20 kN.m.

Here honestly still did not find the solution.

====                                           ====

Now the question which took me to write to the forum:

The attached code, works fine with code ater version v14.6, but not with v15.4. When running the same command files with the latest version I get the following error:

╔════════════════════════════════════════════════════════════════════════════════
║ <EXCEPTION> <MESH1_1>                                                                         
║                                                                                               
║ Le déplacement fourni est associé à un maillage différent du maillage à déformer.             
║ Il faut que ces deux maillages soient les mêmes.                                               
║ Pour créer un champ de déplacement adapté au maillage, on peut utiliser la commande           
║ PROJ_CHAMP.                                                                                   
╚════════════════════════════════════════════════════════════════════════════════


So my final question.

   ** How should torque be applied for the case of large deformations and how to compute the reaction forces correctly? **

#25 Re: Code_Aster usage » Buckling of a cylinder under a twist moment. » 2022-06-08 17:55:55

Hi,

By changing DEFORMATION to 'PETIT_REAC', got a slightly lower value for the buckling moment equal to 17.2 kN.m, instead of 19.2 kN.m as computed with the small deformation hypothesis. This makes all sense to me. However, I would expect to get a similar result by using a large displacement formulation like for example 'GROT_GDEP', which is not the case.

I checked the examples listed document U2.08.04 (Notice de calcul au flambage) and none of those listed in "Modes d’Euler et calcul non linéaire" used a deformation other than 'PETIT'. So my suspicion is that the "Non-Linear Euler buckling" computation does not work with other than small deformation hypothesis.

Could someone with more insight confirm or contradict this affirmation?

Thank you in advance,

Jorge