2022/01/17
Poihl 'Architecture/développement'
Liens utiles:
- le lien gotomeeting pour la visio: https://www.gotomeet.me/EMC3_LMDZ/poihl
- la page du tour de table virtuel https://pad.colibris-outilslibres.org/p/TourdeTablePoihl
- le planning des poihl https://emc3.lmd.jussieu.fr/en/events/agenda et en page de garde du site LMDZ
- la liste des sujets à aborder https://trac.lmd.jussieu.fr/LMDZ/wiki/SujetsPoihl
Questions d'Etienne lancées à la cantonnade:
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:
- le lundi 24 janvier de 10 à 13 heures: restitution 'mains dans le cambouis' du portage de la physique simplifiée effectué lors du hackathon
- 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:
- (séquentiel 32x32x39)