<F>_CORE_FILE

Hallo,

habe bei einem Code-Aster Rechenlauf ziemlich am Ende folgende Meldung:

<F>_CORE_FILE

Worauf könnte das deuten? Komisch ist, dass die Basefiles (glob.1.gz wie pick.1.gz) wieder richtig klein sind. Während der Rechnung hatten diese Faktor 1000 von der Größe.

JDC.py : ERREUR A L'INTERPRETATION DANS ACCAS - INTERRUPTION
>> JDC.py : DEBUT RAPPORT
CR phase d'initialisation
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! <S> Exception utilisateur levee mais pas interceptee. !
! Les bases sont fermees. !
! Type de l'exception : error !
! !
! Erreur lors de l'allocation dynamique. Il n'a pas été possible d'allouer !
! une zone mémoire de longueur 6334 Mo, on dépasse la limite maximum !
! fixée à 7499 Mo et on occupe déjà 6404 Mo. !
! La dernière opération de libération mémoire a permis de récupérer 0 Mo. !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
fin CR phase d'initialisation

>> JDC.py : FIN RAPPORT
FIN EXECUTION
Fin interpreteur Python

---

mpirun has exited due to process rank 0 with PID 8773 on
node caelinux-HA-1861 exiting without calling "finalize". This may
have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).

---

EXIT_COMMAND_8723_00000015=1
<INFO> Code_Aster run ended, diagnostic : <S>_ERROR

<E>_CORE_FILE Code_Aster run created a coredump

<INFO> core file name : core

---

Coredump analysis

coredump analysis... [ OK ]
[New Thread 8793]
[New Thread 8896]
[New Thread 8894]
[New Thread 8895]

warning: Can't read pathname for load map: Eingabe-/Ausgabefehler.
Core was generated by `./asteru Python/Execution/E_SUPERV.py -eficas_path ./Python -commandes fort.1 -'.
Program terminated with signal 6, Aborted.
#0 0x00007f59a2656a75 in raise () from /lib/libc.so.6
#0 0x00007f59a2656a75 in raise () from /lib/libc.so.6
#1 0x00007f59a265a5c0 in abort () from /lib/libc.so.6
#2 0x00007f59a3c225de in _gfortran_abort () from /usr/lib/libgfortran.so.3
#3 0x000000000055e42f in jefini_ ()
#4 0x00000000005298e3 in u2mesg_ ()
#5 0x000000000053a0a5 in u2mess_ ()
#6 0x00000000005a18aa in hanfpe ()
#7 <signal handler called>
#8 0x0000000001f8b142 in dmmkerni1_ ()
Cannot access memory at address 0x1f9e508

---

Content of /tmp/firma-caelinux-HA-1861-interactif.8667-caelinux-HA-1861 after execution

.:
insgesamt 1340808
drwx

---

5 firma firma 4096 2012-02-27 17:45 .
drwxrwxrwt 23 root root 4096 2012-02-27 17:45 ..
-rw-r--r-- 1 firma firma 1255 2012-02-27 17:40 8667-caelinux-HA-1861.export
lrwxrwxrwx 1 firma firma 28 2012-02-27 17:40 asteru -> /opt/aster110/NEW11.0/asteru
-rw-r--r-- 1 firma firma 8077 2012-02-27 17:40 config.txt
-rw

---

1 firma firma 1497026560 2012-02-27 17:45 core
-rw-r--r-- 1 firma firma 11 2012-02-27 17:45 dbg_cmdfile
-rw-r--r-- 1 firma firma 18022408 2012-02-27 17:45 elem.1
-rw-r

---

1 firma firma 7356 2012-02-27 17:45 fort.1
-rw-r

---

1 firma firma 7356 2012-02-27 17:45 fort.1.1
-rw-r--r-- 1 firma firma 0 2012-02-27 17:45 fort.15
-rw-r--r-- 1 firma firma 18395321 2012-02-27 17:45 fort.19
-rw-r--r-- 1 firma firma 8183288 2012-02-27 17:45 fort.20
-rw-r--r-- 1 firma firma 71489 2012-02-27 17:45 fort.6
-rw-r--r-- 1 firma firma 21327 2012-02-27 17:45 fort.8
-rw-r--r-- 1 firma firma 722 2012-02-27 17:45 fort.9
-rw-r--r-- 1 firma firma 1678302 2012-02-27 17:45 fort.98
-rw-r--r-- 1 firma firma 3926482 2012-02-27 17:45 fort.99
-rw-r--r-- 1 firma firma 2457608 2012-02-27 17:45 glob.1
-rwxr-xr-x 1 firma firma 1663 2012-02-27 17:45 mpi_script.sh
drwxr-xr-x 22 firma firma 4096 2012-02-27 16:41 Python
drwxr-xr-x 2 firma firma 4096 2012-02-27 16:41 REPE_OUT
drwxr-xr-x 2 firma firma 4096 2012-02-27 16:41 RESU_ENSIGHT
-rw-r--r-- 1 firma firma 2457608 2012-02-27 17:45 vola.1

REPE_OUT:
insgesamt 8
drwxr-xr-x 2 firma firma 4096 2012-02-27 16:41 .
drwx

---

5 firma firma 4096 2012-02-27 17:45 ..

---

Size of bases

<INFO> size of vola.1 : 2457608 bytes
<INFO> size of glob.1 : 2457608 bytes

---

Copying results

copying .../fort.6... [ OK ]
copying .../fort.8... [ OK ]

<A>_COPYFILE no such file or directory: fort.80

compressing glob.1 [ OK ]
copying .../glob.1.gz... [ OK ]

<S>_ERROR Code_Aster run ended

---

cpu system cpu+sys elapsed

---

Preparation of environment 0.04 0.10 0.14 0.11
Copying datas 0.16 0.17 0.33 0.29
Code_Aster run 2801.79 105.83 2907.62 3830.63
Coredump analysis 0.28 0.06 0.34 3.68
Copying results 0.07 0.04 0.11 0.22

---

Total 2802.55 106.27 2908.82 3835.21

---

(*) cpu and system times are not correctly counted using mpirun.

as_run 1.10.0

---

--- DIAGNOSTIC JOB : <F>_CORE_FILE

---

EXIT_CODE=4

Gruß Markus

Hallo Markus,

du hast ein Speicherproblem. Aster beschwert sich, dass 6330 MB weiterer Speicher benötigt wird und bereits 6404 MB belegt sind,
was den maximal zugeordneten Speicher von 7499 MB übersteigen würde.

Falls du 12 oder 16 GB RM hast versuche den zugeordnenten Speicher für Code-Aster zu vergößern oder vergrößere deinen swap.


Grüße,
Richard

Hallo Richard,

danke für den Tipp. Ich habe in diesem Rechner 8GB RAM und 14,7GB swap - aktiv. Den swap zu vergrößern wird da schwierig, ich könnte im /tmp ein großes swap File zusätzlich anlegen, oder eine zusätzliche Platte mit Swappartition nutzen. Werde ich morgen gleich mal probieren. Wobei ich das Projekt mal auf einer anderen Maschine mit 32GB RAM und 100GB swap laufen lassen könnte.

Werde also mal probieren:
und dann eben mal:


Eine abschließende Frage habe ich noch. Wenn man große Modelle in Code-Aster rechnen will, muss man dann auch automatisch die Speicherdefinitionen inASTK erhöhen? Mit der max_base habe ich schon meine Erfahrungen gesammelt.

Gruß und Dank Markus

Hallo,

heute mal eine allgemeine Frage. Mit welchen Resourcen an swap, RAM usw. wird bei realen Code-Aster Modellen im produktiven Betrieb gearbeitet?

In meinen primär 2D Elemente Modell habe ich 70GB als "Total memory" im ASTK angebenen (wie auch in der asrun). Wie es scheint, reicht das immer noch nicht.

Derzeit sind 150GB in "Total memory" eingetragen (180GB in asrun). Davon sind jeweils 32GB RAM der Rest swap (200GB). Als Argument habe ich zusätzlich -max_base 700000 eingetragen.

Über Tipps und Infos würde ich mich freuen.

Gruß Markus

Hallo,

habe nach ca. 1 Woche Rechnlauf folgende Meldung:

Am Speicherbedarf kann es nach meiner Interpretation nun nicht mehr liegen. Ist das richtig? Auf was deutet dieser Abbruch hin?

Über Tipps und Infos würde ich mich freuen.


Gruß und Dank Markus