Aller au contenu. | Aller à la navigation

Outils personnels

Navigation
Vous êtes ici : Accueil / Le coin des développeurs / CR de réunions / POIHL / 2022/01/17

2022/01/17

Compte rendu du poihl du 17/01/2022

Poihl  'Architecture/développement'

Liens utiles:

 

Questions d'Etienne lancées à la cantonnade:

  • les journées climeri approchent mais pour ceux qui ne connaissent pas vraiment le rôle de climeri dans le paysage de la modélisation en France (comme moi..), quelques éclaircissements seraient bienvenus
  • plus pour le prochain poihl physique:  discussions autour du calcul de l'humidité saturante (il y a des échanges sur le sujet) + discussion autour de la 'masse des précipitations' et de leur effets radiatif
  • et enfin dernier point suite au mail de Pascale Braconnot (qu je recopie ci-dessous). Doit-on et comment participe t-on au sondage pour le prochain CMIP? A l'échelle individuelle? LMDZ? IPSL?

   

Infos générales:

  • Traceurs: David continue ses modifications, aide de Laurent pour le déboggage
  • Discussion sur les nouveau DARI et les accès DYNAMIQUES: doit-on splitter le projet rlmd? Si oui, où va se retrouver le développement du modèle LMDZ qui ne prend pas trop d'heures mais est appelé à en prendre plus avec le tuning automatique? Discussion à avoir avec Olivier et ICMC: vu que LMDZ est un des composants clés du modèle IPSL, on pourrait basculer le développement  de LMDZ sur gencmip6 (c'est déjà un peu le cas ...)


Architecture et développement:

    Après le Hackathon GPU organisé par NVIDIA et l'IDRIS au printemps dernier se pose la question de comment procéder au portage du code. Tout le monde est convaincu qu'il faut y aller mais comment faire?

D'un point de vue général, ce portage serait l'occasion de restructurer le code de la physique pour le rendre plus modulaire (et lisible/compréhensible?) mais Yann rappelle qu'en fait nous avons des contraintes de temps: les tutelles s'attendent à ce que nous puissions faire tourner un modèle efficacement sur les futures machines ce qui implique un portage 'rapide' du code qui paraît incompatible avec le temps long d'une ré-organisation.

Côté pratique, il paraît évident à tout le monde qu'il faudra qu'il y ait des allers-retours fréquents entre la version trunk du code et la version portée, faire autrement ne conduira qu'à des divergences des versions et donc un portage sans utilité. Il est donc souhaitable de faire un portage par inclusion de directives non-intrusives dans le code (openacc ou openmp) et de développer les tests unitaires de vérification.

Pour Frédéric, il est peut-être encore nécessaire de tester certaines idées pour le portage en prenant des bouts du code de la physique et en travaillant dessus. Yann souligne le fait qu'il faudra probablement abandonner l'idée de garder la rétro-compatibilité du code avec d'anciennes versions (on aura toujours l'historique svn du code). Jean-Baptiste insiste sur le fait qu'il faut bien associer tout le monde, le code physique étant un code 'vivant' dans lequel tout le monde intervient.

On décide donc d'organiser pour l'instant des 1/2 journées de travail prenant la place de réunions poihl. Les premières sont prévues:

  1. le lundi 24 janvier de 10 à 13 heures: restitution 'mains dans le cambouis' du portage de la physique simplifiée effectué lors du hackathon
  2. le lundi 7 février de 10 à 13 heures: séance de portage sur une routine spécifique de la physique (le nouveau fisrt ou la turbulence?) pour mettre en place la méthode de travail qu'on va suivre

Il paraît utile aussi d'organiser une rencontre avec les développeurs de ECRAD pour échanger sur le portage du rayonnement sur GPU et voir que récupérer.

 

Tour de table virtuel:

Ehouarn:
  • Tests ancienne physique sur la dernière révision r4058 sur Jean-Zay OK.
  • A discuté avec les planétos sur la pertinence (ou pas) de rejoindre LMDZPedia. Accueil mitigé de l'assemblée... on en rediscutera lors de futures réunions 
  • A faire: mettre  l'interface dynamico-LMDZ sur le svn LMDZ, ni de nettoyer makelmdz_fcm pour harmoniser les arch.path avec les autres modèles....
  • A faire: remettre Dynamico-LMDZ6 d'aplomb. (indépendance dyn-phy + nouveaux traceurs).
  • Question pertinente de Valentin: différences entre "contfracATM", "fract_*, ? Et évoluent-ils dans le temps? => en profiter pour faire un billet LMDZPedia?=> Réponse contfracATM est constant au cours du temps et = pourc_ter+pour_lic (qui eux varient au cours du temps, suivant limit.nc). Question subsidiaire: et contfracOR, c'est frac_quoi? La description dit "% sfce_terre OR", ce qui ne me parle pas des masses... en allant voir dans le code, c'est "pctsrf(:,is_ter)" donc simplement le % de terre?

Laurent:
  • aide à David sur le debug de ces dernières modifications traceurs
  • ré-intégration des modifications d'optimisations d'Arnaud Durocher
  • travail sur dynamique/XIOS
  • montage des enregistrements de la formation ....
    
Frederique:
  • Enrichissement multi-atlas ... 
  • Comment fait on pour avoir cartopy sous fabric?

Adriana:
  • Participation à un nouveau MIP sur le "pattern effect", avec Jean-Louis Dufresne : utilisation de 4 sets de SSTs différents pour forcer des runs transitoires sur 1870-2017 ( 4 ensembles de 3 membres ). On étudie l'effet de la distribution des SSTs sur la sensibilité du climat calculée sur la période historique  (mentionné par JLD dans présentation en réunion "climat" 10 jan.)
    propositions pour le contenu de l'output, pre-processing des sets de SST fournies
  • Test de tuto aerosols de Olivier pour la formation
        -> à discuter l'harmonisation avec l'ordre des exercices dans la formation
  • Autour du plantage ce0l en debug avec install : 
       -> Lionel a testé sans install, avec version IOIPSL à jour : ça tourne ; 
       Le test similaire chez moi plante -> "creuser" diffs
      -> Laurent a essayé de mettre à jour IOIPSL dans le tar utilisé par install ; a vu que le dernier IOIPSL a besoin de HDF, ce que pour l'instant install ne fait que pour XIOS...
  • Autres (aide à une postdoc de Olivier sur simulations type RFMIP ; fignolage tutorial_prod...) 


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