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

You are not logged in.

#1 2009-01-21 13:46:08

Vincent Magnenet
Member
From: IMFS - Illkirch
Registered: 2008-05-27
Posts: 64
Website

Pb installation de MUMPS 4.7.3 pour Aster 9.3

Bonjour,

Ce message rebondit sur un précédent topic :

http://www.code-aster.org/forum2/viewtopic.php?id=12468

et parle donc du problème des integer/integer*4 lors de la compilation de MUMPS.

Voilà mon problème: j'ai compilé MUMPS avec Intel Fortran 10.1 sur machine
Intel en suivant les indications du précédent topic (donc sans l'option -i8). Les cas tests de MUMPS
passent bien (1 2 3 4 5 Ok), ainsi qu'un deuxième cas-test un peu plus costaud (une matrice
500 000 x 500 000 avec une bande de 50 de large, voir le fichier dsimpletest_modifie.F
dans l'archive .zip ci-jointe). Ca marche. Dans mon config.txt pour Aster,
j'ai bien pris note qu'il fallait indiquer les headers de MUMPS modifiés par les
développeurs d'Aster, dans lesquels on remplace les integer initiaux en integer*4 pour
outrepasser l'option -i8 (cf. fichier config.txt joint). Pour bien être sûr de la manip,
j'ai même recompilé mes cas-test MUMPS avec l'option -i8 ET les headers de MUMPS modifiés,
et ça marche bien. La compilation d'Aster se fait également très bien (j'ai même tout reconstruit avec
as_run --make clean ; as_run --make    pour être sûr). Quand je lance Aster sur 4 noeuds (compression d'un cube
elastoplastique, on tourne sous Rocks 5.0, j'ai environ 560 000 equations et 12 millions
de termes non nuls dans ma matrice de raideur, donc ça doit passer d'après mon cas test),
tout se passe bien jusqu'au crash de STAT_NON_LINE :



INSTANT DE CALCUL :  2.000000000E+00

---------------------------------------------------------------------
|   ITERATIONS   |     RESIDU     |     RESIDU     |     OPTION     |
|     NEWTON     |     RELATIF    |     ABSOLU     |   ASSEMBLAGE   |
|                | RESI_GLOB_RELA | RESI_GLOB_MAXI |                |
---------------------------------------------------------------------
[compute-0-3:23855] *** Process received signal ***
[compute-0-2:26206] *** Process received signal ***
[compute-0-1:04142] *** Process received signal ***
[compute-0-3:23855] Signal: Segmentation fault (11)
[compute-0-3:23855] Signal code: Address not mapped (1)
[compute-0-3:23855] Failing at address: 0xf3
[compute-0-2:26206] Signal: Segmentation fault (11)
[compute-0-2:26206] Signal code: Address not mapped (1)
[compute-0-2:26206] Failing at address: 0xf3
[compute-0-1:04142] Signal: Segmentation fault (11)



Ce qui est étrange, c'est quand je compile MUMPS avec
l'option -i8 (donc avec les headers non modifiés), les cas tests sont abérrants
(comme dans le topic cité plus haut, chez moi la solution est quelque chose comme
20 13 9 etc... au lieu de 1 2 3 4 5 et le temps de calcul est anormalement rapide),
STAT_NON_LINE ne crashe plus... mais affiche des résidus abérrants qui croissent
vers l'infini (genre 1E1, 1E11, 1E23, etc....), ce qui est bien entendu normal.

J'ai essayé de recompiler les librairies nécessaires à MUMPS (scalapack
blacs et blas) avec l'option -i8 en me servant du script indiqué par les
développeurs de MUMPS:

http://www.netlib.org/scalapack/scalapack_installer.tgz

puis recompilé MUMPS avec ces versions, mais celà ne change rien
au problème.

Je me sens donc coincé : d'un côté MUMPS doit être compilé avec des integer*4
pour produire des résultats corrects, et d'un autre côté STAT_NON_LINE crashe
quand j'ai des integer*4 mais pas des integer*8.....

Quelqu'un a-t-il une piste à me proposer pour résoudre le problème ?
Désolé pour la longueur de mon message.

Cordialement.


Attachments:
fichiers.zip, Size: 5.05 KiB, Downloads: 577

"Avec suffisamment de paires d'yeux, tous les bugs feront surface."

                                                        Linus Torvalds.

Offline

#2 2009-01-23 10:23:05

Vincent Magnenet
Member
From: IMFS - Illkirch
Registered: 2008-05-27
Posts: 64
Website

Re: Pb installation de MUMPS 4.7.3 pour Aster 9.3

Personne n'a une petite piste à donner ?


"Avec suffisamment de paires d'yeux, tous les bugs feront surface."

                                                        Linus Torvalds.

Offline

#3 2009-01-23 10:51:06

Thomas DE SOZA
Guru
From: EDF
Registered: 2007-11-23
Posts: 3,066

Re: Pb installation de MUMPS 4.7.3 pour Aster 9.3

Bonjour,

Tout ceci est un peu compliqué mais ça devrait marcher. Pour bien se comprendre :

* Avez-vous une machine 64 bits avec un OS 64 bits et Aster compilé pour (c'est à dire avec entiers longs INTEGER*8 en fortran et donc une option du genre -i8 à la compilation ?)
==> si oui alors on continue, sinon MUMPS devrait marcher normalement (pas d'options de compils particulières) et vous n'avez pas besoin de prendre les includes modifiés.

* Comment avez-vous compilé MUMPS exactement (extrait du Makefile.inc) ? Il ne doit là encore pas y avoir d'options particulières. Evitez de mettre une option du type "-align sequence" au début.

* Côté Aster qui doit être compilé en -i8, vous devez donc pointer vers les includes modifiés (et uniquement ici, MUMPS lui a du être compilé normalement) correspondants à votre version. Si c'est exactement ce que vous avez fait et que ça plante il faut regarder si le même problème en dehors de Aster plante aussi en sortant la matrice dans un fichier et en le relisant avec un petit programme du même type que celui de test.
Si ça plante aussi c'est un problème MUMPS. Sinon alors il y a une autre option qui créée des problèmes.

TdS

Offline

#4 2009-01-23 12:12:38

Vincent Magnenet
Member
From: IMFS - Illkirch
Registered: 2008-05-27
Posts: 64
Website

Re: Pb installation de MUMPS 4.7.3 pour Aster 9.3

Bonjour,

Merci de votre réponse. L'OS est bien 64 bits :

laego_admin@cauchy: ~ $ file /bin/ls
/bin/ls: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

et j'ai bien mis -i8 à la compilation d'Aster (cf. config.txt ci-joint). J'ai bien compilé MUMPS sans l'option -i8 (cf. Makefile.inc
modifé) avec les headers non modifiés, puis Aster avec les headers modifiés. Le plantage est malheureusement toujours
là. J'ai ressayé en mettant juste les options suivantes dans le Makefile.inc de MUMPS

OPTF    = -O -nofor_main
OPTL    = -O -nofor_main
OPTC    = -O

mais j'ai toujours ce satané bug.

Le zip joint contient le config.txt et le premier Makefile.inc.

Cordialement


Attachments:
fichiers.zip, Size: 3.74 KiB, Downloads: 551

"Avec suffisamment de paires d'yeux, tous les bugs feront surface."

                                                        Linus Torvalds.

Offline

#5 2009-01-23 13:34:56

Thomas DE SOZA
Guru
From: EDF
Registered: 2007-11-23
Posts: 3,066

Re: Pb installation de MUMPS 4.7.3 pour Aster 9.3

Je ne vois pas ce qui pourrait clocher dans la config.
Est-ce que l'étude en question est la seule touchée ? Ou bien de manière générique il y a plantage en // dans MUMPS en segmentation fault ?

TdS

ps : joignez votre étude sinon pour voir si ça plante chez nous.

Offline

#6 2009-01-23 14:52:49

Vincent Magnenet
Member
From: IMFS - Illkirch
Registered: 2008-05-27
Posts: 64
Website

Re: Pb installation de MUMPS 4.7.3 pour Aster 9.3

j'ai une autre étude (je crois que c'est du THM, je ne suis
pas l'auteur du .comm qui est bourré de macros python appelant des STAT_NON_LINE
avec des listes de COMP_INCR....)
pour laquelle la sparse matrice est de taille 413 000 x 413 000
et 15 000 000 environ de termes non nuls, et STAT_NON_LINE a l'air de démarrer correctement sur 4
noeuds. Il faudrait que je lance le calcul dans un screen pour le week end pour voir si ça va jusqu'au
bout.

Revenons au cube elastoplastique. Est-il possible que vous essayiez chez vous cette etude :

http://vincentmagnenet.free.fr/autres/etude_aster.zip

?  la somme md5sum (paranoia oblige ;-)) :      99168be00397158ba532989ff7f7a697

Chez moi le maillage piece_2.msh passe  mais pas le piece_3.msh qui est plus gros.

Ca serait sympathique de votre part.


"Avec suffisamment de paires d'yeux, tous les bugs feront surface."

                                                        Linus Torvalds.

Offline

#7 2009-01-23 17:43:10

Thomas DE SOZA
Guru
From: EDF
Registered: 2007-11-23
Posts: 3,066

Re: Pb installation de MUMPS 4.7.3 pour Aster 9.3

Il semblerait que cela marche ici. Cf output joint. Quelle est votre version d'Aster ? Combien de mémoire avez-vous par noeud ?


Attachments:
output_4p.txt, Size: 28.81 KiB, Downloads: 620

Offline

#8 2009-01-26 08:22:31

Vincent Magnenet
Member
From: IMFS - Illkirch
Registered: 2008-05-27
Posts: 64
Website

Re: Pb installation de MUMPS 4.7.3 pour Aster 9.3

Le calcul THM lancé ce week end a également planté avec des messages d'erreurs similaires.

Notre version est la STA9.3. On a 16 Go de RAM par noeud, comme pour le maitre.
Je vais peut être essayer une STA9.4, pour voir si celà change quelque chose....
(a priori c'est la même version de MUMPS).

Merci d'avoir fait tourner notre étude chez vous.

Cordialement.


"Avec suffisamment de paires d'yeux, tous les bugs feront surface."

                                                        Linus Torvalds.

Offline

#9 2009-01-26 18:23:56

Vincent Magnenet
Member
From: IMFS - Illkirch
Registered: 2008-05-27
Posts: 64
Website

Re: Pb installation de MUMPS 4.7.3 pour Aster 9.3

Bonsoir,

La suite : j'ai tout recompilé avec les compilateurs mpicc, mpif77, mpif90 à la place
de icc, ifort. Cette fois ci j'ai le backtrace lors du plantage (je ne vous mets
que les messages d'un seul noeud, les autres sont identiques):

-------------------------
INSTANT DE CALCUL :  2.000000000E+00

---------------------------------------------------------------------
|   ITERATIONS   |     RESIDU     |     RESIDU     |     OPTION     |
|     NEWTON     |     RELATIF    |     ABSOLU     |   ASSEMBLAGE   |
|                | RESI_GLOB_RELA | RESI_GLOB_MAXI |                |
---------------------------------------------------------------------
[compute-0-2:14715] *** Process received signal ***
[compute-0-2:14715] Signal: Segmentation fault (11)
[compute-0-2:14715] Signal code: Address not mapped (1)
[compute-0-2:14715] Failing at address: 0xf3
[compute-0-2:14715] [ 0] /lib64/libpthread.so.0 [0x3fa560de70]
[compute-0-2:14715] [ 1] /share/apps/local/openmpi_intel/lib/libmpi.so.0(MPI_Comm_size+0x65) [0x2aaaab06e8b9]
[compute-0-2:14715] [ 2] ./asterd(Cblacs_pinfo+0x9d) [0x1d4bbb5]
[compute-0-2:14715] [ 3] ./asterd(blacs_gridmap_+0x56) [0x1d47e7a]
[compute-0-2:14715] [ 4] ./asterd(blacs_gridinit__+0xa3) [0x1d47deb]
[compute-0-2:14715] [ 5] ./asterd(dmumps_164_+0x2c1) [0x1a62631]
[compute-0-2:14715] [ 6] ./asterd(dmumps_26_+0xadb2) [0x1a4abe6]
[compute-0-2:14715] [ 7] ./asterd(dmumps_+0xb54) [0x19b1512]
[compute-0-2:14715] [ 8] ./asterd(amumpr_+0x383f) [0x130209b]
[compute-0-2:14715] [ 9] ./asterd(amumps_+0x1266) [0x9e09be]
[compute-0-2:14715] [10] ./asterd(preres_+0x11d6) [0x58c61a]
[compute-0-2:14715] [11] ./asterd(nmmatr_+0x1bb8) [0x5ea5e0]
[compute-0-2:14715] [12] ./asterd(nmprta_+0xaaf) [0x70fb0b]
[compute-0-2:14715] [13] ./asterd(nmpred_+0x3aa) [0x5da0d6]
[compute-0-2:14715] [14] ./asterd(op0070_+0x1677) [0x4dedbf]
[compute-0-2:14715] [15] ./asterd(ex0000_+0x51b) [0x4b6da7]
[compute-0-2:14715] [16] ./asterd(execop_+0x225) [0x4936e5]
[compute-0-2:14715] [17] ./asterd(expass_+0xda) [0x491e66]
[compute-0-2:14715] [18] ./asterd [0x46e9e1]
[compute-0-2:14715] [19] /usr/lib64/libpython2.4.so.1.0(PyEval_EvalFrame+0x49fa) [0x3fa5a949da]
[compute-0-2:14715] [20] /usr/lib64/libpython2.4.so.1.0(PyEval_EvalFrame+0x44a6) [0x3fa5a94486]
[compute-0-2:14715] [21] /usr/lib64/libpython2.4.so.1.0(PyEval_EvalFrame+0x44a6) [0x3fa5a94486]
[compute-0-2:14715] [22] /usr/lib64/libpython2.4.so.1.0(PyEval_EvalFrame+0x44a6) [0x3fa5a94486]
[compute-0-2:14715] [23] /usr/lib64/libpython2.4.so.1.0(PyEval_EvalFrame+0x44a6) [0x3fa5a94486]
[compute-0-2:14715] [24] /usr/lib64/libpython2.4.so.1.0(PyEval_EvalFrame+0x44a6) [0x3fa5a94486]
[compute-0-2:14715] [25] /usr/lib64/libpython2.4.so.1.0(PyEval_EvalFrame+0x44a6) [0x3fa5a94486]
[compute-0-2:14715] [26] /usr/lib64/libpython2.4.so.1.0(PyEval_EvalFrame+0x44a6) [0x3fa5a94486]
[compute-0-2:14715] [27] /usr/lib64/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x925) [0x3fa5a95905]
[compute-0-2:14715] [28] /usr/lib64/libpython2.4.so.1.0(PyEval_EvalCode+0x32) [0x3fa5a95952]
[compute-0-2:14715] [29] /usr/lib64/libpython2.4.so.1.0 [0x3fa5ab1ea9]
------------------------

Le problème semble provenir de l'appel à la fonction BLACS_GRIDINIT. J'ai cherché en vain sur internet, mais je n'ai
rien trouvé, à part des infos sur les makefile de blacs. Avez-vous déjà rencontré ce problème ?

Cordialement


"Avec suffisamment de paires d'yeux, tous les bugs feront surface."

                                                        Linus Torvalds.

Offline

#10 2009-01-26 21:25:08

miko
Member
Registered: 2008-09-21
Posts: 114

Re: Pb installation de MUMPS 4.7.3 pour Aster 9.3

Vincent Magnenet wrote:

Bonsoir,



Le problème semble provenir de l'appel à la fonction BLACS_GRIDINIT. J'ai cherché en vain sur internet, mais je n'ai
rien trouvé, à part des infos sur les makefile de blacs. Avez-vous déjà rencontré ce problème ?

Cordialement

Bonsoir Vincent,

Quel chantier cette version parallèle 64 bits ....

Je ne sais pas si cela vous aidera, je vous donne ci-après les grandes lignes de la démarche que j'ai suivie pour construire une version parallèle 64 bits. Tous les cas-tests mumps sont OK, y compris votre étude (petit maillage), objet de votre post.

N'étant pas un développeur, mais plutôt un peu mécanicien, ma demarche parraitrait peut-être archaique aux yeux des spécilalistes,
mais toute remarque sera la bienvenue.

1) Matériel
Serveur bi-xeon 3.2 GH, 16 go de ram + Debian etch 64 bits

2) Installation des compilateurs et de MKL Intel  (compilos 10.1.015, mkl 10.0.3.020)

3) Construction de  MPI "maison" à l'aide des compilos Intel, ( MPI = mpich2-1.0.8.tar.gz)
    passer les options suivantes au ../configure.

( ../configure --prefix=/opt/mpich_ifort CC=/opt/intel/cce/10.1.015/bin/icc CXX=/opt/intel/cce/10.1.015/bin/icpc F77=/opt/intel/fce/10.1.015/bin/ifort F90=/opt/intel/fce/10.1.015/bin/ifort --enable-mpe --enable-cxx --enable-f77 --enable-f90 --enable-sharedlibs=gcc)

Ceci produit les wrappers "maison" mpicc, mpif90 etc...

4) Compiler  MUMPS à l'aide de ces wrappers "maison",  (j'ai essayé le MUMPS_4.8.4 dans /opt/mumps/MUMPS_4.8.4)

L'extrait du Makefile.inc

#End orderings
################################################################################
PLAT    =
RM = /bin/rm -f
CC = /opt/mpich_ifort/bin/mpicc
FC = /opt/mpich_ifort/bin/mpif90
FL = /opt/mpich_ifort/bin/mpif90
AR = ar vr
RANLIB = ranlib
#RANLIB  = echo
#
SCALAP  = /opt/intel/mkl/10.0.3.020/lib/em64t/libmkl_scalapack_ilp64.a /opt/intel/mkl/10.0.3.020/lib/em64t/libmkl_blacs_ilp64.a
INCPAR  = -I/opt/mpich_ifort/include
#
LIBPAR = $(SCALAP)  -L/opt/mpich_ifort/lib/  -lmpich
#
INCSEQ = -I$(topdir)/libseq
LIBSEQ = -L$(topdir)/libseq -lmpiseq
#
LBLAS1 = /opt/intel/mkl/10.0.3.020/lib/em64t/libmkl_lapack.a /opt/intel/mkl/10.0.3.020/lib/em64t/libmkl_em64t.a
LBLAS2 = /opt/intel/mkl/10.0.3.020/lib/em64t/libguide.a
LIBBLAS = $(LBLAS1) $(LBLAS2)
LIBOTHERS = -L/opt/intel/fce/10.1.015/lib/ -limf #-L/lib/ -lpthread
#
#Preprocessor defs for calling Fortran from C (-DAdd_ or -DAdd__ or -DUPPER)
CDEFS   = -DAdd_
#
#Begin Optimized options #
#
OPTF    = -O2 -IPF_fp_speculationsafe -unroll0 -Dintel_ -DALLOW_NON_INIT -nofor_main -align sequence
OPTC    = -O2 -I. -traceback -DLINUX64
OPTL    = -O2 -nofor_main
#
#End Optimized options
INC = $(INCPAR)
LIB = $(LIBPAR)
LIBSEQNEEDED =
#####################################################################################

J'ai aussi utilisé scotch_5.0, mais je crois que ce n'est pas obligatoire.
Ci-dessous les librairies utilisées, (production "maison").

LSCOTCHDIR = /opt/scotch/scotch_5.0_esmumps/lib
LSCOTCH   = -L$(LSCOTCHDIR) -lesmumps -lfax -lsymbol -ldof -lorder -lgraph -lscotch -lscotcherr -lcommon

Tester le MUMPS

Démarrer MPI en lançant  mpd &;
Lancer les divers tests, (rep. examples)  à l'aide de mpiexec ou mpirun "maison", ne pas oublier de tester aussi le c_example...
Si tous les tests sont OK, on prépare les includes de ce MUMPS pour les utiliser avec ASTER.

- Copier le répertoire include dans include_32
- Dans le répertoire include_32, remplacer tous les INTEGER par INTEGER*4, sauf ceux qui sont des INTEGER*8
  (simple observation des includes MUMPS dans ASTER)

5) Recompiler ASTER existant, à l'aide des wrappers "maison", en modifiant le fichier config.txt

L'extrait du fichier config.txt dans [ASTER_ROOT]/STA9.4_mpi

# ************************************************************************************************************************************************************************
ENV_SH         | env     | -     | profile.sh
#
LIB            | ar      | ?     | /usr/bin/ar -rv
#
BIBL           | python  | 2.5   | -L/usr/lib -L/usr/lib/python2.4/config -lpython2.4
BIBL           | med     | 2.3.5 | /opt/aster/public/med-2.3.5/lib/libmed.a
BIBL           | hdf5    | 1.6.5 | /opt/aster/public/hdf5-1.6.5/lib/libhdf5.a
BIBL           | zmat    | 8.4   |
BIBL           | mumps   | 4.8.4 | /opt/mumps/MUMPS_4.8.4/lib/libdmumps.a /opt/mumps/MUMPS_4.8.4/lib/libzmumps.a /opt/mumps/MUMPS_4.8.4/lib/libmumps_common.a /opt/mumps/MUMPS_4.8.4/lib/libpord.a
BIBL           | scotch  | 4.0   | /opt/aster/public/scotch_4.0/bin/libcommon.a /opt/aster/public/scotch_4.0/bin/libscotch.a /opt/aster/public/scotch_4.0/bin/libscotcherr.a /opt/aster/public/scotch_4.0/bin/libscotcherrcom.a
BIBL           | math    | ?     | /opt/intel/mkl/10.0.3.020/lib/em64t/libmkl_scalapack_ilp64.a /opt/intel/mkl/10.0.3.020/lib/em64t/libmkl_blacs_ilp64.a
BIBL           | math    | ?     | /opt/intel/mkl/10.0.3.020/lib/em64t/libmkl_lapack.a /opt/intel/mkl/10.0.3.020/lib/em64t/libmkl_em64t.a
BIBL           | mpi     | 2     | -L/opt/mpich_ifort/lib/ -lmpich
BIBL           | scotch  | 5.0   | -L/opt/scotch/scotch_5.0_esmumps/lib -lesmumps -lfax -lsymbol -ldof -lorder -lgraph -lscotch -lscotcherr -lcommon
BIBL           | c++     | ?     | -L/usr/lib/gcc/x86_64-linux-gnu/4.1.2 -lstdc++ -lsupc++
BIBL           | sys     | ?     | -Wl,--allow-multiple-definition -Wl,--export-dynamic -lieee -ldl -lutil -lm -L/usr/lib -lpthread -L/usr/lib -lz /opt/intel/mkl/10.0.3.020/lib/em64t/libguide.a -L/usr/lib -lpthread
DEFS           | defined | ?     | LINUX64 _USE_INTEL_IFORT _USE_MPI _USE_MPI_MUMPS _DISABLE_MATHLIB_FPE _HAVE_MUMPS
NOBUILD        | option  | ?     |
#
PYTHON         | python  | 2.3   | /usr/bin/python
#
LINK           | link    | ?     | /opt/mpich_ifort/bin/mpif90
OPTL           | link    | ?     | -nofor_main
#
CC             | cc      | ?     | /opt/mpich_ifort/bin/mpicc
OPTC_D         | cc      | ?     | -c -g -O3 -traceback 
OPTC_O         | cc      | ?     | -c -O3 -traceback
INCL           | include | ?     | -I/opt/aster/STA9.4_mpi/bibc/include -I/usr/include/python2.4 -I/opt/aster/public/hdf5-1.6.4/include -I/opt/aster/public/scotch_4.0/bin
INCL           | include | ?     | -I/opt/mpich_ifort/include
#
F77            | f77     | ?     | /opt/mpich_ifort/bin/mpif90
OPTF_D         | f77     | ?     | -c -g -O3  -i8 -r8 -fpe0 -traceback -align sequence
OPTF_O         | f77     | ?     | -c -O3  -i8 -r8 -fpe0 -traceback -align sequence
INCLF          | include | ?     |
#
F90            | f90     | ?     | /opt/mpich_ifort/bin/mpif90
OPTF90_D       | f90     | ?     | -c -g -O3 -i8 -r8 -fpe0 -traceback -align sequence -D_USE_INTEL_IFORT -D_HAVE_MUMPS
OPTF90_O       | f90     | ?     | -c -O3 -i8 -r8 -fpe0 -traceback -align sequence -D_USE_INTEL_IFORT -D_HAVE_MUMPS
#
INCLF90        | include | ?     |-I/opt/mumps/MUMPS_4.8.4/include_32
# *******************************************************************************************************************************************************************************

   et en utilisant as_run, par exemple, depuis [ASTER_ROOT]/STA9.4_mpi, lancer

  ../outils/as_run  --version_dev=STA9.4_mpi   --make clean
  ../outils/as_run  --version_dev=STA9.4_mpi   --make

6) Adapter fichier config pour pouvoir lancer la version parallèle depuis ASTK

L'extrait du fichier config dans [ASTER_ROOT]/ASTK/ASTK_SERV/conf/

# ----- MPI commands and parameters
# mpirun, ?MPIRUN?
#    available arguments are : mpi_hostfile, mpi_nbnoeud, mpi_nbcpu, wrkdir
#   (use Python string formatting style)

mpirun_cmd : /opt/mpich_ifort/bin/mpirun -machinefile %(mpi_hostfile)s -wdir %(wrkdir)s -np %(mpi_nbcpu)s  %(program)s

#   file which contains list of hosts
mpi_hostfile : /home/miko/machfile
#
# shell command to get processor id

mpi_get_procid_cmd : echo $PMI_RANK
# maximum number of nodes
mpi_nbnoeudmax : 1
mpi_nbcpumax : 4
#-------------------------------------------------------------------------------

Bonne chance,

Miko

Offline

#11 2009-01-27 07:31:02

Vincent Magnenet
Member
From: IMFS - Illkirch
Registered: 2008-05-27
Posts: 64
Website

Re: Pb installation de MUMPS 4.7.3 pour Aster 9.3

Merci pour cette réponse complète !

J'ai vu 2 fois sur internet que les gens qui utilisent Mpich n'ont pas le problème
de BLACS_GRIDINIT, vous êtes donc la troisième personne qui va dans ce
sens. Je vais essayer avec Mpich plutôt qu'OpenMPI....

Je vous tiens au courant.
Merci encore.


"Avec suffisamment de paires d'yeux, tous les bugs feront surface."

                                                        Linus Torvalds.

Offline

#12 2009-01-27 11:34:26

miko
Member
Registered: 2008-09-21
Posts: 114

Re: Pb installation de MUMPS 4.7.3 pour Aster 9.3

Vincent Magnenet wrote:

J'ai vu 2 fois sur internet que les gens qui utilisent Mpich n'ont pas le problème
de BLACS_GRIDINIT

Bonjour,

J'avais aussi ce problème, même avec le Mpich, le MUMPS étant
compilé avec le METIS. J'ai vu dans les messages en interactif et INFO=2
que ça pourrait être lié à METIS. Tous les cas-test mumps passent sans problème,
par contre, le problème survenait en STAT_NON_LIN et un maillage plus conséquent. 
Du coup, j'ai supprimé le METIS dans la section Ordering, (cf. extrait de Makefile.inc)
et là, ça passe, y compris votre étude avec maillage "piece_3.mesh"
(avec tout de même un arrêt par manque de temps cpu au bout de 10 heures, à l'instant 3 !! et
au prix de 16 Go de ram et ~ 15 Go de swap sur ma machine)

Je crois avoir encore un problème avec threading et MKL, car dans le suivi interactif,
chaque cpu affiche son message ??.
MKL_SERIAL=YES, dans aster_profile.sh ne semble pas influencer le comportement.

Un avis éclairé serait apprécié !

Miko

PS
L'extrait du fichier Makefile.inc

#          Metis is now available as an internal ordering for MUMPS.
#

LSCOTCHDIR = /opt/scotch/scotch_5.0_esmumps/lib
LSCOTCH   = -L$(LSCOTCHDIR) -lesmumps -lfax -lsymbol -ldof -lorder -lgraph -lscotch -lscotcherr -lcommon

LPORDDIR = $(topdir)/PORD/lib/
IPORD    = -I$(topdir)/PORD/include/
LPORD    = -L$(LPORDDIR) -lpord

#LMETISDIR = /opt/metis/metis-4.0
#IMETIS    = # Metis doesn't need include files (Fortran interface avail.)
#LMETIS    = -L$(LMETISDIR) -lmetis

# The following variables will be used in the compilation process.
ORDERINGSF = -Dscotch -Dpord
#ORDERINGSF  = -Dpord -Dmetis
ORDERINGSC  = $(ORDERINGSF)
LORDERINGS = $(LMETIS) $(LPORD) $(LSCOTCH)
IORDERINGS = $(IMETIS) $(IPORD) $(ISCOTCH)

#End orderings

Offline

#13 2009-01-27 18:26:06

Vincent Magnenet
Member
From: IMFS - Illkirch
Registered: 2008-05-27
Posts: 64
Website

Re: Pb installation de MUMPS 4.7.3 pour Aster 9.3

Bonsoir,

Malheureusement j'ai eu le problème en compilant MUMPS sans Metis......,
depuis le début. C'est bizarre !

Pour votre problème d'affichage, j'ai le même sur mon cluster. De mémoire,
le fait d'indiquer MKL_SERIAL=YES permet d'activer ou nom le parallélisme
des librairies Blas de bas niveau (à confirmer par les développeurs d'Aster).
Par conséquent, celà me semble découplé
de l'aspect "multithread". Il faut sûrement jouer sur l'édition de lien avec -lpthread
mais j'avoue mon ignorance.... (j'aimerais en être déjà là ! )

Cordialement


"Avec suffisamment de paires d'yeux, tous les bugs feront surface."

                                                        Linus Torvalds.

Offline

#14 2009-01-28 09:18:16

mathieu.courtois
Administrator
From: France
Registered: 2007-11-21
Posts: 1,171

Re: Pb installation de MUMPS 4.7.3 pour Aster 9.3

miko wrote:

Je crois avoir encore un problème avec threading et MKL, car dans le suivi interactif,
chaque cpu affiche son message ??.
MKL_SERIAL=YES, dans aster_profile.sh ne semble pas influencer le comportement.

Un avis éclairé serait apprécié !

Pour reprendre une expression de la discussion, la version mpi est un vrai chantier au sens premier du terme.
Autant les versions séquentielles se compilent bien y compris en 64 bits (sauf config bizarres), autant pour la version mpi, çà reste manuel.
Pour info, mumps tout seul peut aussi poser des problèmes sur certaines machines où on ne parvient pas à lancer de gros cas : pb implémentation mpi ? mumps ? en chantier donc !!!

Déjà, j'ai l'impression que le lancement avec as_run fonctionne correctement. Quels tests avez-vous fait ? combien de processeurs / noeuds ?

Pour en revenir à la dernière question : l'affichage cumulé de tous les procs : c'est prévu qu'on travaille dessus mais pas franchement prioritaire :
- il faut faire des choix et pour cela avoir un recul suffisant
- certaines implémentations de mpirun/prun... permettent d'afficher le numéro de procs en début de ligne, on peut donc facilement filtrer ensuite si nécessaire
- ce n'est pas lié à MKL_SERIAL.


MKL_SERIAL=YES comme l'a très justement expliqué Vincent M. permet de désactiver le parallélisme par threads des routines blas/lapack de MKL.
Dans certains cas, c'est souhaitable : si on utilise le solveur d'aster MULT_FRONT (parallélisé openMP) par exemple sur 4 procs et qu'en dessous les MKL sont aussi dispatchées sur 4 procs, on se retrouve avec 16 threads. Plus que le nombre de threads, c'est peut-être la taille des vecteurs qui devient trop petite pour gagner significativement.
Sur notre machine principale, sur les tests effectués, il fallait mieux désactiver le parallélisme des blas. A vérifier sur votre machine.

MC


Code_Aster release : last unstable on Ubuntu 16.04 64 bits - GNU Compilers

Please do not forget to tag your first post as *SOLVED* when it is!

Offline

#15 2009-01-30 10:53:54

miko
Member
Registered: 2008-09-21
Posts: 114

Re: Pb installation de MUMPS 4.7.3 pour Aster 9.3

courtois wrote:

.

Déjà, j'ai l'impression que le lancement avec as_run fonctionne correctement. Quels tests avez-vous fait ? combien de processeurs / noeuds ?

MC

Bonjour, et merci pour votre réponse.

Dernièrement j'ai fait les tests mumps01 à 05 + compression d'un cube
elastoplastique soumis par Vincent Magnenet, petit et gros maillage, sur
un serveur, 2 processeurs xeon 3.2 GH, 16 GO de mémoire, 1 noeud.
(serveur HP, ML 370 G4)

Mais je reviens un peu en arrière concernant la compilation du MUMPS.

EDIT:
J'avais cru résoudre un problème en supprimant le METIS dans la section
ORDERINGS du Makefile.inc du MUMPS (cf. post précédent)

Ceci permettait de passer le test soumis par Vincent, mais aussi les
tests mumps01 à 04 (petits), fausse joie...

En essayent de nouveau passer le test mumps05 (gros), ça plantait
au même endroit que pour le test de Vincent, extrait du log ci-sessous.


Pour cas test mumps05a (Ordering based on PORD)

DMUMPS
L D L^T Solver for general symmetric matrices
Type of parallelism: Working host

****** ANALYSIS STEP ********


DMUMPS
L D L^T Solver for general symmetric matrices
Type of parallelism: Working host

****** ANALYSIS STEP ********


****** Preprocessing of original matrix

Compute maximum matching (Maximum Transversal):  5
... JOB =  5: MAXIMIZE PRODUCT DIAGONAL AND SCALE
... Column permutation not used
Density: NBdense, Average, Median   =    0   75   80
Ordering based on PORD
** Peak of sequential stack size (number of real entries)   : 85267836.
A root of estimated size         2037  has been selected for Scalapack.
BLACS ERROR 'Illegal grid (1 x 2), #procs=1'
from {-1,-1}, pnum=0, Contxt=-1, on line -1 of file 'BLACS_GRIDINIT/BLACS_GRIDMAP'.

BLACS ERROR 'Illegal grid (1 x 2), #procs=1'
from {-1,-1}, pnum=0, Contxt=-1, on line -1 of file 'BLACS_GRIDINIT/BLACS_GRIDMAP'.


Et le cube élastoplastique de Vincent (Ordering based on METIS )



DMUMPS
L D L^T Solver for general symmetric matrices
Type of parallelism: Working host

****** ANALYSIS STEP ********

** Max-trans not allowed because matrix is distributed

DMUMPS
L D L^T Solver for general symmetric matrices
Type of parallelism: Working host

****** ANALYSIS STEP ********

Density: NBdense, Average, Median   =    0   38   41
Ordering based on METIS
** Peak of sequential stack size (number of real entries)   :  8796777.
A root of estimated size         2466  has been selected for Scalapack.
BLACS ERROR 'Illegal grid (1 x 3), #procs=1'
from {-1,-1}, pnum=0, Contxt=-1, on line -1 of file 'BLACS_GRIDINIT/BLACS_GRIDMAP'.

BLACS ERROR 'Illegal grid (1 x 3), #procs=1'
from {-1,-1}, pnum=0, Contxt=-1, on line -1 of file 'BLACS_GRIDINIT/BLACS_GRIDMAP'.

BLACS ERROR 'Illegal grid (1 x 3), #procs=1'
from {-1,-1}, pnum=0, Contxt=-1, on line -1 of file 'BLACS_GRIDINIT/BLACS_GRIDMAP'.

Donc marche arrière, je reconstruis de nouveau le MUMPS avec METIS...

Et pour que le cas test mums05 passe rien à faire, RENUM='METIS'
imposé dans le fichier de commande.

Pour que le cas test cube passe, ajout au fichier de commande RENUM='PORD' ci-dessous.

SOLVEUR=_F(METHODE='MUMPS',
          RENUM='PORD',
          PCENT_PIVOT = 100,
          PARALLELISME='DISTRIBUE_MD',
         PARTITION=SDFETI,
         ),
        );

Concernant le  double affichage et MKL, me voila rassuré..

Merci encore,

Miko

Last edited by miko (2009-01-30 23:12:51)


Attachments:
Capture_2_.png, Size: 156.81 KiB, Downloads: 317

Offline

#16 2009-01-30 21:46:45

mathieu.courtois
Administrator
From: France
Registered: 2007-11-21
Posts: 1,171

Re: Pb installation de MUMPS 4.7.3 pour Aster 9.3

Donc avec RENUM='METIS', çà plante : bonne nouvelle !!!

1. Dans aster, sur les plates-formes 64 bits, on utilise des entiers sur 8 octets (64 bits) pour pouvoir manipuler des entiers supérieurs à 2.10^9 (limite sur 3 octets/32 bits, 2^31 - 1).
Pour le solveur direct inclus dans aster (MULT_FRONT), on utilise metis pour la renumérotation. Et pour traiter de gros problèmes, on a modifié metis (package metis-edf-XXX) pour qu'il utilise aussi des entiers longs.

2. mumps utilise aussi metis pour renuméroter les inconnues. Mais mumps manipule des entiers courts (sur 4 octets) et doit donc être linké avec la librairie standard de metis (Site meits sur la page outils).

Donc en compilant une version standard de metis pour mumps, on peut espérer que çà fonctionne mieux.

A suivre...


Code_Aster release : last unstable on Ubuntu 16.04 64 bits - GNU Compilers

Please do not forget to tag your first post as *SOLVED* when it is!

Offline

#17 2009-01-31 18:42:03

Vincent Magnenet
Member
From: IMFS - Illkirch
Registered: 2008-05-27
Posts: 64
Website

Re: Pb installation de MUMPS 4.7.3 pour Aster 9.3

Bonsoir,

Pour information, le problème rencontré par miko est bien "conforme" ( ;-) )
à ce que m'avait dit les développeurs de MUMPS, cf. correspondance électronique:

---------------------------------
Bonjour,

Cela ressemble à un problème d'installation de la librairie
BLACS. C'est arrivé à pas mal d'utilisateurs dans le passé,
et un crash à ce niveau là dans MUMPS provenait à chaque fois
d'un problème lors de l'appel à BLACS_GRIDINIT (de la librairie
BLACS).

Pour l'installation de BLACS et ScaLAPACK, on vous
conseille d'utiliser le script Python disponible
à partir du lien:

http://www.netlib.org/scalapack/scalapack_installer.tgz

Cordialement,


Vincent Magnenet wrote:
> Bonjour,
>
> Je vous ai contacté il y a quelque temps à propos de
> Code_Aster/MUMPS (j'en profite pour vous remercier
> de votre réponse).
>
> En accord avec vos remarques, j'essaie de tester Code_Aster
> sur un problème plus gros pour analyser le speed-up de MUMPS.
> J'ai alors un crash sévère lors de l'appel à MUMPS.
> J'ai modifié le programme dsimpletest de la distribution MUMPS 4.7.3
> (cf. pièce jointe) qui reproduit le bug. Je vous joins la sortie
> de MUMPS. Avez-vous une idée de la provenance de ce problème ?
>
> Cordialement.
-----------------------------------------

A+


"Avec suffisamment de paires d'yeux, tous les bugs feront surface."

                                                        Linus Torvalds.

Offline