Portage IreneAmd

Validation

IPSLCM6.1.11-LR

Configuration IPSL-CM6-LR
Critère contrôlé	Restart historique (H1C=H2C)
Résultats	OK
Commentaires	OK pour 5D + 5D = 10D, 1M + 1M +... = 1Y + 1Y

La configuration IPSLCM6.1.11-LR a été validée sur 50 ans d'expérience piControl. Un inter-monitoring avec les simulations piControl CMIP6 qui ont tourné sur Curie (TGCC) et Jeanzay (IDRIS) est là : ​http://webservices2017.ipsl.fr/interMonitoring/tmp/interMonitoring_plot01_EiRj0s_prod/

Une simulation plus longue de cette même configuration a été réalisée dans le cadre du projet H2020-COMFORT ( historical + ssp585 ). Le monitoring sur lequel on a rajouté une simulation ssp585 ( scen-ssp85-r4 ) réalisée sur Irene-SKL pour comparaison est là : ​http://webservices2017.ipsl.fr/interMonitoring_prefilled/tmp/interMonitoring_plot01_XwZezc_prod/

Performances

IPSLCM6.1.11-LR

A retenir pour IPSLCM6.1.11-LR :

• 20% plus lent que sur Irene-SKL à nombre de coeurs équivalent
• le dépeuplement x2 permet d'aller 60% plus vite (attention, 2 x plus de coeurs sont utilisés).
• les noeuds dédiés pour XIOS sont nécessaires lorsqu'il y a beaucoup d'IOs (attention, 1 noeud supplémentaire (= 128 coeurs) est utilisé).

Les détails :

• IOs standards (sans workflow CMIP6) :
  • Irene AMD sur 940 process ( soit 1024 coeurs ) : 17 SYPD
  • Irene AMD sur 940 process, 1880 coeurs dépeuplés x2 (soit 1920 coeurs) : 28 SYPD
  • Rappel : Irene SKL sur 940 process (soit 960 coeurs) : 21 SYPD

• IO CMIP6 (piControl, sans noeud dediés à XIOS = sur un même noeud il y a des process NEMO et XIOS)
  • Irene AMD sur 940 process ( soit 1024 coeurs ) : 10 SYPD
  • Irene AMD sur 940 process, 1880 coeurs dépeuplés x2 (soit 1920 coeurs) : 12 SYPD
  • Irene AMD sur 940 process, 3760 coeurs dépeuplés x4 (soit 3840 coeurs) : 13.5 SYPD

• IO CMIP6 (piControl, avec noeud dédies à XIOS = sur un même noeud il n'y a que des process clients ou serveurs)
  • Irene AMD sur 940 process (soit 1152 coeurs) : 15 SYPD soit 18400 h/ 10 ans.
  • Irene AMD sur 940 process, 1880 coeurs dépeuplés x2 (soit 2048 coeurs) : 24 SYPD soit 20480h/10 ans
  • Rappel : Irene SKL sur 940 process (soit 960 coeurs) : 19 SYPD soit 12200h/10 ans

A noter que les fonctionalités de dépeuplement et d'utilisation de noeuds dédiés pour les serveurs XIOS ont été implémentées dans libIGCM (voir la documentation ​https://forge.ipsl.jussieu.fr/igcmg_doc/wiki/Doc/ComputingCenters/TGCC/IreneAmd#Useofspecificoptionstoincreasecomputingperformances).

NEMO

• eORCA1-SI3-PISCES-AGE : 1 année de simulation avec la config NEMOv4.0.3, full outputs

	Nb total de coeurs	Temps elapsed	SYPD		Temps CPU
502 mpi nemo + 1 mpi xios	512	2h 30mn	9.6		1250h
( 502 mpi nemo + 1 mpi xios ) dépeuplés x 2	1024	57 mn	25.3		948h
502 mpi nemo + 1 mpi xios sur 1 noeud dédié	640	1h	23.5		650h

Pour des configurations de plus de 400 procs, la meilleure option est celle avec 1 noeud dédié pour XIOS. On peut le voir nettement sur cette figure qui représente des courbes de scalabilité en fonction du type de répartition des processeurs

• ORCA2-SI3-PISCES-AGE ( Tests réalisés par Nicolas Lebas ) : voir sur cette page ​https://forge.ipsl.jussieu.fr/tunevartrop/wiki/model/NEMO
  

Config avec Inca

voir page ​ici

Problèmes rencontrés

• XIOS : des bloquages ont lieu à l'initialisation et à la finalisation. Le problème vient de la libération des communicateurs qui est "en théorie" une communication globale et donc bloquante. La librairie mpi d'irene-amd semble respecter cette règle alors que la librairie mpi d'irene-skl était moins stricte puisqu'il n'y avait pas de blocage. Ces problèmes de blocage arrivent lorsqu'on utilise plusieurs serveurs XIOS (> 6 serveurs). Ces libérations de communicateurs ont été supprimés dans les versions ​https://forge.ipsl.jussieu.fr/ioserver/changeset/1867/XIOS/branchs/xios-2.5 et ​https://forge.ipsl.jussieu.fr/ioserver/changeset/1866/XIOS/trunk.
• Des instabilités sur les performances ont été constatées.
• En comparant 2 simulations (en théorie "identiques") des différences sur des pas de temps non consécutifs sont apparues dans le fichier solver.stat de NEMO. Les restarts de fin de simulation sont pourtant bien identiques. Il a été décidé de compiler en mode "fp-model strict" : les différences n'ont plus été constatées depuis mais comme elles apparaissaient aléatoirement (de façon non reproductible) il est difficile de dire si le problème est complètement résolu.