4. Ventilation des temps consommés#
4.1. Temps consommés par commande#
Code_Aster propose deux niveaux de lecture pour analyser les temps consommés par chaque commande:
Un niveau global qui amalgame toutes les étapes de calcul de ladite commande,
Un niveau plus fin (paramétrable) qui permet de dissocier les principales étapes.
4.1.1. Monitoring global de chaque commande#
À l’issue de chaque commande , sont tracés dans le fichier message les différentes consommations en temps [6]_ de l’opérateur: CPU [7]_ +système (USER+SYST), système (SYST) et elapsed (ELAPS). A priori, toute dérive importante du temps SYSTet/ou du temps ELAPSEDdoit questionner (cf. §6.2).
# FIN COMMANDE NO : 0045 USER+SYST : 520.01s ( SYST : 12.17s, ELAPS : 525.12s)
# ——————————————————————————-
Figure 4.1.1-a : Traces des consommations globales en temps d’une commande Aster (extrait d’un .mess ).
Ces temps sont aussi récapitulés, pour toutes les commandes, dans le fichier résultat.
COMMAND : USER : SYSTEM : USER+SYS : ELAPSED *
init (jdc) : 2.62 : 0.88 : 3.50 : 4.30 *
. compile : 0.00 : 0.00 : 0.00 : 0.01 *
. exec_compile : 0.54 : 0.03 : 0.57 : 0.58 *
. report : 0.03 : 0.00 : 0.03 : 0.03 *
. build : 0.00 : 0.00 : 0.00 : 0.00 *
DEBUT : 0.04 : 0.05 : 0.09 : 0.13 *
PRE_GIBI : 10.75 : 1.89 : 12.64 : 12.69 *
LIRE_MAILLAGE : 27.92 : 0.13 : 28.05 : 28.37 *
DEFI_MATERIAU : 0.01 : 0.00 : 0.01 : 0.01 *
AFFE_MATERIAU : 0.04 : 0.01 : 0.05 : 0.05 *
AFFE_MODELE : 5.48 : 0.08 : 5.56 : 5.57 *
AFFE_CHAR_MECA : 0.52 : 0.02 : 0.54 : 0.54 *
…
MECA_STATIQUE : 2249.89 : 18.55 : 2268.44 : 2271.87 *
TEST_RESU : 0.01 : 0.01 : 0.02 : 0.01 *
FIN : 0.11 : 0.01 : 0.12 : 0.17 *
. part Superviseur : 3.37 : 0.94 : 4.31 : 5.21 *
. sdveri : 0.68 : 0.01 : 0.69 : 0.73 *
. part Fortran : 4600.81 : 39.42 : 4640.23 : 4650.96 *
TOTAL_JOB : 4604.18 : 40.36 : 4644.54 : 4656.18 *
Figure 4.1.1-b : Consommations globales en temps de toutes les commandes Aster (extrait d’un .resu ).
4.1.2. Monitoring fin de chaque commande#
La ventilation des temps consommés (USER+SYST, SYST, ELAPS) suivant les différentes étapes de calcul (calcul élémentaire, assemblage, factorisation numérique…) est effectuée à l’issue de chaque opérateur impliquant la construction et/ou la résolution de systèmes linéaires (par exemple STAT_NON_LINE et CALC_CHAMP). Par défaut, on affiche des valeurs synthétiques (niv=1). En effet, cette description des temps consommés peut se décliner suivant différents niveaux de lecture via le paramètre MESURE_TEMPS/NIVE_DETAIL des commandes DEBUT/POURSUITE.
A priori , toute dérive importante du temps SYST et/ou du temps ELAPS doit questionner (cf. § 6.2).
Détaillons les niveaux d’impressions de MESURE_TEMPS/NIVE_DETAIL=niv ( défaut=1) :
/niv=0, Aucune impression relative au monitoring en fin de chaque commande,
/niv=1, Impressions synthétiques des trois types de temps pour les calculs élémentaires/assemblages et pour la résolution de systèmes linéaires associés:
#1. Resolution.des.systemes.lineaires ……..CPU.(USER+SYST/SYST/ELAPS):…7.52…0.79.. 11.22
#2. Calculs.elementaires.et.assemblages … CPU.(USER+SYST/SYST/ELAPS):..15.07…0.70…15.77
Figure 4.1.2-a : Consommations en temps dans une commande Aster type STAT_NON_LINE ou CALC_CHAMP avec niv=1 en séquentiel (extrait d’un .mess).
/niv=2, Impressions détaillées des temps pour les deux grands classes de calculs: calculs élémentaires/assemblages et résolution de systèmes linéaires associés. Ce type d’information peut renseigner quant à l’impact d’une modification du fichier de commande ou des paramètres de lancement du calcul (mémoire, parallélisme…). Par exemple, sachant que le parallélisme MPI ne permet potentiellement de diminuer (cf. doc. U2 dédiée) que les étapes 1.3/1.4/2, cela est peu utile de paralléliser un calcul [8]_
sur des dizaines de processeurs si l’étape 1.2 prend 20% du temps total [9]_ !
#1.Resolution.des.systemes.lineaires ……… CPU.(USER+SYST/SYST/ELAPS):…7.72…0.82…8.72
#1.1.Numerotation,.connectivité.de.la.matrice CPU.(USER+SYST/SYST/ELAPS):…0.21…0.02…0.31
#1.2.Factorisation.symbolique……………..CPU.(USER+SYST/SYST/ELAPS):…0.58…0.05…1.28
#1.3.Factorisation.numerique.(ou.precond.)….CPU.(USER+SYST/SYST/ELAPS):…6.78…0.73…7.71
#1.4.Resolution………………………….CPU.(USER+SYST/SYST/ELAPS):…0.15…0.02…0.35
#2.Calculs.elementaires.et.assemblages ……..CPU.(USER+SYST/SYST/ELAPS):..28.87…0.64…29.47
#2.1.Routine.calcul………………………CPU.(USER+SYST/SYST/ELAPS):..26.61…0.56…26.61
#2.1.1.Routines.te00ij……………………CPU.(USER+SYST/SYST/ELAPS):..24.58…0.07…25.78
#2.2.Assemblages…………………………CPU.(USER+SYST/SYST/ELAPS):…2.26…0.08…3.36
#2.2.1.Assemblage.matrices………………..CPU.(USER+SYST/SYST/ELAPS):…2.02…0.06…3.12
#2.2.2.Assemblage.seconds.membres………….CPU.(USER+SYST/SYST/ELAPS):…0.24…0.02…0.37
Figure 4.1.2-b : Consommations en temps dans une commande Aster type STAT_NON_LINE ou CALC_CHAMP avec niv=2 en séquentiel (extrait d’un .mess ).
/niv=3, Idem que niv=2 mais l’impression est faite pour chaque pas de temps ou incrément de calcul.
En mode parallèle MPI (cf. doc. U2 sur le parallélisme ou doc. U4.50.01), on rajoute la valeur moyenne, sur tous les processeurs, des temps consommés ainsi que leur écart-type. Cette information est intéressante pour repérer d” éventuels déséquilibres de charges . Ils peuvent être dus à une distribution de données [10]_ non homogène en nombre de mailles, en terme de complexité de loi de comportement, en accès mémoire aux structures de données…
#1.Résolution.des.systèmes.linéaires……….CPU.(USER+SYST/SYST/ELAPS):…0.29…0.00…0.35
…. (moyenne….diff..procs) …………….CPU.(USER+SYST/SYST/ELAPS):…0.30…0.00…0.47
…. (écart-type.diff..procs) ……. CPU.(USER+SYST/SYST/ELAPS):…0.01…0.00…0.05
Figure 4.1.2-c: Consommations en temps dans une commande Aster type STAT_NON_LINEou CALC_CHAMP avec niv=1 en mode parallèle MPI (extrait d’un .mess).
D’autre part, il arrive que le gestionnaire mémoire d” Aster (JEVEUX) décharge des objets sur disque pour libérer de la RAM (cf. §5.1). Suivant la configuration matérielle, la charge machine et la taille du problème, ces déchargements sont susceptibles de ralentir de manière non négligeable le déroulement du calcul. Lorsque des déchargements se sont produits, au cours d’un opérateur, on trace le cumul de leurs temps consommés (USER+SYST, SYST, ELAPS) en fin d’opérateur. Cela permet par la suite d’affiner d’éventuels diagnostics (cf. §6.2).
#4 Dechargement de la memoire sur disque CPU (USER+SYST/SYST/ELAPS): 0.04 0.04 0.04
Figure 4.1.2-d : Surcoûts en temps dûs aux déchargements sur disque de JEVEUX (extrait d’un .mess ).
Remarque:
On récapitule le volume total récupéré et le nombre d’occurences de ce mécanisme en fin de fichier message (cf. §5.1).
4.2. Temps consommés globaux#
En fin de fichier message sont tracés systématiquement la somme des consommations CPU, CPU+SYST, SYST et le reliquat de temps non utilisé (entre le temps mentionné par l’utilisateur dans Astk et le temps CPU+SYST).
A priori, toute dérive importante du temps SYSTEMEdoit questionner (cf. §6.2).
<I> < INFORMATION TEMPS D’EXECUTION > (EN SECONDE)
TEMPS CPU TOTAL ………….. 2160.55
TEMPS CPU USER TOTAL ……… 2099.33
TEMPS CPU SYSTEME TOTAL …… 61.22
TEMPS CPU RESTANT ………… 439.45
Figure 4.2-a : Consommations globales en temps d’un calcul (extrait d’un .mess ).
4.3. Cas particulier de DYNA/STAT_NON_LINE#
Dans ces commandes de dynamique/statique non linéaires, on trace en standard (INFO=1) pour chaque pas de temps ou incrément de calcul , en supplément du tableau de décroissance des résidus (le niveau de détails est géré par le mot-clé AFFICHAGE des commandes):
Les champs stockés (sélectionnés par le mot-clé ARCHIVAGE),
La ventilation des temps CPU consommés et, éventuellement, le nombre d’itérations associés (ex. processus de Newton),
Des blocs d’affichages dédiés (ex. contact-discret).
L” archivage des champs peut être coûteux en temps (surtout en parallèle) et en mémoire . Il est donc être intéressant d’analyser la liste des champs archivés afin éventuellement de les limiter.
ARCHIVAGE DES CHAMPS:
Champs archivés
A limiter (surtout en parallèle) CHAMP STOCKE : CONT_NOEU INSTANT : 5.00000E+02 NUMERO D’ORDRE : 50
CHAMP STOCKE : DEPL INSTANT : 5.00000E+02 NUMERO D’ORDRE : 50
CHAMP STOCKE : SIEF_ELGA INSTANT : 5.00000E+02 NUMERO D’ORDRE : 50
CHAMP STOCKE : VARI_ELGA INSTANT : 5.00000E+02 NUMERO D’ORDRE : 50
CHAMP STOCKE : VITE INSTANT : 5.00000E+02 NUMERO D’ORDRE : 50
Ventilation temps CPU/itérations CHAMP STOCKE : ACCE INSTANT : 5.00000E+02 NUMERO D’ORDRE : 50
TEMPS CPU CONSOMME DANS CE PAS DE TEMPS : 0 s
TEMPS PAR ITERATION DE NEWTON : 0 s - NBRE NEWT.: 2
TEMPS ARCHIVAGE : 0 s
Seules ces parties peuvent bénéficier du parallélisme TEMPS CREATION NUMEROTATION : 0 s - NBRE NUME.: 0
TEMPS FACTORISATION MATRICE : 0 s - NBRE FACT.: 0
TEMPS INTEGRATION COMPORTEMENT : 0 s - NBRE INTE.: 3
TEMPS RESOLUTION K.U = F : 0 s - NBRE RESO.: 2
TEMPS RESOLUTION CONTACT : 0 s - NBRE ITER.: 2
TEMPS AUTRES OPERATIONS : 0 s
Bloc d’affichages dédié (contact…)
CONTACT DISCRET:
NOMBRE D’ITERATIONS DE CONTACT : 2
NOMBRE D’ITERATIONS DE REAC. GEOM : 2
NOMBRE FINAL DE LIAISONS DE CONTACT : 0
TEMPS TOTAL APPARIEMENT : 0 s
TEMPS TOTAL RESOLUTION : 0 s
Figure 4.3-a : Affichage à chaque pas de temps de DYNA/STAT_NON_LINE avec INFO=1 en mode séquentiel (extrait d’un .mess ).
En fin d’opérateur sont résumées les statistiques globales sur tout le transitoire . Ces temps CPU se retrouvent dans la statistique globale de fin d’opérateur mentionnée au paragraphe précédent. Par contre, leur granularité est plus fine et adaptée aux différentes étapes de l’opérateur.
STATISTIQUES SUR LE TRANSITOIRE
NOMBRE DE PAS DE TEMPS : 100
NOMBRE D’ITERATIONS DE NEWTON : 200
NOMBRE D’ITERATIONS DE CONTACT (ALGO) : 456
NOMBRE D’ITERATIONS DE CONTACT (GEOM) : 200
NOMBRE DE CREATION DE NUMEROTATION : 1
NOMBRE DE FACTORISATION DE MATRICE : 2
NOMBRE D’INTEGRATION DE COMPORTEMENT : 201
NOMBRE DE RESOLUTION K.U = F : 200
TEMPS POUR CREATION NUMEROTATION : 10 s
TEMPS POUR FACTORISATION MATRICE : 100 s
TEMPS POUR INTEGRATION COMPORTEMENT : 3 m 8 s
TEMPS POUR RESOLUTION K.U = F : 9 s
TEMPS POUR CONTACT (APPARIEMENT) : 17 s
TEMPS POUR CONTACT (ALGORITHME) : 2 m 30 s
Figure 4.3-b : Statistiques globales à l’issu de DYNA/STAT_NON_LINE avec INFO=1 (extrait d’un .mess ).