Warning CABLE: Error with code aster 16.7 but Running with code aster 15.6

PierluigiP29

Hi everyone,
I'm currently studying the book DYNAmics_with_code_aster by Jean Pierre Aubry and yesterday I encountered a problem in running the non linear dynamics problem explained in Chapter 10.
I'm using the Salome Meca 2024 container with code aster stable version 16.7 and the DYNA_NON_LINE procedure gives me this error:

Le TYPE_ELEMENT MECABL2 ne sait pas encore calculer l'option: RIGI_MECA

By having a look in some other forum threads I found that there are issues with cable modelizations in code aster 16 that do not appear in code aster 15 so I downloaded the Salome container 2022 with stable version 15.6.
The simulation is currently running while I'm writing this post.

This is just a warning more than a request, but I would be glad if someone could tell me if there is some place where it is possible to see what changed between different versions of the solver.
Otherwise it is a matter of luck if a simulation runs or not, and it gets frustrating if someone wants to make a real project come to life.

Thanks for your time,
Pier

jeanpierreaubry

PierluigiP29
hello

thanks for using my book

you do not give much in formation about where the error occurs

my own guess is that it is when trying to perform the modal analysis, the pure dynamics of the problem should run ok is not it ?

i reported this in:

https://forum.code-aster.org/public/d/21290-solved-modal-analysis-of-structure-with-cable-elements/4

this seems to be a voluntary move from the code_aster team
anyhow as i state in this post results of modal analysis with CABLE elements can be very tricky to understand and can be misleading

PierluigiP29

jeanpierreaubry

Hello,

First of all thank you for the fast reply and for writing such a useful and clear book full of very valuable material!

I'm attaching here the .comm and message files which give me the error mentioned earlier. As you can see I didn't even set up the modal analysis, it fails after the DYNA_NON_LINE command.

With code aster 15.6 (inside salome meca 2022 container) I managed to run this model, but for time issues I stopped it. It reached 13% of completion after 11h on a single core of my pc. In the book what did you mean with 'a few hours'? I also modified the adaptation criterium compared to the one specified in the book... that one reached 12% after 14h yesterday.

At the moment I'm trying to install a version of code aster MPI, for example this one:
https://github.com/emefff/Code-Aster-MPI-in-Singularity-of-SM2021
because I'd like to use at least 4 cores out of 8 that I have.
I hope I'll manage to make it work, it seems a pretty advanced procedure for my limited experience with building software and working with containers...

message.txt

100kB

runcase-1-stage-1.txt

13kB

jeanpierreaubry

PierluigiP29
sadly enough i must say that in encounter the same problem with version 17.2.2
so it seems to be a good idea to keep a 15 version at hand for such problems

maybe this type of analysis will be available again in a near future !!

regarding the calculation time in the example the time is set to very long value to show some features like "bouncing back"
i wrote "a few hours" without much precision as it depends a lot the komputer and the allocated memory on my previous desktop with 8GB RAM it took around 5h
but the higher stresses occur relatively early, around the shock instant, so it is not necessary to set as long a time as in the book

jeanpierreaubry

i made mistakes in my previous post

1- the .mess file shows an error in ASSEMBLAGE that is the first step of a modal analysis
this errors occurs in 16.5 and 17.2.2 which i tried out

2- once this modal analysis part is removed the DYNA_NON_LINE runs pretty well on the same 16.5 and 17.2.2 versions

PierluigiP29

Hello,

Thanks for the info, anyway it remains a mistery to me because I don't have the command ASSEMBLAGE in the model that I shared!

I'm also trying to understand why my run takes so long even using openMP and 4 cores on my machine...

I'll keep you updated when I find something, in the meantime I attach here the updated version that I managed to run until 0.024s

thank you

runcase-1-stage-1.txt

13kB

jeanpierreaubry

PierluigiP29
this command file runs well on my modest laptop in 160 s
maybe something is weird in the problem set up
post the .export file

jeanpierreaubry

looking at the file "message.txt you posted previously
i can see that you do not seem to use MPI at all

-- CODE_ASTER -- VERSION : DÉVELOPPEMENT STABILISÉE (testing) --                  

                               Version 16.7.0 modifiée le 10/12/2024                                

                               révision 5f2fdcddabc5 - branche 'HEAD'                               

                                   Copyright EDF R&D 1991 - 2026                                    
                                                                                                    

                          Exécution du : Tue May 19 22:54:16 2026                               
                                 Nom de la machine : PIER95                                     
                                    Architecture : 64bit                                        
                                Type de processeur : x86_64                                     
           Système d'exploitation : Linux-6.17.0-23-generic-x86_64-with-glibc2.31               
                              Langue des messages : fr (UTF-8)                                  
                                 Version de Python : 3.9.2                                      
                                 Version de NumPy : 1.19.5                                      
                                 Parallélisme MPI : inactif                                     
                                Parallélisme OpenMP : actif                                     
                          Nombre de processus OpenMP utilisés : 1                               
                           Version de la librairie HDF5 : 1.10.3                                
                            Version de la librairie MED : 4.1.1                                 
                           Version de la librairie MFront : 4.1.0                               
                           Version de la librairie MUMPS : 5.5.1c                               
                              Librairie PETSc : non disponible                                  
                           Version de la librairie SCOTCH : 7.0.1

Parallélisme MPI : inactif
seems to mean MPI is not used

Parallélisme OpenMP : actif
Nombre de processus OpenMP utilisés : 1
seems to mean you are using OpenMP wit only one processor

PierluigiP29

jeanpierreaubry
Yeah when I posted the first message I wasn't using openMP, then I found the option in the 'advanced' tab in Salome and I'm doing all the attempts with 4 cores as you can see from my previous answer.

Thanks for your time

PierluigiP29

Here it is, with the head and tail of the message file:

export.txt

562B

mess-parziale.txt

27kB

I also attach a picture of the convergence plot made from the mess file, even if I'm trying to change some solver and convergence options there seem to be always the same critical point highlighted:

Note that the real duration of the simulation is not present, it takes about 1:15h to reach 24ms and then there's a plateau. I stopped it after 8h.
Now I'm running it with smaller timestep and slightly different constraints, but it's slowing down at the same instants as before.

jeanpierreaubry

PierluigiP29
i can see you are using

listdr = DEFI_LIST_REEL(DEBUT=0.0,
                        INFO=1,
                        INTERVALLE=_F(JUSQU_A=0.024,
                                      PAS=0.0001))

PAS is somewhat larger than the book's example which uses

listdr = DEFI_LIST_REEL(DEBUT=0.0,
                        INFO=1,
                        INTERVALLE=_F(JUSQU_A=0.24,
                                      PAS=6.4e-05))

i state in the book in 10.1 that the time stepping has to be related to the element size to ensure a good solution

regarding MPI
i wonder whether such a small problem, as far as number of element is concerned, MPI is really usefull (i have heard of small problems where parallel computing was slower!)
while the iteration for the time stepping are purely sequential
solving at instant n depends entirely on solution at step n

anyhow i can read in the last message file you posted
Parallélisme MPI : inactif
you are not using MPI
but
Parallélisme OpenMP : actif
Nombre de processus utilisés : 4
which is a rather different story

PierluigiP29

Yes I understand, at this point there is a chance that it's a mesh problem because after 25ms the timestep remains between 0.5e-6 and 2e-6.
I used the exact .geo file in the book to generate it, but maybe I have some smaller elements than you.
I'll let you know, thanks for the tip

PS: I will not use MPI for this run because I had a hard time installing this version and also at the moment I'm not planning to use multi-node servers. For practicing with simple (but not too simple) models I think openMP will be enough.

PierluigiP29

I think I found my issue... But I'm still trying to understand why the same .geo gives different mesh sizes along the edges of the blocks:

As you can see I get about 24 edges around the circumference, instead in your model there are about 16.
There are a few elements with size below 3.5mm that make my timestep drop to 6.7e-7 as I saw from the output.

Anyway still remains the mistery of that error with the matrix RIGI_MECA in code aster 16.7. I hope who reads this thread will stick to the original issue now that we solved the other one 🙂