Environnement des modèles Contraintes liées au parallélisme Utilisation de plusieurs machines Liens couplé/forcé
Contexte Composantes en configurations forcées ou couplées Qu’est ce qu’on veut ? Simplicité d’utilisation, besoins utilisateurs Différentes machines Séquentiel et parallèle Portabilité, simplicité, performances, rigueur
Portabilité, simplicité Utilisation d’outils communs ET portables Compilation : modipsl : pratique et simple pour un portage Rq : compilation LMDZ, INCA et OASIS3 Prism-SCE : rigide, beaucoup de fichiers Exécution : modipsl : compliqué, beaucoup de modifs Prism-SRE : modularité intéressante, habillage du job Modèles : outils communs : IOIPSL pour les I/O (fliocom, rebuild)
Performances Parallélisation des composantes Activation à la compilation ou à l’exécution Couplage via Oasis3 des composantes parallélisées Point clé : I/O, état actuel 1 fichier/cpu + « combinelle-rebuild » Post-traitement : Codes performants : « post » performant Enchaînement des taches : Expérience sur Unicore (pas vraiment portable?)
Rigueur Performances + nombre croissant de configurations = rigueur Validation par composantes Validation par machines (et inter machines) Résultats de simulations de référence ? Outils pour la soumission Guidage de l’utilisateur : alertes, dépendances, suivi,…
Conclusion Portabilité, simplicité, performances, rigueur Outils communs ET portables Qu’est ce qu’on veut avoir dans une config de référence ? Modularité par machine, config, composante, tache (fonctions) Couplé/forcé ou forcé/couplé ? Couplé = modèle pour les configs forcées (état actuel) Forcé = briques à assembler pour une config couplée