Aller au contenu. | Aller à la navigation

Outils personnels

Navigation

2022/02/07

Compte rendu du poihl du 22/02/2022

Liens utiles:


Généralités:

  • point traceurs: moratoire toujours en cours: suite aux différentes commissions, on ne retrouve pas la convergence pour les traceurs non-eau sur les tests des différents modes de parallélisation sur jean-zay. On règle le problème (ou on se l'explique) avant de lever le moratoire.
  • Lidia: nous informe de ses tests de convergence de la nouvelle routine lscp_mod.F90. On n'a pas de convergence au bit près mais on retrouve bien le comportement du modèle. A suivre, des tests de contrôle AMIP en L95 avec et sans lscp_mod activé, le tuning actuel étant fait sur le modèle de Ludovic sans lscp_mod
  • Etienne attend la fin du moratoire pour commiter la nouvelle version du 1D qui va impliquer une perte de rétro-compatibilité. Se pose la question de la distribution des cas 1D (dans l'archive ou par git)
  • Sébastien se pose la question de quelle version récupérer pour son travail sur les isotopes. C'est à discuter avec David, Anne, Ehouarn et Laurent (mais surtout David ...)

 

Poihl  'Architecture'

On continue la présentation des modifications apportées à la physique simplifiée pendant le hackathon en regardant le programme appelant. On en profite pour analyser les exemples de routine "plugin" que Thomas a rajouté et qui permettent de brancher à l'exécution, à un code principal, différentes versions d'une routine pour un travail spécifique (branchement, par exemple, de routines de sortie différentes qui sortiraient les variables dans un fichier texte, netcdf, etc ...).

Discussion sur la méthode de travail à engager pour le portage de la physique:

Retrouver ici

https://plmlatex.math.cnrs.fr/project/61d426efaa54ab9e2a21f98a?project_name=LMDZ-GPU

le document partagé de Thomas sur LMDZ-GPU-ré-écriture.

On ré-affirme le fait que le but de la réflexion et du travail engagés est bien de porter le code physique sur GPU mais aussi de ré-écrire la physique du modèle. On se permet donc d'établir une liste au Père Noël (à compléter dans le document de Thomas ci-dessus):

  • Faire tourner des parties de la physique de façon indépendante. Aller plus loin dans l'idée que la physique est compilée comme une libraire indépendante (l'appeler par un driver qui ne soit pas LMDZ, basculer sur un mode dynamique des allocations des tableaux, ... )
  • Pouvoir extraire les données d'entrée d'une routine donnée : paramètres + variables de module
  • Clarifier les interfaces de chaque paramétrisation ; définir une routine d'initialisation ; les variables de module deviennent internes à la paramétrisation
  • Nettoyer et rendre plus lisible le code.
  • Avoir un profiling du code pour savoir sur quel bout mettre l'effort
  • Que tout soit dans des modules
  • Avoir des monitoring successif de la qualité du portage vers GPU

 

On sent bien que l'effort à consentir pour la ré-écriture de la physique risque de retarder le côté portage sur GPU. On s'oriente du coup vers deux dynamiques de travail:

  1. une dynamique de portage vers le GPU 'force-brute' où l'on outillerait avec openacc le code existant de la physique LMDZ routine par routine. On utiliserait comme 'driver' soit dyn3dmem, DYNAMICO (?), un driver simplifié à développer (?)
  2. une dynamique de ré-écriture de la physique en ne considérant pas les modules et routines en tant que tels mais en considérant les modules constituant une paramétrisation comme un tout homogène et indépendant et en développant des interfaces claires entre ces paramétrisations et le moniteur de la physique. La paramétrisation des thermiques et celle de Mellor-Yamada seraient de bons premiers candidats à cette ré-écriture

Deux autres tâches utiles à ces dynamiques seraient

  1. une analyse du code pour savoir ce qui est effectivement utilisé/à garder/à porter/à ré-écrire (voir l'outil de coverage du code https://www.lmd.jussieu.fr/~fairhead/Labo/LMDZ_Coverage/sequential/example-html-details.html?)
  2. un travail sur l'automatisation de l'écriture des paramètres d'entrée et de sortie des routines de paramétrisations physiques pour pouvoir effectuer des exécutions offline et réalistes de ces paramétrisations


Détails pratiques:
Après discussion, les modifications au code apportées par les deux groupes/dynamiques de travail seraient enregistrées et partagées sur des branches indépendantes (une branche GPU, une branche ré-écriture) du dépôt svn. Ces branches seraient mergées  au tronc et 'élaguées' le plus fréquemment possible (avec une recommandation de faire un premier merge de la trunk vers la branche puis de la branche vers la trunk avant de la faire disparaître).

Composition des groupes de travail et forces en présence:
Côté groupe de calcul LSCE, on peut compter sur de l'aide, mais on attend la mise en place effective des dynamiques de travail pour voir où cette aide sera la plus efficace. Côté IPSL, Eliott est prêt à s'investir et côté LMDZ, on retrouve Frédéric, Thomas, Etienne, Jean-Yves, Jean-Baptiste, Ehouarn, Lionel et Laurent. Se constitueraient les groupes de travail suivants:

  • Groupe 'portage GPU': Eliott, Ehouarn, Laurent, ...
  • Groupe 'ré-écriture': Frédéric, Thomas, Etienne, Jean-Yves, Jean-Baptiste, Laurent, ...

Lionel propose son aide pour l'organisation

Calendrier de travail:
Le travail pourrait se faire lors des bocaux LMDZ des jeudis après-midi avec restitution des travaux lors des poihl architecture toutes les 3 semaines. Un premier rendez-vous du groupe 'ré-écriture' est prévu le jeudi 17 février (à confirmer pour Etienne)

Liens d'outils fortran donnés par Thomas pour l'analyse du code:
https://omni-compiler.org/xcodeml.html
https://lfortran.org/

 

Ajouter un commentaire

Vous pouvez ajouter un commentaire en complétant le formulaire ci-dessous. Le format doit être plain text. Les commentaires sont modérés.

Enter the word