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

You are not logged in.

#1 Re: Code_Aster usage » CALC_MODES and MATR_DISTRIBUEE » 2022-08-04 10:11:24

Hi Stephane,
my guess is that the message in the log file is very generic and doesn't change
depending on the context from where the MUMPS solver is used (e.g. the analysis type).
Also based on the documentation and your test MATR_DISTRIBUEE simply isn't available in CALC_MODES.

I guess you need to find a different approach for reducing the memory demand of the Egenmode calculations (which indeed is very high in Code-Aster based on our experiences as well).

Best,
Richard

#2 Re: Code_Aster usage » [SOLVED] Revolute joint with DIS_TR elements and LIAISON_SOLIDE. » 2022-03-11 09:59:08

Hi Helio,
the behavior you are seeing is simply explained by the fact that you are using a linear static setup, so only small rotations are supported.
The observation you make - expansion under rotation - is a typical phenomena when you don't have rotation-invariance due to small strain formulation.

You need to use STAT_NON_LINE with the proper nonlinear behavior to make this work for large rotations.

Best,
Richard

#3 Re: Code_Aster usage » [SOLVED] FORTRAN routines CA development material laws!? » 2022-03-08 12:41:24

Hello,
I think you will find an answer to your question in the "Developer" section of the documentation, in particular this document might help you to get started: https://www. code-aster.org/V2/doc/default/fr/man_d/d5/d5.04.01.pdf

Best,
Richard

#4 Re: Code_Aster usage » [SOLVED] Extracting results at particular surface of thermal analysis » 2021-12-15 15:20:14

No worries, it's not so important.
I think you just have to edit the first post in the thread, where you should be able to edit the "subject".
Other than that I have no other way.

Best,
Richard

#5 Re: Code_Aster usage » [SOLVED] Extracting results at particular surface of thermal analysis » 2021-12-15 13:50:21

Hi Ennio,
good to hear that!

One small point: could you add "[SOLVED]" in front of the title of the forum post, so others can see that this was actually solved, it's a good practice.

Best,
Richard

#6 Re: Code_Aster usage » [SOLVED] Extracting results at particular surface of thermal analysis » 2021-12-15 10:18:55

Hi,
you are using the NOM_CMP wrongly. This is used to restrict the output of the field you defined under "NOM_CHAM" to specific components.
For example, a Displacement field (DEPL) has components "DX, DY, DZ", so if you want to only print out the X-displacement you can use NOM_CMP="DX". The Temperature field "TEMP" has only the Temperature "TEMP" as component (maybe more if you have structural elements).

Ideally you have a look at the documentation page for this command: https hmm/www.code-aster.org/V2/doc/v14/fr/man_u/u4/u4.91.01.pdf

You can see that there is one option "IMPR_COOR", which is default as "NON". If you set it to "OUI" it should print also the node coordinates to the result.

Best,
Richard

#7 Re: Salome-Meca usage » [SOLVED] A big difference in simulation result between SW and Salome » 2021-12-15 10:08:51

Hi,
are you sure about your units?
In the mesh screenshot you say "mm", so I suppose thats the lenght unit you are using.
But in a later post where you have your material properties shown, it looks like SI units, with lenght unit "m".

Can you confirm which unit system are you using?

Best,
Richard

#8 Re: Salome-Meca usage » [SOLVED] heat shock » 2021-12-08 11:01:43

Ok, t
hen you can try with a smaller time step or fully implicit time integration (theta=1, default is 0.57).

Best,
Richard

#9 Re: Salome-Meca usage » [SOLVED] heat shock » 2021-12-08 10:12:06

Hi, for thermal shock applications it is recommended to use 3D_DIAG elements, as its known that full integration elements have the tendency to cause numerical oscillations in the temoerature.
See for ecxample in the training materials here Slide 8:
https hmm/www.code-aster.org/V2/UPLOAD/DOC/Formations/06-thermal_analysis.pdf

Best,
Richard

#10 Re: Code_Aster usage » Oscillations in transient thermal results THER_NON_LIN » 2021-08-10 07:19:48

Hi Rodrigo,
while we don't have your input data, I can just say that oscillations are a typical behavior for thermal transient analyses with rapid change of temperatures when using standard elements.
You can use diagonalized thermal mass elements (3D_DIAG) to reduce these oscillations.
You can see a good example here on Slide 8: code-aster.org/V2/UPLOAD/DOC/Formations/06-thermal_analysis.pdf

Best,
Richard

#11 Re: Code_Aster usage » [SOLVED] Stress analysis on a symmetrical shaft » 2019-11-15 09:39:25

Hi marcelo,
it seems you are still missing the AFFE_CARA_ELEM command to assign the structural element properties (spring stiffness) of your DIS_TR elements.

Best,
Richard

P.s.: What you could also do is to run a quick analysis on SimScale (free) with a similar setup and check the log file, there you can see exactly how the  command file is built and you can use this information for your file. For example this project could be helpful: https://www. simscale.com/projects/rszoeke/pinned_bar_example/

#12 Re: Code_Aster usage » Fix limitation with parallelism for DYNA_NON_LINE + CONTACT » 2019-05-26 23:41:14

Hello,
since which version is this allowed?
We are using V14.2.0 and for that, still with NORMALE='MAIT' we get this error:

   !-----------------------------------------------------------------------------------------------------------------!
   ! <EXCEPTION> <CONTACT3_46>                                                                                       !
   !                                                                                                                 !
   ! Pour la dynamique non linéaire implicite avec contact, il faut utiliser la méthode de distribution centralisée  !
   ! "DISTRIBUTION=_F(METHODE='CENTRALISE')" dans AFFE_MODELE.                                                       !
   !-----------------------------------------------------------------------------------------------------------------!

Best,
Richard

#13 Code_Aster usage » Fix limitation with parallelism for DYNA_NON_LINE + CONTACT » 2019-05-24 08:09:34

RichardS
Replies: 2

Hi all,
we are having performance issues with large cases of "drop test" problems that require DYNA_NON_LINE + CONTACT/CONTINUE and we suspect that this is related to the limitation that since version 13.4.15 parallelism is forbidden for these cases (only use of PARALLELISME='CENTRALISE') - see https: //bitbucket.org/code_aster/codeaster-histor/src/731e9ba037e37d0f895a65a252b9663ca58ae6bf/13.4.15

I would like to reach out to the users and the developers to get maybe some answers to the many questions I have regarding this:
* Is there any plan to remove this restriction in the next version of code_aster (code_aster HPC?)
* Is there a work-around how we can improve performance for such cases even with the current version (V14.3)
* Does this limitation also apply to the LAC contact?
* Is there any performance test case using DYNA_NON_LINE + CONTACT? (I couldn't find one in codeaster-perf repository)
* How much would the implementation effort be for distributing the matrices correctly such that parallelism can be enable again?

I would highly appreciate any help regarding this.

Best,
Richard

#14 Re: Code_Aster usage » STAT_NON_LINE basic convergence question » 2019-05-16 15:24:31

Hello Markus,
there is no exact science behind choosing an appropriate NPREC value.
Usually the default (8) should be fine, if not, there is likely an issue that causes this.

You need to understand what this NPREC actually means. It is a value which is used to control at which point the linear solver should stop the solution as the loss of precision is too high. Simply speaking, a value of NPREC=8 means that we tolerate a loss of precision of up to 8 digits - (with usual double precision we still got 8 valid digits left). On the other hand the "loss of precision" is just an estimate and sometimes MUMPS over-estimates the lost precision, especially if you run the simulation on multiple parallel MPI threads.
So it might be acceptable to go up to NPREC=11 and still have a reasonable accuracy. That's also only a rule of thumb.

If your analysis still does not even converge with a high value, then maybe you should check why your simulation is that badly conditioned - maybe your input is inconsistent, the setup is just physically unstable, you have a bad mesh quality + a million of different other reasons why a nonlinear analysis might fail.

Again, without the complete case its all just speculation.

Best,
Richard

#15 Re: Code_Aster usage » STAT_NON_LINE basic convergence question » 2019-05-13 11:49:01

Hello Markus,
your settings look like you have severe issues with your model:

                       CONVERGENCE=_F(RESI_GLOB_MAXI=10,
                                      ARRET='NON',
                                      ITER_GLOB_MAXI=25,),
                       SOLVEUR=_F(METHODE='MUMPS',
                                  RENUM='METIS',
                                  NPREC=12,
                                  ELIM_LAGR='NON',
                                  STOP_SINGULIER='NON',),

I would say, with such loose convergence settings (RESI_GLOB_MAXI=10,  ARRET='NON', NPREC=12, STOP_SINGULIER='NON') that your solution is probably already quite unphysical once you observe the convergence not advancing any more.

In any case it is very hard and usually impossible to argue over reasons of such behavior without having the FULL case setup available (mesh + command file).

Best,
Richard

#16 Code_Aster usage » How to properly use IMPR_NOM_VARI? » 2019-05-06 09:59:40

RichardS
Replies: 0

Hi all,
it seems like I am still not able to successfully use IMPR_NOM_VARI and would like to get some clarification on it's usage.

My goal: Having a simulation with multiple material behaviors, I want to extract the equivalent plastic strain in a separate field.

As the V1 component of the internal variables can have many different meanings, depending on the material behavior, I thought using IMPR_NOM_VARI would be convenient as I would be sure to only export the correct field component, e.g. EPSPEQ.

Checking the documentation (https: //www.code-aster.org/V2/doc/v14/fr/man_u/u7/u7.05.21.pdf ), it seems like it would be a global parameter inside IMPR_RESU/FORMAT='MED', but looking at the code, it must be specified inside an RESU key word (and is on per default). So the Documentation needs an update here, or sth. changed after the version I am using here (V14.2.0 within SalomeMeca2018)

Then, the documentation states:
"Ce mot clé est utile dans le cas des variables internes. Lorsqu’il est utilisé et que l’impression d’un
champ VARI_* a été demandée, c’est en fait un champ VARI_*_NOMME qui sera imprimé. Ce champ
aura des composantes dont le nom sera basé sur le catalogue des lois de comportement utilisées
dans le calcul. Si deux lois de comportement ont des variables internes communes, celles-ci seront
fusionnées dans une unique composante."

So this leaves me to think that once I request a VARI_* field to be printed, what is actually printed is an equivalent VARI_*_NOMME field.
Trying this with a VARI_NOEU field, actually nothing is printed. I only get the usual VARI_NOEU components V1, V2, etc.

Also, when I try to explicitly ask for the printing of a VARI_NOEU_NOMME field to be able to actually only export the component NOM_CMP='EPSPEQ', it fails as there is no option to explicitly export this field type, even less the specific component.

The only way for me to print a VARI_*_NOMME field at all, is to use an VARI_ELGA field and but restrict the components of the obfuscated VARI names ("V1" here), but then I also have no chance of using a custom field name in the med file:

        _F(
            IMPR_NOM_VARI='OUI',
            NOM_CHAM='VARI_ELGA',
            #NOM_CHAM_MED='equivalent plastic strain',
            NOM_CMP=('V1'),
            RESULTAT=SIM,
            ),

Finally I would really love to know if there is any good workaround how I can achieve my goal of safely exporting only the EPSPEQ component of the VARI_NOEU field to a separate field with a custom name (like given by NOM_CHAM_MED)?

Best,
Richard

#17 Re: Code_Aster usage » Elastoplastic and anisotropic material behavior » 2019-05-03 09:47:16

Hi,
it is not possible in Code-Aster directly, but you can use the MFront coupling to include such a material behavior.

This thread might help you: https hmm/code-aster.org/forum2/viewtopic.php?id=21992

Best,
Richard

#18 Re: Code_Aster installation » Any plans to provide a "full-src" package for V14.3? » 2019-05-03 09:43:39

Hi,
maybe the release plan changed, but I think at least for the previous versions 13.3 and 12.3 there were also "full-src" packages available.

Just so we can adapt our processes: will there no more "full-src" packages be released or is there just a delay or special handling for the 14.3 one?

Best,
Richard

#19 Code_Aster installation » Any plans to provide a "full-src" package for V14.3? » 2019-03-27 14:11:28

RichardS
Replies: 2

Hi all,
are there any plans to release an aster-full-src package for the new minor version V14.3?
(I am referencing the ones presented here: https: //code-aster.org/V2/spip.php?article272 )

Best,
Richard

#20 Re: Code_Aster usage » May the coef. of heat exchange depend on temperature? » 2019-03-06 12:44:26

Hello kathi,

it is not possible to have a temperature dependent formula here for any of the parameters of an "ECHANGE" condition,
but you can easily, model the same condition with  a "FLUX_NL", a specific nonlinear heatflux condition which can take a temperature dependent formula as input.
You can just explicitly define the convection heat flux with a formula and assign it there.

Best,
Richard

#21 Re: Code_Aster usage » efficiency of code aster » 2019-02-08 08:46:32

Hi Assadi,
great that you find it helpful. Once you tried it, let me know about your experiences (you can also write me here a direct message)!

samasd wrote:

About the (We are hiring! simscale-jobs.personio.de/?language=en#all), did you accept people from France (Language French)?

For sure, we have a very international team from +20 different countries!

Best,
Richard

#22 Re: Code_Aster usage » efficiency of code aster » 2019-02-06 15:23:24

Hello @samasd,
one option to add, if you are mainly concerned about the initial learning curve and ease-of-use I could also recommend to try SimScale (simscale.com).

We have integrated a lot of the basic functionality of Code-Aster, including frictional contact into a very easy to use browser-based GUI (to my knowledge the easiest way to start with Code-Aster from all currently available alternatives) where you can use up to 16-core cloud computing instances in the free plan. As an academic, you might also apply for the academic plan to use up to 64-core instances and private projects.

Obviously we have only a subset of the total functionality of Code-Aster integrated, so if you want to get into more complex modelling approaches, 1D and 2D structural elements etc. you might then need to switch back to AsterStudy or "pure" code-aster.

Best,
Richard

[@mods please feel fee to remove this post if you think its rather advertisement than help]

#23 Re: Code_Aster usage » Code stops due to communication error » 2019-02-02 10:24:25

Anirudh wrote:

Hi,
However, the memory usage while CALC_CHAMP(for VonMises Stress) is still huge. For 36 time steps, it was 23 GB(13GB free RAM(total 16 GB) +11 GB Swap) in all. Is there no way to avoid this?

Sadly this is a known issue since a very long time, see for example this thread: https:// www. code-aster.org/forum2/viewtopic.php?id=19506
The only work-around to reduce total memory consumption in CALC_CHAMP is to stop the calculation after the main calculation step is finished (STAT/DYNA_NON_LINE for example) and restart with POURSUITE the calculation on only 1 MPI thread. The performance reduction in terms of total runtime is negligable for most cases in our experience - but the reduction in RAM and Disk usages are enormous.
My only hope is that this might be no issue any more with the new version 15 - "Code-Aster HPC" ;-)

Anirudh wrote:

I see messages in Xterm that lots of fields are stored in RAM for a converged step(like SIEF_ELGA, CONT_NOEU, COMPORTEMENT, VARI_ELGA, DEPL, ACCEL, VITE) etc. Is it possible to just store DEPL while calculating?

You can check the key-word CHAM_EXCLU of ARCHIVAGE within DYNA_NON_LINE - this should be able to do what you want.

Anirudh wrote:

Also, you mentioned about second level parallelism in Code_Aster. Do I activate it by ncpus parameter in ASTK? I thought OpenMP is valid only for 1 core and MULT_FRONT. If yes, will it increase RAM requirement?

This I 'll leave for the experts to answer. To my knowledge you can use either shared memory directly within the BLAS package - and this you don't need to specify this with ncpus, but compile the BLAS library accordingly, or you use a single threaded BLAS and enable shared memory via ncpus - but I might be wrong, so don't take my word for granted. There are also plenty of documentation pieces available about this.

Best,
Richard

#24 Re: Code_Aster usage » Information on all exit codes in Code_Aster » 2018-12-26 12:43:37

Yes,
that makes sense.

There is an option in never CA versions where you can force a time step subdivision in case the residual explodes, for example:

_F(EVENEMENT = 'RESI_MAXI', 
RESI_GLOB_MAXI = 1e5,
ACTION = 'DECOUPE',
SUBD_METHODE = 'MANUEL',
SUBD_NIVEAU = 2,
SUBD_PAS=2)

Best,
Richard

#25 Re: Code_Aster usage » Information on all exit codes in Code_Aster » 2018-12-25 21:24:16

Hi
Code-Aster uses the standard lunix/unix exit codes.
Standard exit code reference for bash: www. tldp.org/LDP/abs/html/exitcodes.html
You can find a good list of the related signals here: www. lifewire.com/signal-linux-command-4094016
So 136 = 136-128 = 8, which is SIGFPE, so floating point exception.
Not sure if thst tells you much, though.

Best,
Richard