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

You are not logged in.

#1 Re: Code_Aster usage » Oscillation of temperature in a COQUE model. » 2022-04-21 13:32:03

Hi, Are you using 2:nd order elements? - If I remember correct it is better to use linear elements for thermal simulations and that this will solve the oscillation issue.

#2 Re: Code_Aster usage » HEXA20_27, PENTA15_18 and the conformity of the mesh » 2022-04-05 15:16:05

Hi, No I have not wound a answer.

Regarding the contact problems, -are you using Salome meca 2021? -Have you seen this post:https://code-aster.org/forum2/viewtopic.php?id=26047

I tried your idea with salome bi-quadratic but it seems this does not create PENTA18. It creates PENTA20. I am not sure CA will be able to handle them.

#3 Re: Code_Aster usage » Make the whole mesh bigger/smaller in code aster » 2022-04-05 14:18:26

You can scale it with MODI_MAILLAGE + ECHELLE.

#4 Re: Code_Aster usage » Error in STAT_NON_LINE » 2022-01-13 21:43:48

No i do not. Maybe change to linear elastic material first and then troubleshoot from there.

#5 Re: Code_Aster usage » Error in STAT_NON_LINE » 2022-01-13 16:35:10

CARA_ELEM=elemprop, is missing for your STAT_NON_LINE case.

#6 Re: Code_Aster usage » How to display moment and axial force » 2022-01-12 21:13:40

You can print to .resu file with:






#8 Re: Code_Aster usage » [SOLVED] DEFORMATION='GROT_GDEP’ and FORC_NODA moment equilibrium » 2021-12-08 22:17:23

I did investigate this a bit further.  I printed out coordinates, deformations and nodal forces and check the equilibrium:


i=1; Msum=0;

The result for GROT_GDEP and using all Beam nodes is:
Msum =-4.2277e-07   3.4652e-07  -6.6579e-07
Hence the beam moments are zero -OK.

The result for GROT_GDEP and using right end nodes is:
Msum = -9.7829e+08   4.7920e+07  -1.4075e+07
Hence the same result as the reaction on the left end side. As expected.

If I neglect the deformation using  V=COORD(i,1:3) I get the results given in the previous posts. E.g. for the right end nodes:
Msum = -9.3282e+08   4.8051e+07  -1.4106e+07

So if my investigation is correct the print out from POST_RELEVE_T and MOYE_NOEUD='OUI’  is without taking the deformation into account in the moment calculation. This works ok for PETIT but not for PETIT_REAC and GROT_GDEP. –Does someone know if it is possible to force it to do so?


#10 Code_Aster usage » [SOLVED] DEFORMATION='GROT_GDEP’ and FORC_NODA moment equilibrium » 2021-12-08 08:20:35

Replies: 4

I am trying out simulations with large rotations and deformations GROT_GDEP. I have a horizontal beam fixed at the left end and at the right end loaded by a vertical surface pressure. The beam bends downwards in the negative z-direction. See attached figure.  The pressure load is of type SUIV/follower load. The beam is 1000mm long and the maximum displacement is ~170mm in the negative z-direction.

With DEFORMATION=‘GROT_GDEP’  I get the following displacement at the right end:
                             DX                                  DY                                       DZ
Right end        -9.49071988320817E-02 -1.93657103389098E+01 -1.72476505187015E+02

And the following forces:
                      RESULT_X      RESULT_Y     RESULT_Z      MOMENT_X     MOMENT_Y     MOMENT_Z
Beam            1.52710E-10 -2.29193E-10 -4.86864E-09   4.54745E+07  1.31263E+05 -3.13190E+04
Left end       -1.44293E+02  2.79228E+05  9.60747E+05   9.78294E+08 -4.79202E+07  1.40746E+07
Right end       1.44293E+02 -2.79228E+05 -9.60747E+05  -9.32819E+08  4.80515E+07 -1.41059E+07

‘Beam’ is the sum of all FORC_NODA of the nodes of the beam volume elements (TETRA10). ‘Right end’ is the force applied at the right end. ‘Left end’ is the reaction at the left end.  The MOMENT_X for all the beam nodes is 4.54745E+07  which is 4.54745E+07/9.32819E+08 =5% of the applied MOMENT_X= 9.32819E+08 at the right end. I find this result difficult to understand. That the beam is not in equilibrium regarding moment about X does not make sense.

With DEFORMATION=‘PETIT’  I get the following displacement at the right end:
                             DX                                  DY                                       DZ
N8        -9.78444452002913E-02 -1.24114888251096E-01 -1.70929183101883E+02
And the following forces:
                      RESULT_X      RESULT_Y     RESULT_Z      MOMENT_X     MOMENT_Y     MOMENT_Z
Beam            7.18131E-10  1.03910E-10  1.33582E-09  -4.32727E-07  1.48014E-07  1.75791E-07
Left end       -1.30319E+02  2.75596E+05  1.00028E+06   9.72714E+08 -5.00266E+07  1.39103E+07
Right end       1.30319E+02 -2.75596E+05 -1.00028E+06  -9.72714E+08  5.00266E+07 -1.39103E+07

The MOMENT_X for all the Beam nodes is zero and the moment applied at the right end MOMENT_X = 9.72714E+08 is the same as the moment supported at the left end. This result is what I would expect.

See attached files . Is the GROT_GDEP FORCE_NODA calculated correct? –is there some option that need the be specified in CALC_CHAMP for the calculation of FORC_NODA? –or what does it mean that the MOMENT_X  is non zero? The beam stress is high in this case ~5000MPa, still I think the equilibrium should be possible to understand.

Here is something similar where it is found that for GROT_GDEP with C_PLAN elements you have to use RELATION='VMIS_ISOT_LINE’: /forum2/viewtopic.php?id=21492 . But I have not found similar information for my case.

Any inputs are appreciated. -How can non zero MOMENT_X for the beam be understood or corrected?


#11 Re: Code_Aster usage » Weird Behavior of POU_* Elements with GROT_GDEP » 2021-12-01 21:58:10

Hi, Has there been progress since 2016 regarding robust/correct  results with POU_D_T_GD elements as mentioned here and in post  /forum2/viewtopic.php?id=21253 ?

I tried case (3) from /forum2/viewtopic.php?id=21253 with salome meca 19 and 21. Comparing the mess files I got the same results as back in 2016.

#12 Re: Code_Aster usage » How to change a spring constant from one STAT_NON_LINE to the next? » 2021-11-15 14:04:25

Hi, interesting solution if you can make it work.
A different method is to create a "spring" with some structural elements, a temperature history and then let the modulus of elasticity of the structural elements be a function of temperature and hence a function of time. Some advantages: It can handle iteration cutbacks. Also, If I remember correct, you can not use discrete elements in simulation with large displacements. In the end, if you are heading for contact simulation you may also want large displacements.

#13 Re: Code_Aster usage » Linear Buckling of Cylinder Under External Pressure » 2021-11-14 16:34:47

Hi,  -  double check the latest documentation:
"lamda : eigenvalue ( lamda=−mu with mu multiplying coefficient of loading)"
"Note: It is well the critical load factor mu and not lamda who is stored in the concept result."


#14 Code_Aster usage » HEXA20_27, PENTA15_18 and the conformity of the mesh » 2021-11-14 15:59:11

Replies: 2

Hi, A Question about CREA_MAILLAGE HEXA20_27, PENTA15_18 and the conformity of the mesh.

HEXA27 is recommended for contact analysis(u4.44.11, u2.04.04, u4.23.02) and my experience is that for contact with friction it is a huge difference in converges compared to other elements. At least for FORMULATION='CONTINUE’.

But there is extra effort building the mesh. Building a combined mesh with HEXA20 and PENTA15 can often be easier. However it may then become complicated to convert the mesh into a HEXA27 mesh since CREA_MAILLAGE with keyword HEXA20_27 only modifies QUAD8  and HEXA20 elements (into QUAD 9 and HEXA27).

If you convert a combined HEXA20+PENTA15 mesh using HEXA20_27=_F(TOUT='OUI’) , then on the QUAD sides of the PENTA15 you will get QUAD9 elements that do not conform with the underlying PENTA15. The problem is not solved by sequentially adding the PENTA15_18 operation. QUAD9 elements will then exist on the quad sides of the PENTA18 but the elements will not be joined at the mid side node. The end result is a mesh where you can not use the quad side elements of the pentas.

1 -If converting a combined mesh HEXA20+PENTA15 mesh using HEXA20_27=_F(TOUT='OUI’) and then only using the quad sides of the HEXA27 and the triangular sides of the PENTA15 elements: -Will this be ok? –Or will the nonconformity between then voluminal HEXA27(with mid side node) and the PENTA15(without midside node) reduce the accuracy of the stresses and the deformations?

2 -For a HEXA20_27=_F(TOUT='OUI’) + PENTA15_18=_F(TOUT='OUI’) mesh a way to attach the QUAD9 side to the PENTA18 could be to merge the mid side nodes manually (for example by importing them into Salome + merge + export). –Would this be good way to solve this issue if you want to be able to use also the quad sides of the pentas? –Or is there another way? (The documentation says not “At present, mixed grids made up at the same time ofHEXA20 and of PENTA15 are not transformable by CREA_MAILLAGE”) –Still Would the presented “manual merge” idea work?

3 –For a mesh with only PENTA18 (created with the PENTA15_18 =_F(TOUT='OUI’) operation) will the QUAD9 sides perform as good in contact as if the underlying element was a HEXA27?

4 -Anyone want to recommend an automatic hex-mesher?   -Are the Salome plugins DISTENE "MG-" algorithms good?

Thank you for your inputs!

#15 Re: Code_Aster usage » Linear Buckling of Cylinder Under External Pressure » 2021-11-11 21:29:26

Hi, I think that if the applied load points is the direction in which the buckling mode deforms then the multiplicator is positive. Otherwise negative. If I understand your description correct that is also what your results show.

#16 Re: Code_Aster usage » Contact with friction: -performance tetra/hexa - Contact algorithms » 2021-11-10 13:44:15

It seem that I get much better results if I use ALGO_CONT='PENALISATION’ combined with  ALGO_FROT='PENALISATION’. Maybe one should not mix ALGO_CONT=STANDRARD’ and ALGO_FROT='PENALISATION’?.

So first I then need to set a reasonable COEF_PENA_CONT. For DISCRETE formulation the documentation u2.04.04 says:
“One generally chooses E_N by successive tests: • first of all one will start by taking a value equalizes with 10 times the largest Young modulus of the structure multiplied by a length characteristic of this one; “. For CONTINUE formulation I can not find any guide in the documentation. Is it reasonable to use a value similar to E_N?

So for example would it be reasonable, for a simulation with modulus of elasticity 210e3MPa and with a contact diameter of 100mm, to use:

Here: code-aster.org/forum2/viewtopic.php?id=24855 a much lower value is suggested: COEF_PENA_CONT=210e3/100=210e1

Which of these values are reasonable to start with?  10*E*size=210e6 or E/100=210e1???

#17 Re: Code_Aster usage » Contact with friction: -performance tetra/hexa - Contact algorithms » 2021-11-10 10:38:03

As I mentioned above the ALGO_FROT='PENALISATION’ algorithm seem attractive since it stable and relatively fast converges to a solution.
I did a study of how to adjust the COEF_PENA_FROT parameter so that the friction forces would be accurately transferred. See attached pages. However with the simulations I did I found no way to adjust the parameter that would accurately describe the load path in this case. In this study HEXA27 elements are used.

-Is it due to over estimated slip that ALGO_FROT='PENALISATION’ can not accurately describe the load path?
-Do you have any tip how to improve the contact definition (see last page)?

#19 Code_Aster usage » Comparison SM2019 vs SM2021 - odd contact results » 2021-11-09 21:09:21

Replies: 2

Hi, I ran the same contact analysis with Salome Meca 2019 and 2021. See attached picture and files
-Why are the SM2021 contact results with HEXA27 elements so spotted?

Some other points:
-While debugging mistakes in the .comm file I notice that very few errors are reported to the .mess file with SM2021.
-With SM2021, concepts are not presented by their names but by some id number. For example in the .resu file the RESU concept R1 = STAT_NON_LINE.... is denoted 00000011.
-SM2021 include CA version 15.4. On the down load page only CA 14.4 can be downloaded (stable version). -Is it possible to down load also CA 15.4? -where?

-Is anybody else experiencing these points with SM2021?

#20 Re: Salome-Meca installation » Salome-Meca 2021: Download fails » 2021-11-07 19:55:40

OK, I assumed that after a while.
Check also
"salome_meca-lgpl-2021.0.0-1-20210811-scibian-9.sif" under installation. Should be 
"salome_meca-lgpl-2021.0.0-0-20210601-scibian-9.sif" I think.

#21 Re: Salome-Meca installation » Salome-Meca 2021: Download fails » 2021-11-06 23:06:33

I have downloaded salome_meca-lgpl-2021.0.0-0-20210601-scibian-9.sif a couple of times. I get md5sum
c34331b7c3161021cb20731cd9a16b16 which is different from on the code-aster.org download page
-Is my file corrupt? -is the checksum on the download page wrong? -someone else experience the same?

#22 Re: Salome-Meca usage » Creation of Hexa mesh on 3D CAD geometry » 2021-11-03 19:32:21

Thank you for inputs Claws and Irvise. I will try your recommendations with Hexahedron (i,j,k) Irvise.

-It would be interesting to have a comment about plugins DISTENE "MG-" algorithms? since they would be integrated into salome. -Anyone have experience from them? -good? -affordable?

#24 Re: Code_Aster usage » Contact with friction: -performance tetra/hexa - Contact algorithms » 2021-11-01 23:06:08

After more testing it seems that Using, ALGO_FROT='PENALISATION', solves this problem good. You just need to verify a reasonable value of COEF_PENA_FROT to use.
Document U2.04.04 says: "For studies where adherence is dominating, one will support values of COEF_FROT lower than the value by default(100) while for cases where the slip is dominating, one will choose higher values."  -Does this mean that convergens will be faster by doing this? -Or that the accuracy of the calculated slip will be better? -Both? Is the same valid also for COEF_PENA_FROT?

When testing this out I found a interesting/odd result. Even if I force two surfaces to slide relative to each other CA says that some nodes are sticking. See attached case with a box sliding on a plane from instant t=2.0 to t=3.0.
-CA says some nodes are sticking (RTAX, RTAY, RTAZ)!=(0,0,0). See attached picture -Why?
-The slave nodes are on the box -should not the stick/slip efforts be in the other direction?

#25 Salome-Meca usage » Creation of Hexa mesh on 3D CAD geometry » 2021-10-29 07:37:21

Replies: 4

Hi, What algorithm are you using to create hexa mesh on 3D CAD models?

My experience is only from "Extrusion 3D". I then use 1D algorithm: Local length, 2D(submesh) algorithm Netgen + "Quad-dominated" and 3D algorithm "Extrusion 3D". These algorithms work ok for some shapes but essentially the geometry must be divided up in parts each being 2D and then extruded from that.

-How do you proceed to overcome this for more complex shapes? -What algorithm are you using?

-Anybody using the plugins DISTENE "MG-" algorithms? -Are they good? -Easy buy and install?