Indicatori di performance di un calcolo

U1.03.03

Indice1 Scopo 2

2 Generalità 3

3 Caratteristiche dei sistemi lineari 4

4 Ripartizione del tempo impiegato 74.1 Tempo impiegato per un comando . . . . . . . . . . . . . . . . 7

4.1.1 Monitoraggio globale di un comando . . . . . . . . . . 74.1.2 Monitoraggio dettagliato di un comando . . . . . . . . 8

4.2 Tempo impiegato globale . . . . . . . . . . . . . . . . . . . . . 114.3 Caso particolare di DYNA_NON_LINE e STAT_NON_LINE . . 11

5 Consumo di memoria RAM 145.1 Calibrazione della memoria di un calcolo . . . . . . . . . . . . 155.2 Impiego di memoria per JEVEUX . . . . . . . . . . . . . . . . 175.3 Impiego di memoria per i prodotti MUMPS . . . . . . . . . . . 215.4 Impiego di sistema . . . . . . . . . . . . . . . . . . . . . . . . 23

6 Alcuni consigli per ottimizzare le prestazioni 256.1 Riguardo alle caratteristiche del problema . . . . . . . . . . . 256.2 Riguardo al tempo impiegato . . . . . . . . . . . . . . . . . . 256.3 Riguardo alla RAM impiegata . . . . . . . . . . . . . . . . . . 276.4 Riguardo al parallelismo . . . . . . . . . . . . . . . . . . . . . 28

1

1 ScopoDurante una simulazione con Code-Aster, le impostazioni predefinite traccianonei file dei messaggi e dei risultati (.mess/.resu) alcune caratteristiche didimensionamento del calcolo (consumo RAM, tempo CPU, sistema utente,. . . ). Questa documentazione descrive in dettaglio i display di questi indicatoridi prestazione.

Ci sono anche alcuni suggerimenti per aiutare l’utente a trarre vantaggioda queste diagnosi. Ma dobbiamo essere consapevoli che non esiste una ricettauniversale per ottimizzare le prestazioni complessive di un calcolo. Dipendedal tipo di studio, dagli aspetti software/hardware della macchina e persinodal suo carico di lavoro.

Le impostazioni predefinite e i display/allarmi del codice forniscono un fun-zionamento bilanciato e strumentato. Ma per essere sicuri di aver sfruttato almeglio le capacità della macchina, l’utente deve rimanere attento agli elementidescritti in questo documento e ai consigli contenuti nella documentazione deicomandi. Questo documento contiene molti riferimenti alla documentazionerelativa: alla parola chiave SOLVEUR [U4.50.01], all’utilizzo dei solutori lineari[U2.08.03] e aull’utilizzo del parallelismo [U2.08.06] .

2

2 GeneralitàDurante una simulazione Code-Aster, per impostazione predefinita vengonovisualizzate le tracce, nel file dei messaggi e dei risultati (.mess/.resu), dialcune caratteristiche di dimensionamento del calcolo. Troviamo, per ognioperatore Aster:

• Le caratteristiche dei sistemi lineari da costruire e risolvere (numero dinodi, equazioni di Lagrange, dimensione della matrice, . . . )

• La memoria JEVEUX piatta (per passare in modalità out-of-core1) e lamemoria JEVEUX ottimale (per passare in modalità in-core)

• La memoria JEVEUX richiesta da alcuni prodotti esterni (ad esempio:MUMPS)

• Il tempo CPU, il tempo di sistema e il tempo trascorso (elapsed)

• La ripartizione dei tempi impiegati secondo le fasi di calcolo (calcolielementari/assemblaggi, risoluzione del sistema lineare, . . . )

Quest’ultima descrizione dei tempi impiegati può essere declinata in base aidiversi livelli di lettura (stampa sintetica, stampa dettagliata e stampa detta-gliata durante l’avanzamento del calcolo) tramite i parametri MESURE_TEMPSe NIVE_DETAIL dei rispettivi comandi DEBUT/POURSUITE. In modalità pa-rallela, aggiungiamo il valore medio, su tutti i processori, dei tempi impiegatie la loro deviazione standard.

1La Out-Of-Core (OOC) è una modalità di gestione della memoria che consiste nelloscaricare su disco alcuni oggetti allocati dal codice per liberare la RAM. Questi scarichipossono essere automatici (attivati dal sistema o dal pacchetto software JEVEUX) oppureorganizzati dal programmatore. La strategia OOC può gestire problemi più grandi, maquesti accessi al disco rallentano il calcolo. Al contrario, la modalità In-Core (IC) consistenel mantenere gli oggetti nella RAM. Ciò limita la dimensione dei problemi accessibili, masi concentra sulla velocità.

3

3 Caratteristiche dei sistemi lineariUn gran numero di operatori (STAT_NON_LINE, DYNA_NON_LINE, nonchèTHER_NON_LINE, CALC_MODES, . . . ) richiedono la costruzione e la riso-luzione di un sistema lineare. Per risolvere questi sistemi di equazioni,usiamo algoritmi speciali chiamati solutori lineari. Questi solutori linearisono infatti onnipresenti nel corso degli operatori di Code-Aster perché sonospesso utilizzati dagli algoritmi numerici: schemi non lineari, integrazione neltempo, analisi modale, . . .

Consumano la maggior parte del tempo e della memoria della CPU. Perimpostazione di default (INFO = 1), ogni comando traccia le sue caratteri-stiche durante la costruzione del sistema lineare: dimensione N , numero ditermini diversi da zero NNZ , . . .

--- NOMBRE TOTAL DE NOEUDS : 1705 DONT: 1364 NOEUDS "LAGRANGE"--- NOMBRE TOTAL D’EQUATIONS : 2046--- TAILLE DU PROFIL MORSE DE LA TRIANGULAIRE SUPERIEURE (FORMAT SCR): 26652--- DONC LA TAILLE DE LA MATRICE EST:--- EN SYMETRIQUE NNZ = 26652--- EN NON SYMETRIQUE NNZ = 51016

Nodi totali (NT ):fisici (NP ) + lagrangiani (NL)

NT = NP + NL

Numero di nodiLagrangiani (NL)

Dimensione sistema (N):2D isoparametricoN = 2NP + NL

Numero termini non nulli dellamatrice (NNZ) (Number of NonZero terms) nella memoria vuota.Quindi, in media, si hanno circaNNZ/N ≈ 13 termini diversida zero per riga e per colonna

A questo livello di calcolo, nonè ancora noto se la matrice siasimmetrica oppure no. Quindi,si menzionano le due possibilidimensioni di archiviazione:

• parte triang. superiore

• parte triang. superiore +parte triang. inferiore −diagonale

Figura 1: Caratteristiche del sistema lineare in corso di assemblaggio all’inter-no di un comando Aster tipo STAT_NON_LINE o THER_LINEAIRE (estrattodal file .mess)

4

Le dimensioni del sistema N , la parte Lagrangiana NL e il riempimentodella matrice forniscono informazioni indirette sui consumi memoria/CPUdel calcolo e sulle possibili difficoltà di risoluzione.

A grandi linee, la complessità algoritmica della costruzione del sistemalineare è in NNZ , mentre la sua risoluzione è dell’ordine Nα × NNZ (con1 < α < 2).

L’occupazione di memoria totale è di tipo β × 2NNZ × 8 Byte (con10 < β < 100)2. Questo consumo di memoria raccoglie diverse strutturedati Aster e/o relative a prodotti esterni (MATR_ASSE, NUME_DDL, matricefattorizzata, . . . ). Fortunatamente, queste strutture di dati sono suddivise indiversi segmenti di memoria distinti e l’algoritmo non impone la loro presenzasimultanea nella memoria RAM. Si può quindi scaricare spesso su disco buonaparte di questi dati.

D’altra parte, l’introduzione delle variabili di tipo Lagrangiano3 nellematrici (le cosiddette matrici dualizzate) degrada le loro proprietà numeriche(dimensione, matrice definita positiva, condizionamento della matrice). Ciòpertanto comporta spesso una maggiore elaborazione digitale nei solutori ene riduce le prestazioni. Questa osservazione può essere estesa anche a tuttigli elementi finiti misti (modellazione incomprimibile, metodi continui neicontatti, . . . ).

2Il termine β è approssimativamente il fattore di riempimento della fattorizzazione.Vale a dire, il fattore di memoria aggiuntiva, rispetto alla matrice iniziale, implicata nelprocesso di riempimento della fattorizzazione (fattorizzazione totale in semplice o doppiaprecisione di LDLT, MULT_FRONT, MUMPS [U4.50.01] oppure fattorizzazione in sempli-ce precisione dei precondizionatori GCPC e PETSC [U4.50.01], documenti di riferimentoassociati).

3Queste variabili di Lagrange vengono introdotte "artificialmente" durante il calcoloper tenere conto delle condizioni di Dirichlet (semplici o generalizzate oppure bloccanti ovincolanti).

5

Osservazioni

La visualizzazione delle caratteristiche del problema (Figura 1) vie-ne eseguita una sola volta, all’inizio dell’ordine. In generale, questecaratteristiche non cambiano durante il calcolo. Le uniche eccezioniriguardano l’operatore STAT_NON_LINE con il metodo X-FEM ingrande spostamento oppure con i metodi continui nei contatti. In que-sti contesti, il profilo della matrice cambia col passare delle iterazioni.Questo display si esegue molto presto nel processo, appena dopo lacreazione del profilo della matrice Aster4. L’assemblaggio dei terminielementari non è ancora stato effettuato5. È per questo motivo chenon si può governare, a priori, sul carattere simmetrico della matri-ce. In pratica, è spesso simmetrica e, in caso contrario, può esseresimmetrizzata tramite l’opzione SYME del’argomento SOLVEUR.

4Procedura che analizza le incognite del problema (al fine di creare il collegamentoalgebrico tra nodo, gradi di libertà e incognite) e dimensiona alcune strutture di dati Aster(NUME_DDL, MATR_ASSE, . . . ).

5È sufficiente che un termine elementare non sia simmetrico in modo che la matriceassemblata diventi non simmetrica.

6

4 Ripartizione del tempo impiegato

4.1 Tempo impiegato per un comando

Code-Aster propone due livelli di lettura per analizzare i tempi impiegati daciascun comando:

• Un livello globale che amalgama tutte le fasi di calcolo del suddettocomando

• Un livello dettagliato (configurabile) che consente di dissociare le tappeprincipali del comando

4.1.1 Monitoraggio globale di un comando

Alla fine di ogni comando, i diversi consumi di tempo6 dell’operatore vengonotracciati nel file di messaggi: CPU7+sistema (USER+SYST), sistema (SYST)e trascorso (ELAPS). A priori, ogni deriva significativa del tempo SYST e/odel tempo ELAPS deve essere messa in discussione (Capitolo 6.2).

# FIN COMMANDE NO: 0045 USER+SYST: 520.01s (SYST: 12.17s, ELAPS: 525.12s)# ------------------------------------------------------------------------------

********************************************************************************

Figura 2: Traccia dell’impiego di tempo globale per un comando Aster (estrattodi un file .mess)

6Il tempo della CPU (USER), misura l’esecuzione dei codici sorgenti (C, Fortran, Python).Il tempo di sistema (SYST) tiene conto delle chiamate di sistema sottostanti (accessodisco/RAM, . . . ). Il tempo trascorso (ELAPS) comprende i due precedenti e misura iltempo reale trascorso (wall clock).

7Il tempo della CPU qui è chiamato USER.

7

Questi tempi sono anche riepilogati nel file dei risultati (.resu) per tuttii comandi utilizzati:

********************************************************************************** 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 **********************************************************************************

Figura 3: Impiego complessivo di tempo per tutti i comandi Aster (estrattodi un file .resu)

4.1.2 Monitoraggio dettagliato di un comando

La suddivisione dei tempi impiegati (USER+SYST, SYST, ELAPS) in base allevarie fasi di calcolo (calcolo elementare, assemblaggio, fattorizzazione numerica,. . . ) viene eseguita alla fine di ciascun comando che implica la costruzionee/o la risoluzione di un sistema lineare (ad esempio: STAT_NON_LINE,CALC_CHAMP, . . . ).

Per impostazione predefinita (niv = 1), visualizziamo valori sintetici. Ineffetti, questa descrizione dei tempi consumati può essere declinata in base a di-versi livelli di lettura tramite il parametro MESURE_TEMPS e NIVE_DETAILdei comandi DEBUT e POURSUITE.

A priori, ogni deriva significativa del tempo SYST e/o del tempo ELAPSdeve essere messa in discussione (Capitolo 6.2). Descriviamo in dettaglio ilivelli di stampa di MESURE_TEMPS e NIVE_DETAIL a cui attribuiamo ilvalore niv (impostazione predefinita niv = 1):

8

• niv = 0: Nessuna stampa relativa al monitoraggio al termine diciascun comando

• niv = 1: Stampa sintetica dei tre tipi di tempo per calcoli elementa-ri/assemblaggi e per la risoluzione dei sistemi lineari associati:

#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

Figura 4: Impiego di tempo per un comando Aster di tipo STAT_NON_LINEo CALC_CHAMP con niv = 1 in modalità sequenziale (estratto di un file.mess)

• niv = 2: Stampe dell’impiego di tempo dettagliato per le due prin-cipali classi di calcoli: calcoli elementari/assemblaggi e risoluzione deisistemi lineari associati. Questo tipo di informazioni può fornire infor-mazioni sull’impatto di una modifica del file di comando o dei parametridi avvio del calcolo (memoria, parallelismo, . . . ). Ad esempio, sapendoche il parallelismo MPI può potenzialmente ridurre (vedere il documen-to [U2] dedicato) i passaggi 1.3, 1.4 e 2, sarebbe di scarsa utilitàparallelizzare un calcolo8 su decine di processori se il passaggio 1.2richiederebbe 20% del tempo totale9.

#1.Resolution.des.systemes.lineaires.........CPU.(USER+SYST/SYST/ELAPS):...7.72...0.82...8.72#1.1.Numerotation.connectivite.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

Figura 5: Impiego di tempo per un comando Aster di tipo STAT_NON_LINEo CALC_CHAMP con niv = 2 in sequenza (estratto di un file .mess)

8Questa operazione riduce il consumo di memoria richiesta e la quantità di temponecessaria per la costruzione e la risoluzione del sistema lineare. Di conseguenza, altrefunzionalità (ad esempio il contatto con attrito) potrebbero essere (leggermente) accelerateperché avrebbero più spazio nella RAM.

9Il guadagno di tempo (accelerazione) è limitato ad un fattore 5, anche su centinaia diprocessori!

9

• niv = 3: simile a niv = 2 ma la stampa viene eseguita per ogni fasetemporale o incremento del calcolo.

Nella modalità parallela a memoria distribuita (MPI) (vedi [U2] sulparallelismo oppure [U4.50.01] sul solver), aggiungiamo il valore medio,su tutti i processori, dei tempi impiegati e della loro deviazione standard.Questa informazione è interessante per identificare possibili squilibridi carichi computazionali. Possono essere dovuti ai seguenti fattori:una distribuzione dei dati10 non omogenea nella dimensione delle mesh(in termini di complessità della legge comportamentale), accesso allamemoria delle strutture di dati, . . .

#1.Resolution.des.systemes.lineaires.........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....(ecart-type.diff..procs)..............CPU.(USER+SYST/SYST/ELAPS):...0.01...0.00...0.05

Figura 6: impiego di tempo per un comando Aster di tipo STAT_NON_LINEo CALC_CHAMP con niv = 3 in modalità parallela MPI (estratto di un file.mess)

D’altra parte, succede che il gestore JEVEUX della memoria di Aster scaricagli oggetti sul disco per rilasciare la RAM (vedere Capitolo 5.1). A secondadella configurazione hardware, del carico della macchina e della dimensionedel problema, è probabile che questi scarichi rallentino significativamente ilprocesso di calcolo. Quando si verificano gli scarichi di memoria, duranteun operatore, si traccia l’accumulo dei loro tempo impiegato (USER+SYST,SYST, ELAPS) alla fine del comando. Ciò consente un ulteriore affinamentodelle possibili diagnosi (vedere Capitolo 6.2).

#4.Dechargement de la memoire sur disque......CPU.(USER+SYST/SYST/ELAPS):...0.04...0.04...0.04

Figura 7: Costi aggiuntivi nel tempo dovuti allo scarico su disco di JEVEUX(estratto di un file .mess)

10Nel flusso di dati distribuiti di JEVEUX o nei possibili strumenti esterni paralleli(MUMPS, PETSC).

10

Osservazione

Il volume totale recuperato e il numero di occorrenze di que-sto meccanismo vengono ricapitolati alla fine del file di messaggi(Capitolo 5.1).

4.2 Tempo impiegato globale

Alla fine del file dei messaggi vengono sistematicamente tracciati la sommadi USER, USER+SYST, consumi SYST e il resto del tempo inutilizzato (tra iltempo indicato dall’utente in Astk e il tempo USER+SYST). A priori, ognideriva importante del tempo del SYST deve essere messa in discussione(Capitolo 6.2).

<I> < INFORMATION TEMPS D’EXECUTION > (EN SECONDE)TEMPS CPU TOTAL .............. 2160.55TEMPS CPU USER TOTAL ......... 2099.33TEMPS CPU SYSTEME TOTAL ...... 61.22TEMPS CPU RESTANT ............ 439.45

Figura 8: Impiego globale di tempo in un calcolo (estratto da un .mess)

4.3 Caso particolare di DYNA_NON_LINE e STAT_NON_LINE

In ogni passaggio temporale o incremento del calcolo nell’ambito dei comandiDYNA_NON_LINE e STAT_NON_LINE, oltre alla tabella di decadimento deiresidui (il livello dei dettagli è gestito dalla parola AFFICHAGE del comando),si tracciano come impostazione predefinita (INFO = 1) i seguenti elementi:

• Campi memorizzati (selezionati mediante la parola chiave ARCHIVAGE)

• Ripartizione dei tempi CPU consumati e, possibilmente, il numero diiterazioni associate (ad esempio: processo di Newton)

• Blocchi display dedicati (ad esempio: contatto discreto)

I campi di archiviazione possono richiedere molto tempo (soprattutto inparallelo) e in memoria. È quindi interessante analizzare l’elenco dei campiarchiviati al fine di limitarli.

11

ARCHIVAGE DES CHAMPS:CHAMP STOCKE : CONT_NOEU INSTANT :5.00000E+02 NUMERO D’ORDRE : 50CHAMP STOCKE : DEPL INSTANT :5.00000E+02 NUMERO D’ORDRE : 50CHAMP STOCKE : SIEF_ELGA INSTANT :5.00000E+02 NUMERO D’ORDRE : 50CHAMP STOCKE : VARI_ELGA INSTANT :5.00000E+02 NUMERO D’ORDRE : 50CHAMP STOCKE : VITE INSTANT :5.00000E+02 NUMERO D’ORDRE : 50CHAMP STOCKE : ACCE INSTANT :5.00000E+02 NUMERO D’ORDRE : 50

TEMPS CPU CONSOMME DANS CE PAS DE TEMPS: 0 sTEMPS PAR ITERATION DE NEWTON : 0 s - NBRE NEWT. : 2TEMPS ARCHIVAGE : 0 sTEMPS CREATION NUMEROTATION : 0 s - NBRE NUME. : 0TEMPS FACTORISATION MATRICE : 0 s - NBRE FACT. : 0TEMPS INTEGRATION COMPORTEMENT : 0 s - NBRE INTE. : 3TEMPS RESOLUTION K.U = F : 0 s - NBRE RESO. : 2TEMPS RESOLUTION CONTACT : 0 s - NBRE ITER. : 2TEMPS AUTRES OPERATIONS : 0 s

CONTACT DISCRET:NOMBRE D’ITERATIONS DE CONTACT : 2NOMBRE D’ITERATIONS DE REAC. GEOM : 2NOMBRE FINAL DE LIAISONS DE CONTACT : 0TEMPS TOTAL APPARIEMENT : 0 sTEMPS TOTAL RESOLUTION : 0 s

Campi archiviati da limitare(soprattutto in parallelo)

Ripartizione del tempoCPU per le iterazioni

Solo queste parti possonobeneficiare del parallelismo

Figura 9: Visualizzazione di ogni passaggio nei comandi DYNA_NON_LINEe STAT_NON_LINE con INFO = 1 in modalità sequenziale (estratto da unfile .mess)

Alla fine del comando sono riepilogate le statistiche globali su tutti itransitori. Questi tempi della CPU si trovano nelle statistiche generali sull’o-peratore riportate nel paragrafo precedente. D’altra parte, la loro granularitàè più fine e adattata alle diverse fasi dell’operatore.

12

---------------------------------------------------------------------------------STATISTIQUES SUR LE TRANSITOIRE---------------------------------------------------------------------------------

NOMBRE DE PAS DE TEMPS : 100NOMBRE D’ITERATIONS DE NEWTON : 200NOMBRE D’ITERATIONS DE CONTACT (ALGO) : 456NOMBRE D’ITERATIONS DE CONTACT (GEOM) : 200NOMBRE DE CREATION DE NUMEROTATION : 1NOMBRE DE FACTORISATION DE MATRICE : 2NOMBRE D’INTEGRATION DE COMPORTEMENT : 201NOMBRE DE RESOLUTION K.U = F : 200TEMPS POUR CREATION NUMEROTATION : 10 sTEMPS POUR FACTORISATION MATRICE : 100 sTEMPS POUR INTEGRATION COMPORTEMENT : 3 m 8 sTEMPS POUR RESOLUTION K.U = F : 9 sTEMPS POUR CONTACT (APPARIEMENT) : 17 sTEMPS POUR CONTACT (ALGORITHME) : 2 m 30 s

---------------------------------------------------------------------------------

Figura 10: Statistiche globali alla fine dei comandi DYNA_NON_LINE eSTAT_NON_LINE con INFO = 1 (estratto di un file .mess)

13

5 Consumo di memoria RAMIn qualsiasi momento, la memoria RAM utilizzata da Code-Aster può essererappresentata dall’accumulo di tre componenti:

• La memoria allocata direttamente dalle fonti del codice. Questo èprincipalmente quella assegnata dal software JEVEUX [D6.02.01] pergestire tutte le strutture di dati F77 del codice. Questo pacchettoconsente inoltre di scaricare sul disco questi oggetti (funzionalità out-of-core). A seconda della dimensione del problema, della dimensione dellaRAM e delle raccomandazioni del programmatore, JEVEUX effettuascambi di dati più o meno pronunciati tra il disco e la RAM.

• La memoria utilizzata da un software esterno sollecitato dal calcoloAster (MUMPS/PETSC, METIS/SCOTCH, HOMARD, MISS3D, . . . ). Lamaggior parte dei software esterni funziona in modalità in-core. Cioè,non gestiscono direttamente alcun overflow di memoria ed esternalizzanoquesta attività al sistema operativo. Altri, come il risolutore lineareMUMPS, sono potenzialmente out-of-core e gestiscono esplicitamente loscarico su disco di alcuni oggetti di grandi dimensioni (vedere l’opuscolodella parola chiave SOLVEUR alla voce GESTION_MEMOIRE [U4.50.01]).

• La memoria richiesta dal sistema (caricamento parte dell’eseguibi-le, livello di rete in parallelo, . . . ), dal supervisore e dalle libreriePython.

Quando si utilizza un operatore Code-Aster che richiede la costruzione e la riso-luzione di un sistema lineare (ad esempio: STAT_NON_LINE, CALC_MODES,. . . ), i limiti di memoria sono spesso imposti dal risolutore lineare (docu-menti [U4.50.01] e [U2.08.03]). Quando si tratta di solutori interni (LDLT,MULT_FRONT, GCPC), i loro consumi di RAM si trovano nei display diJEVEUX. D’altra parte, quando si utilizza un prodotto esterno (MUMPS oPETSC), è quindi necessario tenere conto del proprio consumo (che sostituisceampiamente quello di JEVEUX).

14

Tempocalcolo

RAM

MemoriaJEVEUX

MemoriaMUMPS

Costruzionesistema lineareKu = F

RisoluzioneMUMPSusol

Figura 11: Diagramma di evoluzione del consumo di RAM durante un calcolostandard in meccanica lineare

5.1 Calibrazione della memoria di un calcolo

È spesso interessante calibrare a livello di memoria RAM un calcolo Aster.Ciò può, ad esempio, consentire di ottimizzare il posizionamento in unaclasse batch (sequenziale o parallela) o semplicemente evitare il suo arrestoimprovviso a causa di un difetto di memoria. Per fare ciò, possiamo procederecome segue:

• Passo 1: Individuare nello stato di avanzamento del calcolo l’operatoreche sembra il più grande in termini di dimensioni del problema (spessosono gli operatori STAT_NON_LINE, DYNA_NON_LINE, CALC_MODES,. . . a trattare il modello più grande).

• Passo 2: In caso contrario, parametrizzare il blocco SOLVEUR diquesto operatore con METHODE = ’MUMPS’ e MANAGE_MEMOIRE= ’EVAL’. Alla fine della calibrazione, probabilmente pensare diripristinare le vecchie impostazioni.

• Passo 3: Avviare il calcolo così com’è con modesti parametri di me-moria e tempo rispetto ai consueti consumi di questo tipo di calcolo.Infatti, con questa opzione, Code-Aster costruirà il primo sistema linearedell’operatore e lo trasmetterà a MUMPS per l’analisi. Quest’ultimo noneseguirà il suo costoso passo (in termini di tempo e soprattutto di memo-ria) della fattorizzazione numerica. Una volta completata questa analisi,

15

le stime della memoria MUMPS (MUEIC e MUEOOC), insieme a quelladi JEVEUX (JEOOC), vengono tracciate nel file dei messaggi (vedere laFigura 12). Quindi il calcolo si interrompe in ERREUR_FATALE perconsentire di passare il più rapidamente possibile al passaggio successivo.

******************************************************************************- Taille du systeme lineaire: 500000

- Memoire RAM minimale consommee par Code_Aster : 200 Mo- Estimation de la memoire Mumps avec GESTION_MEMOIRE = ’IN_CORE’ : 3500 Mo- Estimation de la memoire Mumps avec GESTION_MEMOIRE = ’OUT_OF_CORE’ : 500 Mo- Estimation de l’espace disque pour Mumps avec GESTION_MEMOIRE = ’OUT_OF_CORE’ : 2000 Mo

===> Pour ce calcul, il faut donc une quantite de memoire RAM au minimum de- 3500 Mo si GESTION_MEMOIRE = ’IN_CORE’,- 500 Mo si GESTION_MEMOIRE = ’OUT_OF_CORE’

En cas de doute, utilisez GESTION_MEMOIRE = ’AUTO’

******************************************************************************

JEOOCMUEIC

MUEOOC

Figura 12: Visualizzazione nel file dei messaggi in modalità ’EVAL’

• Passo 4: Sfruttamento delle stesse memorie stimate. Per riavviare ilcalcolo con il risolutore lineare MUMPS, si ha accesso diretto ai valoripiatti della memoria RAM indispensabili per il calcolo. Esistono duediversi scenari in base alla modalità di gestione della memoria sceltaper MUMPS:

– In-Core (IC): Si considera il valore massimo tra JEOOC e MUEIC ,con GESTION_MEMOIRE = ’IN_CORE’

– Out-Of-Core (OOC): Si considera il valore massimo tra JEOOC eMUEOOC , con GESTION_MEMOIRE = ’OUT_OF_CORE’

A seconda della macchina e delle classi batch disponibili, è quindinecessario riavviare il calcolo completo modificando eventualmente anchequesto parametro del blocco SOLVEUR. Queste stime sono stabiliteper un determinato computer e per una determinata configurazionenumerica: piattaforma hardware, librerie, numero di processi MPI,rinumerazione, pre-elaborazione, . . .

• Passo 5: Riavviare il calcolo completo modificando eventualmente laparametrizzazione del blocco SOLVEUR e impostando Astk con il valorededotto nel Passo 4 (sezione Total Memory (MB) della Figura 14.

16

Osservazione

Questa procedura di calibrazione della memoria per uno studioAster è disponibile solo dai valori di ritorno della parola chiaveGESTION_MEMOIRE di SOLVEUR (a partire dalla versione v11.2di Code-Aster). Per le versioni precedenti, se il calcolo è già statoavviato (e se si dispone di un file di messaggi utilizzabile) possiamoriprendere con cautela, come stima ottimale della memoria richiesta,il valore più alto di tutti processori di VmPeak dell’ultimo operatore.In caso contrario, procedere come indicato nelle versioni precedenti diquesto documento:

• Passo 1: Come il precedente

• Passo 2: Impostare il blocco SOLVEUR con le parole chia-vi: METHODE = ’MUMPS’, OUT_OF_CORE = ’OUI’ e conINFO = 2.

• Passo 3: Avviare il calcolo limitando il consumo nel tempo(ad esempio, con poco tempo oppure con ricerca di alcuni modipropri)

• Passo 4: In base alla modalità di gestione della memoria MUMPSrichiesta (In-Core (IC) o Out-Of-Core (OOC)), prendere ilmassimo della stima di MUMPS e del consumo JEVEUX.

5.2 Impiego di memoria per JEVEUX

Gli elementi per valutare il consumo di memoria di JEVEUX sono tracciati allafine di ciascun operatore Aster (vedere Figura 13). A grandi linee, possiamospiegarli nel modo seguente:

• JEOOC fornisce la dimensione minima (’Minimum’) di cui JEVEUX habisogno per operare fino a questo operatore. Sarà quindi completamenteOut-Of-Core (OOC). Al di sotto di questo valore, il calcolo non èpossibile (nella configurazione selezionata)

• JEIC fornisce un limite inferiore (’Optimum’), fino a questo operatore,della memoria JE ′

IC necessaria a JEVEUX per operare completamentein modalità In-Core (IC). Con almeno questo valore di RAM impostatoin Astk (vedi MEMASTK), il calcolo verrà eseguito in modo ottimale:

17

non vi è alcun rischio di un errore a causa della mancanza di memoria egli accessi alle strutture dati puramente Aster saranno un pò rallentatedagli scaricamenti su disco.

Questi due numeri sono necessariamente inferiori al valore totale della memoriaRAM dedicata al calcolo (parametrizzata in Astk), vedi MEMASTK .

# Statistiques memoire(Mo): 15521.78/ 8920.14/ 1603.77/ 248.27(VmPeak/VmSize/Optimum/Minimum)

SYS1 SYS2 JEIC JEOOC

Figura 13: Statistiche globali alla fine del comando (estratto da un file .mess)

MEMASTK è il numeroinserito nella casellaTotal Memory (MB)

Figura 14: Parametrizzazione in Astk della memoria RAM

18

Osservazione

Se non esiste un meccanismo globale di rilascio della memoria (ve-dere il paragrafo seguente), JEIC rappresenta davvero la memoriaJEVEUX necessaria per operare in In-Core (IC). In caso contra-rio, quest’ultima stima deve essere vicina alla somma11 di JE ′

IC =JEIC + "il guadagno medio fornito da ciascun rilascio". È quindi inu-tile (se non si utilizza un prodotto esterno) impostare il calcolo conun valore molto superiore a JE ′

IC .

Quando si imposta il calcolo, è necessario stabilire un compromesso trala sua velocità e il suo consumo di memoria. Dando priorità al consumo dimemoria di tutti i comandi, si può identificare quello che dimensiona il calcolo.In una configurazione di calcolo fissa (numero di processori), più lo spazio dimemoria riservato a JEVEUX sarà grande, più il calcolo sarà In-Core (IC) equindi sarà più veloce. Si può anche, secondo le contingenze dei file di attesadel batch, tagliare il suo calcolo in diversi POURSUITE in modo da variegaree quindi ottimizzare le impostazioni tempo/memoria.

0 JEOOC JE ′IC

JEIC

Limite OOC Limite IC Memoria impostataper JEVEUX

Dimensioneminima peril calcolo

Calcolosempre

più veloce

Memorianon

utilizzata

Figura 15: Significato dei display relativi a JEVEUX nel file dei messaggi

11Una strategia per determinare esattamente il punto operativo In-Core (IC) per JEVEUXè aumentare gradualmente il valore di MEMASTK , quindi il valore di JEIC deve quindiaumentare. Appena quest’ultima smette di variare, significa che abbiamo raggiunto il puntooperativo ottimale che consente a JEVEUX di funzionare completamente in In-Core (IC):JE′

IC .

19

Durante il calcolo, JEVEUX può scaricare sul disco gran parte degli oggetticontenuti nella memoria RAM. Questo meccanismo è:

• Automatico (spazio RAM insufficiente per creare un oggetto o rimpa-triarlo)

• Gestito dal programmatore (ad esempio: una chiamata a questo mecca-nismo di rilascio prima di passare a MUMPS))

Le statistiche relative a questo meccanismo sono riassunte alla fine del filedei messaggi (vedere Figura 16) per tutti i comandi. Ovviamente, più questomeccanismo interviene (e su grandi volumi di memoria rilasciata), più ilcalcolo viene rallentato (tempo SYST e tempo ELAPS che crescono mentre iltempo USER di CPU rimane stabile). Questo fenomeno può essere accentuatoin modalità parallela (memorie simultanee) in base alla distribuzione deiprocessori sui nodi di calcolo e in base alle caratteristiche della macchina.

STATISTIQUES CONCERNANT L’ALLOCATION DYNAMIQUE:TAILLE CUMULEE MAXIMUM : 1604 MoTAILLE CUMULEE LIBEREE : 52117 MoNOMBRE TOTAL D’ALLOCATIONS : 1088126NOMBRE TOTAL DE LIBERATIONS : 1088126APPELS AU MECANISME DE LIBERATION : 1TAILLE MEMOIRE CUMULEE RECUPEREE : 1226 MoVOLUME DES LECTURES : 0 MoVOLUME DES ECRITURES : 1352 Mo

MEMOIRE JEVEUX MINIMALE REQUISE POUR L’EXECUTION : 248.27 Mo- IMPOSE DE NOMBREUX ACCES DISQUE- RALENTIT LA VITESSE D’EXECUTION

MEMOIRE JEVEUX OPTIMALE REQUISE POUR L’EXECUTION : 1603.77 Mo- LIMITE LES ACCES DISQUE- AMELIORE LA VITESSE D’EXECUTION

JEOOC

JEIC

Figura 16: Statistiche del meccanismo di rilascio di JEVEUX (estratto da unfile .mess)

Queste statistiche riassumono anche le stime JEIC e JEOOC descritte inprecedenza.

Osservazione

I possibili costi aggiuntivi nel tempo di tali scarichi sono registratialla fine degli operatori interessati (vedere Capitolo 4.1.1). In casodi mancanza di RAM, si può diagnosticare attraverso il parametroVmPeak (vedere Capitolo 5.4).

20

5.3 Impiego di memoria per i prodotti MUMPS

Per ora, l’unico prodotto esterno il cui consumo di memoria RAM è realmenteridimensionabile, è il prodotto MUMPS. Possiamo tracciare i suoi consumi(In-Core (IC) e Out-Of-Core (OOC)) in due modi:

• Tramite un pre-calcolo molto rapido ed economico in memoria tramitela modalità GESTION_MEMOIRE = ’EVAL’ (vedi Capitolo 5.1). Maqueste sono solo stime (valori MEIC e MEOOC di Figura 12). Possonoquindi essere un pò pessimistiche (specialmente in out-of-core e/o inparallelo). In modalità parallela, tracciamo solo le stime del processoMPI che impiega più memoria.

• Con il calcolo standard (se possibile limitato a pochi passaggi tempora-li o ad alcuni modi propri) aggiungendo la parola chiave INFO = 2 nelcomando che impiega più memoria. Riassumiamo quindi nel file dei mes-saggi (vedere Figura 17), non solo le stime di memoria precedenti MEICe MEOOC (colonne ESTIM IN-CORE e ESTIM OUT-OF-CORE), maanche il consumo effettivo, modalità selezionataMRIC/OOC (qui in moda-lità OOC perché visualizza RESOL OUT-OF-CORE). Ad esempio, nellaFigura 17, si dovrebbe leggere: "Le stime di MUMPS richiedono almenoMEOOC = 478 MB per processore per funzionare in OOC. Per passarea IC (calcolo più veloce), stima di aver bisogno di almeno MEIC = 964MB. In pratica, ha consumato esattamente MRIC/OOC = 478 MB inOOC (la stima è perfetta: MEIC/OOC = MRIC/OOC). In modalità pa-rallela, si riepilogano le cifre per ogni MPI di processo, nonché i lorominimi, massimi e medi. È un display con vocazione di competenzapiù dettagliato rispetto al display della modalità MANAGE_MEMOIRE= ’EVAL’. Oltre a queste informazioni sul consumo di RAM, riepilogaanche elementi relativi al tipo di problema, alla sua difficoltà numerica(errori) e alla sua distribuzione parallela (bilanciamento del carico).

21

******************************************************************************< MONITORING DMUMPS 4.8.4 >TAILLE DU SYSTEME 210131RANG NBRE MAILLES NBRE TERMES K LU FACTEURSN 0 : 5575 685783 45091154N 1 : 8310 1067329 51704129N 2 : 11207 1383976 53788943...N 7 : 8273 1039085 4560659--------------------------------------------------------------TOTAL : 67200 8377971 256459966

MEMOIRE RAM ESTIMEE ET REQUISE PAR MUMPS EN Mo(FAC_NUM + RESOL)RANG ASTER : ESTIM IN-CORE | ESTIM OUT-OF-CORE | RESOL. OUT-OF-COREN 0 : 869 478 478N 1 : 816 439 439N 2 : 866 437 437...N 7 : 754 339 339-----------------------------------------------------------------------------MOYENNE : 5.92D+02 3.50D+02 3.50D+02-----------------------------------------------------------------------------MINIMUM : 7.54D+02 3.39D+02 3.39D+02-----------------------------------------------------------------------------MAXIMUM : 9.64D+02 4.78D+02 4.78D+02-----------------------------------------------------------------------------

******************************************************************************

MEIC MEOOC MROOC

Figura 17: Memoria impiegata per ogni processore (stimata ed effettiva) delprodotto esterno MUMPS (visualizzato in un file .mess con INFO = 2)

Osservazione

Secondo il tipo di calcolo (sequenziale, parallelo centralizzato o paral-lelo distribuito), il numero di processori, la modalità d’uso di JEVEUX(parola chiave MATR_DISTRIBUEE di SOLVEUR) e la memoria MUMPSdel gestore (parola chiave GESTION_MEMOIRE di SOLVEUR), la ge-rarchia la memoria può tuttavia essere spinta. In modalità paralleladistribuita, la memoria di picco JEVEUX diminuirà con il numero diprocessori non appena verrà attivato MATR_DISTRIBUEE. Questosarà anche il caso di MUMPS, qualunque sia la modalità di paralleli-smo (specialmente in IC). Inoltre, anche il passaggio di MUMPS dallamodalità IC alla modalità OOC riduce drasticamente la sua memoriadi picco. Il display in INFO = 2 dei consumi RAM di MUMPS perprocessore informa sui possibili squilibri del carico di memoria. Sipuò provare a limitarli modificando l’euristica di programmazione delprodotto: parametri SOLVEUR, PRETRAITEMENTS, RENUM oppureil numero di processori.

22

0 MEOOCMROOC/IC

MEIC

Limite OOC Limite IC Memoria impostataper MUMPS

Dimensioneminima peril calcolo

Calcolosempre

più veloce

Memorianon

utilizzata

Figura 18: Significato dei display relativi a MUMPS nel file dei messaggi

5.4 Impiego di sistema

Gli unici consumi di sistema menzionati nel file di messaggi riguardano lamemoria globale del lavoro in questo momento di calcolo (VmSize) e il suopicco dall’inizio (VmPeak). Viene tracciato alla fine di ciascun comando(vedere le voci SYS1 e SYS2 della Figura 13). Il termine VmPeak è riassuntoalla fine del file di messaggi (vedere la Figura 19).

MAXIMUM de MEMOIRE UTILISEE PAR LE PROCESSUS : 15107.89 Mo- COMPREND LA MEMOIRE CONSOMMEE PAR JEVEUX,

LE SUPERVISEUR PYTHON, LES LIBRAIRIES EXTERNES

SYS1

Figura 19: VmPeak finale di un processo su Unix

In evidenza VmPeak fornisce informazioni sul picco delle dimensioni dellamemoria causato da tutti gli eseguibili attivi del lavoro Aster. È necessarioassicurarsi che questa cifra rimanga inferiore alla memoria fisica disponibileper il lavoro. Altrimenti il sistema, in una certa misura, cambierà e questorallenterà il calcolo. A livello del pacchetto software JEVEUX, ciò comporteràun maggiore scarico (vedere Capitolo 4.1.2 e Capitolo 5.2), a livello dei prodottiesterni questo comporteà un divario dei tempi ELAPS/USER crescente (tramaalla fine dell’ordine vedere Capitolo 4.1.1).

23

Osservazioni se SOLVEUR = ’MUMPS’

Dal ritorno della parola chiave GESTION_MEMOIRE di SOLVEUR (dal-la versione v11.2 di Code-Aster), si consente al solutore di diffondersinella memoria (a complemento delle allocazioni di JEVEUX, del super-vi) fino ad occupare la dimensione massima assegnata. Ciò consente alprodotto di essere più veloce e meno ingombrante per quanto riguardale esigenze di memoria in termini di pivoting. D’altra parte, corollariodi questa strategia di occupazione ottimale delle risorse di memoria,il VmPeak visualizzato nel file dei messaggi diventa dipendente dallamemoria allocata al calcolo (MEMASTK o terminale della classe batch).Non può quindi essere utilizzato, come in precedenza, per calibrarel’impiego minimo di memoria dello studio. Per fare ciò, è necessarioapplicare la strategia dettagliata del Capitolo 5.1.

24

6 Alcuni consigli per ottimizzare le prestazioniEcco alcuni suggerimenti per aiutare l’utente a trarre vantaggio dalla diagno-stica tracciata nel file dei messaggi. Ma dobbiamo essere consapevoli che nonesiste una ricetta universale per ottimizzare le prestazioni complessive di uncalcolo. Dipende dal tipo di studio, dagli aspetti software e hardware dellamacchina, e persino dal suo carico di lavoro.

Le impostazioni predefinite e i display/allarmi del codice forniscono unfunzionamento bilanciato e strumentato. Tuttavia, per essere sicuri di aversfruttato al meglio le capacità della macchina, l’utente deve rimanere attentoagli elementi descritti in questo documento, nonché ai suggerimenti cheabbondano nella documentazione dei comandi.

Elenchiamo di seguito, in modo non esaustivo, alcune domande che sonointeressanti da porre quando si cerca di ottimizzare le prestazioni del suocalcolo. Naturalmente, alcune domande (e risposte) sono cumulative e possonoquindi applicarsi contemporaneamente.

6.1 Riguardo alle caratteristiche del problema

Alla luce degli elementi del Capitolo 3, si possono formulare due regoleempiriche:

• Aumentare la dimensione del problema N e/o il riempimento dellamatrice NNZ , rende la costruzione e (soprattutto) la risoluzione delsistema lineare più costosa (in termini di CPU/RAM).

• Aumentare la proporzione di Lagrange NL/N può rendere più difficilerisolvere il sistema lineare (tempo di esecuzione, qualità della soluzione).

• La dimensione del problema determina il numero massimo di proces-sori che è rilevante dedicare al suo calcolo parallelo: è richiesta unagranularità di almeno 20× 103 gradi di libertà per processo MPI.

6.2 Riguardo al tempo impiegato

Per ridurre i tempi della CPU, l’utente Aster ha diversi strumenti:

• Se la maggior parte dei costi riguarda calcoli elementari/assemblaggie/o risoluzioni di sistema lineari (vedere Capitolo 4.1), si consiglia diutilizzare Aster in modalità parallela. È quindi preferibile utilizzare il

25

risolutore lineare MUMPS in modalità a memoria distribuita (MPI) o ilrisolutore MULT_FRONT in modalità a memoria condivisa (OpenMP).La prima strategia consente inoltre di ridurre il consumo di RAM perprocessore

• Se si utilizza già il risolutore lineare MUMPS, è possibile disabilita-re le funzionalità di Out-Of-Core (OOC)12 (GESTION_MEMOIRE =’IN_CORE’) e il miglioramento della qualità della soluzione (RESI_RELA= - 1.d0). Se la matrice è ben condizionata e/o non simmetrica, sipossono anche provare i parametri di rilassamento del risolutore lineare(FILTRAGE_MATRICE, MIXER_PRECISION, SYME)

• Se si esegue un calcolo non lineare, è possibile provare i vari parametridi rilassamento del solutore non lineare (REAC_INCR, REAC_ITER,SYME)

• Se si esegue un calcolo modale, si consiglia l’uso del metodo IRAM(METHODE = ’SORENSEN’) e la divisione dello spettro ricercato indiverse bande di frequenza (tramite l’operatore CALC_MODES conOPTION = ’BANDE’ ritagliata in diverse sotto-bande)

• In generale, più il funzionamento di JEVEUX (ed anche di MUMPS) èin modalità In-Core (IC) (vedere Capitolo 5.1), più il calcolo è veloce.Questi guadagni non sono tuttavia molto importanti rispetto a quelliche può fornire il parallelismo e la scelta di un risolutore adatto (conrelativa impostazione).

Per ogni fase del calcolo, si dovrebbe normalmente avere un "tempo disistema" basso (SYST) e un "tempo CPU + tempo di sistema" cumulati-vo (USER+SYST) molto vicino al tempo di attesa reale (ELAPS). In casocontrario, possono insorgere due casi classici:

• Il tempo USER+SYST è molto superiore del tempo ELAPS. Il calcoloutilizza certamente il parallelismo a memoria condivisa (OpenMP) dellestrategie parallele 1c o 2a descritte nel documento [U2] sul parallelismoe nel Capitolo 2.2 della documentazione [U4.50.01] dei risolutori. Questasituazione non è preoccupante (e nemmeno desiderata), l’importante èche il tempo di ritorno del calcolo sia il più basso possibile!

12Ciò può essere interessante quando si osservano le spese generali I/O nei passaggi 1.3e 1.4 (Figura 4) tramite un tempo SYST non trascurabile e un tempo ELAPS molto piùelevato del tempo USER.

26

• Il tempo ELAPS è molto più alto del tempo USER e/o il tempo SYST ri-sulta importante. Il calcolo probabilmente soffre di problemi di memoria(swap di sistema, I/O RAM/disco, . . . ):

– Traccia 1: Questo costo aggiuntivo può derivare dagli scarichiglobali di JEVEUX. Per convincersene basta leggere, alla fine del file.mess, le statistiche relative all’allocazione dinamica (Capitolo 5.2)oppure agli impieghi nel tempo dei diversi scarichi (Capitolo 4.1).Maggiore è il numero di chiamate ai meccanismi di rilascio e/ogli oggetti rilasciati sono di grandi dimensioni, maggiori sarannoi tempi di SYST ed ELAPS. Una soluzione è quindi quella diaumentare la dimensione della memoria devoluta a JEVEUX

– Traccia 2: Come corollario dell’osservazione precedente, la mo-dalità parallela MPI tende ad aumentare i costi aggiuntivi dovutiallo scarico. In effetti, la distribuzione dei dati indotti dal paralle-lismo diminuirà la dimensione degli oggetti JEVEUX (se è attivatoMATR_DISTRIBUEE di SOLVEUR) e quindi limiterà l’impattodegli scarichi. D’altra parte, questi possono verificarsi contempora-neamente e su processori contigui. Una soluzione alternativa puòquindi essere quella di "incasinare" il processore, interlacciandoi processori MPI attivi con i processori dormienti (ad esempio:inizializzato su 2 il valore "ncpus" di Astk)

– Traccia 3: Se si utilizza il risolutore lineare MUMPS in modalitàOut-Of-Core (OOC), il problema può derivare da un gran numerodi elementi nell’algoritmo forward-backward del solutore (vedere ilpunto 1.4 del Capitolo 4.1). Possono essere limitati scollegandol’opzione di perfezionamento automatico (RESI_RELA = -1.d0)oppure tornando in modalità In-Core (IC) (se le risorse di memorialo consentono).

6.3 Riguardo alla RAM impiegata

• Se i consumi JEIC e JEOOC sono vicini (poche decine di percentua-li), è perché JEVEUX ha dovuto operare spesso in modalità Out-Of-Core (OOC). Probabilmente c’erano molti scaricamenti di memoria(vedi Capitolo 4.1 e Capitolo 5.2). Il tempo di calcolo può risentirne(soprattutto in parallelo). È necessario provare ad aggiungere memoriao aumentare il numero di processori (se l’opzione MATR_DISTRIBUEEè attivata).

27

• Il calcolo viene spesso dimensionato in memoria, dal massimo, sull’o-peratore che richiede più memopria, tra il valore di base di JEVEUX(JEOOC) e il valore utilizzato dal risolutore lineare MUMPS (se utilizzato).Per ridurre questo numero possiamo giocare su diversi fattori:

– Se si utilizza MUMPS e questo è predominante (spesso accade):utilizzare più processori in modalità a memoria distribuita (MPI)(parametri mpi_nbcpu e mpi_nbnoeud di Astk), passare in Out-Of-Core (OOC) (parola chiave GESTION_MEMOIRE di SOLVEUR).Se la matrice è ben condizionata e/o non simmetrica, si possonoanche provare i parametri di rilassamento del risolutore lineare(FILTRAGE_MATRICE, MIXER_PRECISION, SYME)

– Se si utilizza MUMPS e quest’ultimo non è predominante: utilizzarela distribuzione di oggetti JEVEUX dell’opzione MATR_DISTRIBUEEin modalità parallela

– Se si utilizza un altro solutore lineare: utilizzare MUMPS in paralleloo anche GCPC o PETSC (in sequenza o in parallelo).

6.4 Riguardo al parallelismo

• Se la maggior parte dei costi riguarda calcoli elementari/assemblaggie/o risoluzioni di sistemi lineari (vedere Capitolo 4.1), si consiglia diutilizzare Aster in modalità parallela. È quindi preferibile utilizzare ilrisolutore lineare MUMPS in modalità a memoria distribuita (MPI) (vedidocumento [U2] sul parallelismo oppure [U4.50.01] sui solutori linea-ri) oppure il solutore MULT_FRONT in modalità a memoria condivisa(OpenMP)

• È meglio limitare il parallelismo del calcolo solo ai pochi operatori costosi(in termini di tempo/memoria): STAT_NON_LINE, DYNA_NON_LINE,CALC_MODES, . . .

Quindi, se possibile, suddividerlo in una successione di pre/post-trattamentie calcoli paralleli. Durante lunghi calcoli (alcuni giorni), questa strategiaconsente inoltre di proteggersi meglio da possibili arresti errati salvandoil database associato a ciascuna fase principale del calcolo

• È interessante validare preventivamente il suo calcolo parallelo confron-tando alcune iterazioni in modalità sequenziale e in modalità parallela.Inoltre, questo approccio consente anche di calibrare i guadagni massimiottenibili (accelerazione teorica) e quindi di evitare troppi "sprechi diprocessori". Pertanto, se f è la porzione parallizzabile del codice (ad

28

esempio: determinata tramite una precedente esecuzione sequenziale),la massima accelerazione teorica (speed-up) Sp ottenibile su un numerodi processori p viene calcolato secondo la formula di Amdhal (vedereCapitolo 2.4 della documentazione [R6.01.03]):

Sp =1

1− f +f

p

(1)

Ad esempio, se utilizziamo il parallelismo a memoria distribuita (MPI)per impostazione predefinita (strategie 1b + 2b, vedi la documentazione[U2] sul parallelismo) e se i passaggi 1.3, 1.4 e 2 (vedi Capitolo 4.1)rappresentano il 90% del tempo sequenziale (f = 0.90), l’accelerazioneteorica è limitata al valore:

S∞ =1

1− 0.9 +0.9

∞

= 10 (2)

E questo, qualunque sia il numero di processi MPI assegnati

• Per ottimizzare il calcolo parallelo, è necessario monitorare i possibilisquilibri dei carichi del flusso di dati (CPU/RAM) e limitare i costiaggiuntivi dovuti alla memoria di scarico (JEVEUX e MUMPS Out-Of-Core (OOC)) (vedi Capitolo 4.1) e con l’archiviazione dei campi (vediCapitolo 4.3). Per risparmiare tempo di calcolo, è inoltre necessariovietare qualsiasi procedura di rielaborazione della memoria (parolachiave RETASSAGE di FIN) che risulta controproducente in parallelo

• L’uso del parallelismo a memoria distribuita (MPI) di MUMPS con-sente di risparmiare nel tempo CPU (sugli stadi parallelizzati) e nel-la RAM: grazie alla distribuzione dei dati di JEVEUX (se l’opzioneMATR_DISTRIBUEE è attivata) e, soprattutto, grazie a quella deglioggetti MUMPS

• Alcune cifre empiriche: è consigliabile assegnare almeno 20× 103 gradidi libertà per ogni processo MPI. Un calcolo termomeccanico standardgeneralmente avvantaggia, su 32 processori, un guadagno dell’ordine di10 nel tempo trascorso e un fattore 4 nella memoria RAM utilizzata

29

AcronimiAGLA Atelier de Génie Logiciel

BLAS Basic Linear Algebra Subprograms

CPU Central Process Unit

CSC Compressed Sparse Column

CSR Compressed Sparse Row

DAE Differential Algebraic Equations

EDF Electricité Dé France

GMRES Generalized Minimal RESidual method

GUI Graphic User Interface

HDF Hierarchical Data Format

HPC High-performance Computing

HYPRE High-performance PREconditioners

IC In-Core

LMP Limited Memory Preconditioneer

MG Multi Grid method

MPI Message Passing Interface

MUMPS MUltifrontal Massively Parallel Sparse direct solver

ODE Ordinary Differential Equations

OOC Out-Of-Core

OpenMP Open Multi Processing

PETSc Portable Exstesible Toolkit for Scientific computations

RCP Remote Copy

REX Return of EXperience

30

RD Research and Development

RG Regular Grid

RRQR Rank Revealing QR

RSH Remote Shell

ScaLAPACK Scalable Linear Algebra PACKage

SCP Secure Copy

SDS Sparse Direct Solver

SSF Sparse matrix Storage Formats

SSH Security Shell

UG Unstructured Grid

31