= Portage !IreneAmd = [[TOC(heading=Table of contents,depth=3)]] == 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/][[BR]][[BR]] 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 (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 (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 * Irene AMD sur 940 process, 1880 coeurs dépeuplés x2 (soit 2048 coeurs) : 24 SYPD * Rappel : Irene SKL sur 940 process (soit 960 coeurs) : 19 SYPD 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é || 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 de scalabilité [[BR]][[BR]] [[Image(perfs_eorca1_nemo4.3_irene_fig1.png, 500px)]][[BR]] * ORCA2-SI3-PISCES-AGE ( Tests réalisés par Nicolas Lebas ) : voir sur cette page [https://forge.ipsl.jussieu.fr/tunevartrop/wiki/model/NEMO][[BR]] === Config avec Inca === voir page [https://forge.ipsl.jussieu.fr/inca/wiki/PortageAMD 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.