Emploi du temps

Table of Contents

1. Plan

1.1. Passage aux études out-of-core et parallèle distribuée

  • se lancer en parallèle dans out-of-core et distribué
  • revoir l'automatisation du workflow pour le développement et le déploiement
    • à priori, le script setenv.sh permet de tout gérer facilement (environnements Guix, génération d'images Singularity,…)
    • Guix disponible sur PlaFRIM, Singularity disponible sur PlaFRIM, Curta et IDRIS
    • les autres plateformes proposent uniquement les modules
  • utiliser PlaFRIM pour travailler au développement de la pile (déploiement le plus facile)

1.1.1. Out-of-core

  • PlaFRIM (accès obtenu)
    • disques SSD NVMe : sirocco14-16 (750Go, débit à déterminer depuis le nœud)
    • disques SSD classiques : kona01-04 (800Go, L/E 500/460 Mo/s), sirocco21 (RAID0 de deux SSD - 3.5To au total, L/E 838/650 Mo/s par disque)
    • disques SAS à 15000rpm : brise (558Go, modèle « PERC H730P Adp » mais impossible à trouver un disque pareil sur Internet, ça serait plutôt le modèle du contrôleur, à voir avec l'équipe PlaFRIM), sirocco07-13 (300Go, L/E 250/175 Mo/s), sirocco17 (1To ou 300Go d'après le numéro du modèle, L/E 233/160 Mo/s)
    • disques SATA à 7200rpm : bora001-044 (1To, 136 Mb/s - unités à confirmer), miriel001-088 (300Go, 115 Mo/s), diablo01-05 (1To, 194 Mo/s), sirocco01-05 (1To, 115 Mo/s), sirocco06 (1To, 175 Mo/s)
  • IDRIS (demande d'accès en cours)
    • 4 nœuds de pré et post-traitement avec 1,5Go SSD NVMe (modèle non précisé)
    • JOBSCRATCH au lieu de /tmp : GPFS à 500Go/s
  • TGCC (demade d'accès en cours)
    • 1 nœud de visualisation distante avec 800Go SSD NVMe (modèle non précisé)
    • 5 nœuds de pré et post-traitement avec 1,6Go SSD NVMe (modèle non précisé) : SKL
    • SCRATCH au lieu de /tmp : réseau EDR à 300Go/s
  • OCCIGEN (accès obtenu)
    • disques locaux non spécifiés
    • SCRACTH : Lustre à 105Go/s
  • Curta (accès obtenu)
    • tous les nœuds disposent d'un disque local SATA à 7200rpm avec 460Go d'espace (modèle non précisé)

1.1.2. Parallèle distribué

  • PlaFRIM (accès obtenu)
    • 100G : bora001-044, miriel001-043, diablo01-05, sirocco07-13, sirocco14-17
    • 40G : miriel001-088, sirocco01-05
    • 10G : tous les nœuds sauf kona01-04
    • 1G : kona01-04
  • IDRIS (demade d'accès en cours)
    • 100G : tous les nœuds
  • TGCC (demade d'accès en cours)
    • 100G : SKL et Rome
  • OCCIGEN (accès obtenu)
    • 4 × 56 G (d'après les infos trouvées sur Internet, le site du CINES indique le type de liaison - Infiniband 4 × FDR)
  • Curta (accès obtenu)
    • 100G : tous les nœuds

1.2. Étude énergétique

  • reste le mystère de la consommation lors de la compression (très élevée par rapport aux GEMMs)
  • aller voir Hervé pour demander des benchmarks de référence qui permettent notamment d'atteindre la conso max des machines - miriel

1.3. Nouveaux algorithmes

1.3.1. qr_mumps

  • commencer à explorer cette piste dès que possible (une fois les études out-of-core et parallèle distribué stabilisés)
  • GPU
  • grandes étapes à suivre :
    1. prise en mains : passage de LLH en LLT
    2. implémentation de multi-solve
    3. fournir une routine pour le calcul du complément de Schur (voir avec Alfredo) : vers l'implémentation de multi-facto
    4. single-stage

1.3.2. Couplage entre solveur creux (MUMPS/PaStiX/…) et dense (SPIDO/HMAT/…)

  1. Multi-solve: exploiter la présence de colonnes nulles dans B

    Y a-t-il quelque chose à gagner ?

  2. apport du BLR (compression low rank) dans mumps ?

1.3.3. Couplage PaStiX et SPIDO/HMAT

Avec PaStiX, c'est mpf/src/MAT/IMPLS/PASTIX/matfactpartsolve​_pastix.c

L'approche multi-solve PaStiX est dans mpf/src/MAT/IMPLS/PASTIX/matsolvegemm​_pastix.c, elle ne marche qu'avec une matrice D au format SPIDO (dense).

  1. Passage en PaStiX 6

    Aujourd'hui on utilise PaStiX 5.2, PaStiX 6 utilise une API très différente. Il faudra adapter mpf dans les différentes routines appelant PaStiX (MatFactor, MatSolve). On pourra utiliser test​_FEMBEM pour valdier tout ça.

  2. Approche multi-facto avec pastix et SPIDO/HMAT

    Il faut ré-écrire en pastix la routine CreateSchurComplement(). Les routines « au dessus » doivent être très proche de MPF​_multifact​_MUMPS() et MPF​_multifact​_MUMPS​_HMAT().

1.4. Approche Full \(\mathcal{H}\)-matrix

Jérôme est en train de bosser à récupérer une partie des développements d'Aurélien : au moins la partie nested disection, peut être la connexion à scotch. Pour la partie factorisation symbolique, on va attendre (confiance moyenne dans les devs d'AF.

1.4.1. Bencher l'approche Full \(\mathcal{H}\)-matrix

1.4.2. Nested dissection « épaisse »

Au lieu de mettre un séparateur le plus fin possible, on crée un séparateur de même taille que les 2 intérieurs, i.e. on coupe en 3 parts égales.

Intérêt : plus de blocs tall&skinny dans la matrice, meilleure compression des Rk-matrices.

Inconvénient : les blocs de zéros créés sont plus petits.

1.5. Approche itérative

On peut tourner avec ou sans FMM, avec ou sans complément de schur, et si « avec » on peut choisir MUMPS ou PaStiX.

1.6. PARDISO

1.7. Intérêt du raffinement itératif dans MUMPS, PaStiX, HMAT

1.8. Randomized QR

Cet algo peut être utilisé pour créer la compression Rk de blocs de matrices, en utilisant des produits matrice-vecteur par le bloc de matrice qu'on souhaite compresser. Intéressant dans les cas où ce produit mat-vec est pas cher :

1.8.1. randomized QR sur des blocs creux

1.8.2. randomized QR sur des blocs pour lesquels on peut faire une FMM

1.9. Task-based HMAT : gestion optimisée des très gros blocs

Aujourd'hui, l'algo HMAT, sur le cluster Airbus, dispose (suivant les nœuds) de 3 à 12 Go de RAM par workers, donc par tâche. Cela conduit à limiter la taille des plus grosses Rk dans la matrice, et donc à subdiviser des blocs là où le critère d'admissibilité nous dirait qu'on peut les conserver. Cette subdivision « inutile » augmente le nombre d'opérations et le temps de calcul. On souhaite remédier à ça en introduisant des nouveaux algos spécifiques pour opérer sur ces très gros Rk sans les subdiviser (au sens de la subdivision \(\mathcal{H}\)-matrice).

1.10. New preconditionner using HHMAT ideas

We currently use SPAI (Sparse approximate inverse) as precondionner. What about using \(\mathcal{H}\)-matrices with low accuracy as preconditionner? Or accuracy that decreases as we go away from the diagonal? Or \(\mathcal{H}\)-SPAI algorithm?

2. Objectif final

Passer les plus gros cas FEM-BEM possibles. Quels algos s'y prêtent le mieux ?

3. Bogues connus

3.1. Erreurs LAPACK dans le multi-solve compressé

Des erreurs LAPACK apparaissent lors du calcul du complément de Schur ou lors de la factorisation de celui-ci. Le phénomène peut être observé à partir d'une certaine taille de problème (2 000 000 d'inconnues et plus particulièrement à partir de 4 000 000 d'inconnues) et uniquement pour des matrices double complexes.

3.2. Exécution de test_FEMBEM échoue avec PaStiX et Chameleon

3.2.1. PaStiX

Sur notre machine, on a obtenu la backtrace suivante avec gdb (commande de lancement run -withmpf --fem -pastix) :

PASTIX 5.2.3
PASTIX: Check Matrix format
PASTIX: Initialize parameters to default values
PASTIX: Ordering / Scotch
PASTIX: Symbolic factorization
PASTIX: Mapping and Compute scheduling
free(): invalid pointer

Thread 1 "test_FEMBEM" received signal SIGABRT, Aborted.
0x00007fffef8a7aba in raise () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6
(gdb) bt
#0  0x00007fffef8a7aba in raise () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6
#1  0x00007fffef8a8bf5 in abort () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6
#2  0x00007fffef8e9c97 in __libc_message () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6
#3  0x00007fffef8f0fea in malloc_printerr () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6
#4  0x00007fffef8f292c in _int_free () from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6
#5  0x00007ffff09fed30 in memFree (memptr=0x77e090) at common/src/common_memory.c:369
#6  0x00007ffff0a070c7 in symbolRealloc (symbptr=symbptr@entry=0xca41f8) at symbol/src/symbol.c:114
#7  0x00007ffff0a0f621 in solverBlend (solvmtx=0xca69b8, symbmtx=0xca41f8, assemb1D=0x7fffffffe500, assemb2D=0x7fffffffe520, clustnbr=1, thrdlocnbr=<optimized out>, cudanbr=0, clustnum=0, option=0x7fffffffe540,
    dofptr=0x7fffffffe4e0) at blend/src/blend.c:172
#8  0x00007ffff0c5a6ee in Z_pastix_task_blend () from /gnu/store/vx1scgsd5rc7sz2fgid6qimzcvlr3sbl-pastix-5-mkl-5.2.3/lib/libpastix.so
#9  0x00007ffff0c5fc1d in z_pastix () from /gnu/store/vx1scgsd5rc7sz2fgid6qimzcvlr3sbl-pastix-5-mkl-5.2.3/lib/libpastix.so
#10 0x00007ffff168b50d in MatFactor_PASTIX (mat=<optimized out>) at /tmp/guix-build-mpf-git.fec66d4.drv-0/mpf-git.fec66d4/src/MAT/IMPLS/PASTIX/matfactor_pastix.c:118
#11 0x00007ffff16f4594 in MatFactor (mat=0x67c0e0) at /tmp/guix-build-mpf-git.fec66d4.drv-0/mpf-git.fec66d4/src/MAT/INTERFACE/mat_factor.c:50
#12 0x000000000041b1f5 in testMPF (argc=argc@entry=0x7fffffffe83c, argv=<optimized out>) at /tmp/guix-build-scab-git.297fe52.drv-0/scab-git.297fe52/fmmlibs/tools/test_FEMBEM/SRC/testMPF.c:438
#13 0x0000000000409c9c in main (argc=<optimized out>, argv=<optimized out>) at /tmp/guix-build-scab-git.297fe52.drv-0/scab-git.297fe52/fmmlibs/tools/test_FEMBEM/SRC/main.c:386

De plus, on a détecté que dans la définition du paquet pastix-5, les chemins vers scotch et hwloc étaient invalides. Cependant, la compilation passait quand même. Le problème persiste aussi après avoir corrigé cela.

On note que l'on a également supprimé pt-scotch de la liste des dépandances de PaStiX en version 5 ainsi que de celle de mpf. Aussi, les références vers scotch ont été remplacées par scotch32.

Effectivement, après vérification, PaStiX n'est pas linké avec SCOTCH.

3.2.2. Chameleon

Lors des essais menés par GS, Chameleon marchait bien !

Sur notre machine, on a obtenu la backtrace suivante avec gdb (commande de lancement run -solvechameleon) :

 **** Creating MAT CHAMELEON...

Thread 1 "test_FEMBEM" received signal SIGSEGV, Segmentation fault.
0x00007fffef4bd470 in _starpu_worker_exists_and_can_execute.constprop.23 () from /gnu/store/072xvma27lfih1zdzg00jn2zw8q9z8kl-starpu-1.3.5/lib/libstarpu-1.3.so.4
(gdb) bt
#0  0x00007fffef4bd470 in _starpu_worker_exists_and_can_execute.constprop.23 () from /gnu/store/072xvma27lfih1zdzg00jn2zw8q9z8kl-starpu-1.3.5/lib/libstarpu-1.3.so.4
#1  0x00007fffef4bd568 in _starpu_worker_exists () from /gnu/store/072xvma27lfih1zdzg00jn2zw8q9z8kl-starpu-1.3.5/lib/libstarpu-1.3.so.4
#2  0x00007fffef4b4378 in _starpu_task_submit_head () from /gnu/store/072xvma27lfih1zdzg00jn2zw8q9z8kl-starpu-1.3.5/lib/libstarpu-1.3.so.4
#3  0x00007fffef4b6215 in starpu_task_submit () from /gnu/store/072xvma27lfih1zdzg00jn2zw8q9z8kl-starpu-1.3.5/lib/libstarpu-1.3.so.4
#4  0x00007fffef5fa57a in _starpu_mpi_task_insert_v () from /gnu/store/072xvma27lfih1zdzg00jn2zw8q9z8kl-starpu-1.3.5/lib/libstarpumpi-1.3.so.3
#5  0x00007fffef5fa787 in starpu_mpi_insert_task () from /gnu/store/072xvma27lfih1zdzg00jn2zw8q9z8kl-starpu-1.3.5/lib/libstarpumpi-1.3.so.3
#6  0x00007ffff07781c4 in INSERT_TASK_map () from /gnu/store/xrd553kv29bncbhj85xjp9mc3l0m65g9-chameleon-git.b1d8091/lib/libchameleon_starpu.so
#7  0x00007ffff0847e8f in chameleon_pmap () from /gnu/store/xrd553kv29bncbhj85xjp9mc3l0m65g9-chameleon-git.b1d8091/lib/libchameleon.so
#8  0x00007ffff0847c76 in CHAMELEON_map_Tile_Async () from /gnu/store/xrd553kv29bncbhj85xjp9mc3l0m65g9-chameleon-git.b1d8091/lib/libchameleon.so
#9  0x00007ffff0847d89 in CHAMELEON_map_Tile () from /gnu/store/xrd553kv29bncbhj85xjp9mc3l0m65g9-chameleon-git.b1d8091/lib/libchameleon.so
#10 0x000000000040a618 in CHAMELEON_generate_matrix (flttype=ChamComplexDouble, NB=320, PQ=PQ@entry=0x7fffffffe818, descA=descA@entry=0x7fffffffe800)
    at /tmp/guix-build-scab-git.297fe52.drv-0/scab-git.297fe52/fmmlibs/tools/test_FEMBEM/SRC/chameleon.c:137
#11 0x00000000004178f9 in testCHAMELEON () at /tmp/guix-build-scab-git.297fe52.drv-0/scab-git.297fe52/fmmlibs/tools/test_FEMBEM/SRC/testCHAMELEON.c:38
#12 0x0000000000409c3a in main (argc=<optimized out>, argv=<optimized out>) at /tmp/guix-build-scab-git.297fe52.drv-0/scab-git.297fe52/fmmlibs/tools/test_FEMBEM/SRC/main.c:370

4. Tests de performance

4.1. Évaluation des implémentations existantes d'Aurélien

  • CV-HSF HMAT
    • minimum fill (MF)
    • algébrique
    • partitionneur de graphes
    • ND avec MF
  • BBox HMAT
    • ND
    • géométrique
    • pas de finition comme MF

Définir une campagne de tests spécifique pour ça.

5. Bibliographie

  • thèse d'Aurélien
  • thèse de Terry Cojean
  • thèse de Stojce Nakov
  • article de E. Agullo et al.
    • notamment les sections 4.4 et 5.3 portant sur le out-of-core
  • manuel de StarPU
    • profilage de H-MAT
    • utilisation de workers
    • fonctionnement du out-of-core implicite

6. Astuces

6.1. Accès à la machine occigen

Faire directement ssh mfelsoci@occigen.cines.fr ne marche pas. La commande se termine une fois le temporisateur expiré (connection timed out).

Il faut passer par la passerelle d'Inria acces1.bordeaux.inria.fr pour se connecter à la machine occigen. En plus, il a fallu passer par Julien pour rajouter la clé publique sur la passerelle pour se connecter dessus.

6.2. Utilisation d'ICC dans Guix

Grand merci à Ludo de nous avoir fourni les définitions de paquets intel-compilers désormais accessible via le dépôt guix-hpc-non-free.

À noter, sur PlaFRIM, il faut installer la version 2019.4 car c'est la seule pour laquell l'on dispose de la licence sur PlaFRIM :

guix install intel-compilers@2019.4

Puis, il ne faut pas oublier de mettre à jour la variable d'environnement GUIX_PROFILE de façon suivante (sinon un problème d'édition de liens apparaît) :

GUIX_PROFILE="/home/<plafrim-username>/.guix_profile" . \
"$GUIX_PROFILE/etc/profile"

Ainsi, les compilateurs Intel sont disponibles directement via la ligne de commandes, e. g. icc test.c -o test.

Testée sur notre machine personnelle, la version la plus récente qui est disponible, à savoir 2020, fonctionne aussi en lui fournissant une licence gratuite étudiante obtenue auprès d'Intel.

Il ne faut pas oublier de créer une variable d'environnement nomée INTEL_LICENSE_FILE contenant le chemin vers le fichier de licence à utiliser.

Par exemple :

export INTEL_LICENSE_FILE=~/intel/NCOM_L___XXXX-XXXXXXXX.lic

6.3. Tracé automatique de courbes de perfs

Jérôme propose pyqtgraph (moche, pas facile à installer sans un gestionnaire de paquet – mais peut-être que sur Guix ça devrait aller) ou alors pygal (simple à installer, utiliser et hacker mais lent ! cependant full-Python).

jmcc dit que ggplot2 c'est bien mais il faut faire attention à bien organiser les données dans le cas où on change d'outil (si jamais), il n'a pas récemment utilisé les outils que Jérôme a conseillés (+ CSV c'est bien comme format, surtout pour de grands jeux de données).

gcvb contient déjà un tableau de bord qui lui permet de voir l'évolution d'une métrique au cours du temps (mais la biblio n'est pas inlcluse par défaut car trop grande), le plan est de rajouter Dash By Plot dans gcvb pour pouvoir créer des dashboards complets (voir https://dash-gallery.plotly.host/Portal/ et https://plot.ly)

6.4. Surveillance de la consommation disque

inotify permet de surveiller les événements survenus sur un fichier ou tout un dossier mais ne permet pas de surveiller sa taille. Pour faire ça, il faut se servir des outils standards, tel que stat, par exemple.

Cependant, on peut utiliser cette bibliothèque pour effectuer des mesures de manière un peu plus intelligente, c'est à dire relever la taille des fichiers surveillés qu'au moment de modification et éviter un contrôle périodique éventuellement plus consommateur.

En plus, il existe une implémentation d'inotify en Python (dispo sur Guix).

Pour le moment, on se contente d'exécuter du toutes les secondes (implémenté dans rss.py).

Date: 25/02/2022 | 18:08:50

Author: Emmanuel Agullo, Marek Felšöci, Guillaume Sylvand

Email: emmanuel.agullo@inria.fr, marek.felsoci@inria.fr, guillaume.sylvand@airbus.com

Validate