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

You are not logged in.

#1 Re: Salome-Meca usage » [SOLVED] A big difference in simulation result between SW and Salome » 2021-12-15 17:28:34

Now I remembered the exact technical term: its a "solid" calorimeter.
Now its should be clear how to calculate by hand

#3 Re: Salome-Meca usage » [SOLVED] A big difference in simulation result between SW and Salome » 2021-12-15 09:50:36

My question is: is there an analytical way to determine the function, see appendix. If we have this function then we can say clearly what is right and what is wrong.

#4 Re: Salome-Meca usage » [SOLVED] A big difference in simulation result between SW and Salome » 2021-12-14 17:36:46

Is there an analytical way to obtain the function of thermal balancing?
Or other Question: which material property can you change to suppress geometrical nonlinearities as best as possible?

#5 Re: Salome-Meca usage » [SOLVED] heat shock » 2021-12-09 10:01:10

Have you already tested a modelling without using LIAISON_MAIL?
I mean you have only one "real" solid and two zones of solid elements...

#6 Re: Code_Aster usage » [SOLVED] Bolt pretension lock » 2021-11-15 12:16:05

I have doubt that in your model all prestessed regions are able to deform in a realistic way of.
(Compare with theorem of virtual work)

One example: you have a M12 bolt 8.8.
Then the stress cross-section is 84,3 mm^2 (acc. ISO898-1)
In EC3 you will find a pretension force of F p,C = 47200 N.
The normal stress after prestressing is 560 MPa in the stress cross-section, now.

The yield point of the bolt is 640 MPa.

As long as your connected plates are deformationless in the direction of the thickness you will only reach a additional external force of 7000 N till reaching the yield point (in contrary to 47200 N prestress force)...

3D Solid model?

#7 Re: Code_Aster usage » Error in DEFI_MATERIAU If I use ELAS_FO and MOHR_COULOMB » 2021-09-13 15:04:05

Thank you!

There is another (interesting) file: defi_materiau.py


But the question remains, how to compile the files new?

#8 Code_Aster usage » Error in DEFI_MATERIAU If I use ELAS_FO and MOHR_COULOMB » 2021-09-13 13:10:57

Replies: 2

Bonjour la communauté Code_Aster!

I have a material model for soil whose young moduls depends on pressure.
So I try to use in DEFI_MATERIAU  ELAS_FO together with MOHR_COULOMB.


      ! Regulate (S) not respected (S):                                            !
      ! - Le mot clé 'MOHR_COULOMB' étant présent, il faut que : ELAS soit présent !

I think, the error output means that MOHR_COULOMB needs ELAS not ELAS_FO. Is that correct?

I have extended "Code_Aster/PRODUCTS/code_aster/14.4/lib/aster/Comportement/mohr_coulomb.py" by ELAS_FO:

loi = LoiComportement(
    nom            = 'MOHR_COULOMB',
    lc_type        = ('MECANIQUE',),
    doc            =   """Loi de Mohr_Coulomb, non-associée, pour la mécanique des sols (cf. [R7.01.16] pour plus de détails).
            Pas d'ecrouissage"""              ,
    num_lc         = 55,
    nb_vari        = 3,
    nom_vari       = ('EPSPVOL','EPSPEQ','INDIPLAS',),
    mc_mater       = ('ELAS','ELAS_FO','MOHR_COULOMB',),#Volker_2021-09-13

But it doesnt helps.
How to recompile this file?

Any suggestions are welcome!

Kind regrads Volker

#9 Re: Code_Aster usage » How to ramp loads BETWEEN loadsteps? » 2021-08-31 12:17:20

regarding you "FOR IN RANGE LOOP":
I think, if you want to reimport the last result into a new calc then
INST from last result "evol_ther" should be equal to INST from new starting THER_NON_LINE, means
your time stepping has to be INST [new start calc] = INST [last step from old calc]

#10 Re: Code_Aster usage » Simplifying Modelling for a PV Module Frame » 2021-08-30 09:39:41

A well-known rail vehicle manufacturer would model it like this:
(without waranty that your costumer wants it like this)
The proof concept for those is the nominal stress concept.

The first step is to derive the mid surface, that you obtain a clean shell model.
Secoundly meshing all as a compound to prevent that you need operator  "liasson-maille" etc..
Mesh zise sould be approx. 20 mm. Also try to suppress all driangle elements.

Use all symmetry conditon.. etc.
Then run time should only a couple of secounds.

I hope it helps you or other "code_aster" enthustiastics

#11 Re: Code_Aster usage » Oscillations in transient thermal results THER_NON_LIN » 2021-08-11 12:23:12

I have often used this construct for thermal calculations of power plant equipment


without a for in range loop. I find that the units in Code_Aster are a bit tricky at times.

Kind regards Volker

#12 Re: Code_Aster usage » [SOLVED] Increasing number of threads increases computational time » 2021-08-05 08:43:07

here some hints from me:

You use parallelisation method openMP not mpi.
(mpi requires, additional to openMP, domain decomposition what you can do with scotch for instance. You can google after scotch and domain decomposition. Then it becomes more clear…)

My experience with a small model and many time steps (Dyn_non_line) was:
-    starting only one thread
-    switch out hyper threading in the Computer BIOS
-    seek for a computer with the highest tact frequency

#13 Re: Code_Aster installation » Code_aster 15.4 MPI installation problem » 2021-08-02 09:56:35

Hi Anirudh,

for which applications and tasks is the PETSC solver compulsory for you?
Can you live also with the mumps solver (for openMP and mpi calculations) together with MULT_FRONT solver (only for openMP calculation)?

Greetings Volker

#14 Re: Code_Aster installation » Code_aster 15.4 MPI installation problem » 2021-07-22 11:07:58

METIS produces a shared-memory-object and
SCOTCH produces in my opinion both or at least also one distributed-memory-object ...

#15 Re: Code_Aster installation » Code_aster 15.4 MPI installation problem » 2021-07-22 11:02:37

first of all I have the greatest respect for your project.

I was thinking about the error message:
"... can not be used when making a shared object ..."
In my opinion this means PETSC needs a "distributed memory object" not a "shared memory object".

Distributed memory objects are needed for mpi parallelization. In contrary
Shared memory objects are needed for openMP parallelization.
I know the mumps solver can deal with both objects, but Im not sure that PETSC can do the same.

So one hint is to comment out the PETSC Solver. Or try to compile PETSC solver for both memory objects...

Good Luck. !!! Pleace let me know when you have any progress in your project. Thank you.


#17 Re: Code_Aster usage » Differences in Von Mises Stresses » 2019-10-10 15:00:14

Hi Astercode,
I tested my suggestion and now I get exactly the same result as in the analytical calculation with Sigma = 120 MPa .
Have you already achieved the same in Nastran?
I attach my .comm file for comparing. Kind regards Volker

#18 Re: Code_Aster usage » Differences in Von Mises Stresses » 2019-10-09 14:06:21

Hi Astercode,
again, both numerical calculations are wrong (also Nastran). Change the boundary conditions in both systems that you get 120 MPa in both numerical calculations Aster and Nastran.  This is very important. Your boundary condition produces a singularity. The correct result should be infinitely in Aster and Nastran !!! ...
Kind regards and good luck Volker

#19 Re: Code_Aster usage » Differences in Von Mises Stresses » 2019-10-09 07:45:09

Hi Astercode, I compared the results and my conclusion is both numerical solutions are wrong.
What happens if you only set  DX of 'NODES_CONSTR' = 0 and an absolutely unimportant node gets the rest (DY, DZ, DRX, DXY, DRZ =0)??

#20 Re: Code_Aster usage » Differences in Von Mises Stresses » 2019-10-08 15:41:45

Hi astercode,
have you already compared your numerical solutions with the analytical solution?

A numerical solution is a good start point to investigate commercial and open source software.

Kind regards and good luck Volker

#21 Re: Code_Aster usage » Problem with Data transfert from CFD to Aster » 2019-07-09 15:11:22

Hi, the error message tells NOM_CHAM in your result file is "T". "T" is not allowed. One solution could be NOM_CHAM = "TEMP" or "TEMP_ELGA"...

#22 Re: Code_Aster installation » Salome-Meca V2018 on Ubuntu 18.04 » 2019-07-01 10:35:04

I was the next one with this problem.
On my machine helps this, and I don't know why:

LD_PRELOAD='/usr/$LIB/libstdc++.so.6' ./salome
(see thread code-aster.org/forum2/viewtopic.php?id=24078)

#23 Re: Code_Aster usage » E_Young varies by EPSI or DIVU » 2019-06-19 15:04:35

Hi, I think E an NU can't be a function of EPSI, only X, Y, Z and INST.
I would check the material model...
Kind regards Volker

#24 Re: Code_Aster usage » How calculate the Principal Stresses on a surface of a solid? » 2019-05-28 10:04:30

Hi All,
here a sketch with my interpretation of the local stresses according the FKM Guideline:

How can we calculate the stress gradient with Code_Aster??

Kind regards Volker

jeanpierreaubry wrote:

i do think this is not necessary maybe giving wrong results by polluting the model..

I total agree with you ,
but I got also the same advice from a commercial support-team to introduce skin elements ;-)

#25 Re: Code_Aster usage » How calculate the Principal Stresses on a surface of a solid? » 2019-05-27 11:47:54

Bonjour Johannes,
which part of FKM Guideline do you mean ??
Do you mean for example calculation of G_Sigma and G_Tau according equation no. 4.3.17 ??

Kind regards Volkere