An Ocean Model Ported by a Large Language Model: Experience and Lessons from FESOM2 (Fortran to C to C++/Kokkos)

Cet article démontre qu'un modèle de langage de grande taille agentique, guidé par des experts du domaine à travers un processus de traduction en deux étapes strict et une validation rigoureuse, a porté avec succès le modèle océanique FESOM2 de 74 000 lignes en Fortran vers le C++/Kokkos tout en préservant sa physique et en réalisant des gains de performance significatifs sur GPU.

L'essentiel

Imaginez que vous possédez une recette massive, incroyablement complexe et hautement réussie pour un plat 5 étoiles. Cette recette a été écrite dans une langue très ancienne et spécialisée (appelons-la « Fortran ») que seuls quelques maîtres chefs comprennent. Elle a été testée pendant des décennies, et tout le monde sait qu'elle fonctionne parfaitement. Cependant, la cuisine change : les nouveaux fours (les supercalculateurs modernes avec des GPU puissants) ne parlent plus le « Fortran ». Ils parlent le « C++ ».

Le problème ? Traduire cette recette de 74 000 lignes de l'ancien langage vers le nouveau est comme essayer de traduire un roman tout en reconstruisant simultanément la maison dans laquelle il est écrit. Si vous faites ne serait-ce qu'une seule petite erreur de calcul, le plat pourrait se transformer en poison, ou la cuisine pourrait prendre feu. Habituellement, cela prend des années à une équipe d'experts humains.

Cet article décrit une nouvelle expérience : Un algorithme d'IA (un grand modèle de langage) peut-il effectuer ce travail de traduction pour nous, et peut-il le faire sans gâcher la recette ?

Voici comment ils ont procédé, en utilisant des analogies simples :

1. La stratégie de traduction en deux étapes

Au lieu de demander à l'IA de passer directement de l'« Ancien Langage » au « Nouveau Langage à Haute Vitesse », l'équipe l'a forcée à faire un détour.

• Étape 1 : La « Copie Propre » (Fortran → C) : D'abord, ils ont demandé à l'IA de traduire la recette dans un langage intermédiaire plus simple appelé « C ».

  • La Règle : Il était strictement interdit à l'IA d'« améliorer » la recette. Elle ne pouvait pas remplacer les ingrédients pour les rendre « meilleurs » ou modifier les temps de cuisson pour être plus efficace. Elle devait faire une copie littérale, mot pour mot.
  • Le But : S'assurer que la saveur (la physique) restait exactement la même. Ils ont fait tester cette nouvelle version en « C » pendant cinq années de temps simulé. Elle avait un goût identique à la version « Fortran » originale, avec des différences si infimes qu'elles étaient comparables à un grain de sel dans un océan.

• Étape 2 : La « Mise à niveau de vitesse » (C → C++/Kokkos) : Une fois la version « C » prouvée parfaite, ils ont demandé à l'IA de traduire celle-ci dans le langage moderne « C++ », qui est conçu pour fonctionner sur des fours à haute vitesse (GPU).

  • Le Filet de Sécurité : Puisque la version « C » était déjà parfaite, l'IA pouvait maintenant se concentrer sur la vitesse. Ils ont vérifié chaque étape du processus de cuisson pour s'assurer que la nouvelle version « C++ » produisait exactement les mêmes nombres que la version « C » sur des ordinateurs standards.

2. Le système de vérification par « Jumeaux »

Comment savaient-ils que l'IA n'avait pas glissé une erreur ? Ils ont utilisé un système de « Jumeaux ».

Imaginez que vous avez un maître chef (le code original) et un apprenti chef (le nouveau code). Chaque fois que l'apprenti coupe un oignon, il doit montrer immédiatement le résultat au maître chef.

• Le Test du « Jumeau » : Pour chaque étape de la cuisson, l'ordinateur exécute le nouveau code et l'ancien côte à côte. Si les nombres diffèrent, même d'une fraction infime, le système hurle « Stop ! » et dit à l'IA : « Tu as raté cette étape spécifique. »
• Le Piège de l'« Halo Stagnant » : Une erreur courante commise par l'IA a été d'oublier de mettre à jour les bords des données (comme oublier de laver la planche à découper entre deux coupes). L'équipe a construit une « sonde » spéciale qui vérifie spécifiquement les bords pour attraper ces erreurs invisibles.

3. Les Résultats : Vitesse et Précision

L'expérience est un succès. Voici ce qui s'est passé :

• Précision : Le nouveau code est scientifiquement fiable. Sur cinq années de simulation, les températures et la salinité de l'océan de la nouvelle version étaient presque indiscernables de l'original. Sur les nouveaux GPU ultra-rapides, les résultats étaient « statistiquement proches » — ce qui signifie que les infimes différences étaient simplement dues à la manière dont l'ordinateur effectue les calculs, et non parce que la physique était erronée.
• Vitesse : Le nouveau code fonctionne sur des GPU modernes (comme le NVIDIA A100) et est 1,6 à 3,7 fois plus rapide que l'ancien code tournant sur des CPU standards.
• Portabilité : Le meilleur aspect ? Ils ont écrit le code une seule fois, et il fonctionne sur différents types de supercalculateurs (NVIDIA, AMD et autres) sans avoir besoin d'être réécrit. C'est comme un adaptateur universel qui s'adapte à n'importe quelle prise.

4. Ce qui a mal tourné (et comment ils l'ont réparé)

L'IA n'est pas parfaite. Elle a essayé d'« aider » en simplifiant les choses, ce qui a failli briser la physique.

• Le Piège de la « Simplification » : L'IA voulait arrondir les nombres ou changer une valeur constante parce que cela paraissait plus « propre ». L'équipe a dû l'interdire strictement. Ils lui ont dit : « Si l'original dit 0,1, tu écris 0,1. Ne devine pas. »
• Le Piège du « Commentaire » : L'IA lisait parfois un commentaire dans le code qui disait « La valeur est 5 » alors que le code réel disait « La valeur est 10 ». L'IA faisait confiance au commentaire. L'équipe a corrigé cela en forçant l'IA à vérifier la ligne de code réelle à chaque fois.

L'essentiel

Cet article prouve qu'avec les bonnes règles et une « échelle de sécurité » de vérifications strictes, une IA peut traduire un modèle scientifique massif et complexe d'un ancien langage vers un nouveau, ultra-rapide, en quelques semaines.

Elle n'a pas seulement copié le code ; elle a préservé la science. Le modèle océanique se comporte toujours exactement comme le véritable océan, mais il tourne désormais assez vite pour nous aider à prédire le futur climat sur les ordinateurs les plus puissants du monde. La clé n'était pas seulement l'IA ; c'était la discipline des humains qui la guidaient : des règles strictes, une traduction littérale et une vérification constante.

Résumé technique

Résumé technique : Un modèle océanique porté par un grand modèle de langage

Énoncé du problème
Les projections climatiques exigent de plus en plus des résolutions océaniques à l'échelle du kilomètre, ce qui nécessite la migration des modèles de circulation générale (GCM) océaniques établis, écrits en Fortran et de grande échelle, vers le matériel moderne, en particulier les GPU. Cependant, ces modèles, souvent développés sur des décennies pour des clusters de CPU à mémoire distribuée, font face à des barrières significatives pour leur portage : une rareté de l'expertise humaine en connaissance du domaine, en portage et en optimisation des performances, ainsi que la difficulté de maintenir la fidélité scientifique lors de la traduction. Bien que les grands modèles de langage (LLM) aient démontré leur succès dans la traduction de segments de code plus petits ou de fonctions individuelles, il n'était pas encore établi si un LLM pouvait porter un modèle géophysique complet, de niveau production, vers un langage et un framework différents (spécifiquement pour l'accélération GPU) sans dégrader sa physique ou sa précision numérique.

Méthodologie
Les auteurs ont porté FESOM2, un modèle océan-glace de mer à maillage non structuré et à volumes finis (environ 74 000 lignes de Fortran central), en utilisant un assistant de codage agentique basé sur un LLM (Claude Code avec le modèle Opus 4.7) sous la direction d'experts du domaine. Le processus de portage a été structuré autour de trois pratiques critiques pour garantir la fiabilité :

1. Traduction en deux étapes : La traduction a été divisée en deux phases distinctes pour séparer la justesse numérique du parallélisme.

   • Étape 1 (Fortran vers C) : Le modèle a été traduit en une référence C propre et mono-threadée. Cette étape a consisté à condenser le code Fortran hautement configurable dans la configuration spécifique utilisée pour l'exécution, résolvant les ambiguïtés concernant les options de compilation actives et les valeurs par défaut à l'exécution. La traduction était strictement littérale, interdisant au LLM d'« améliorer » ou de simplifier le code.
   • Étape 2 (C vers C++/Kokkos) : La référence C a ensuite été enveloppée dans du C++ utilisant la couche de portabilité des performances Kokkos pour cibler à la fois les CPU et les GPU. Cette étape s'est concentrée sur la parallélisation tout en préservant l'arithmétique de la référence C.

2. Traduction littérale stricte : Le LLM a reçu l'instruction d'effectuer une traduction ligne par ligne, convertissant l'indexation de base 1 en base 0, adaptant le stockage colonne-major en ligne-major, et convertissant les variables globales USE en passage de structures. Aucun changement sémantique n'était autorisé. Cela garantissait que toute divergence par rapport à la référence soit un bug de portage plutôt qu'une modification de la physique.

3. Échelle de validation par paliers : Un cadre de validation rigoureux a été appliqué à chaque étape :

   • Fortran vers C : Validé via un accord statistique à long terme (intégrations de 5 ans) plutôt que par une égalité bit à bit, car les différences de langage et de compilateur empêchent une correspondance exacte au niveau de l'octet.
   • C vers Kokkos (CPU) : Validé par une identité bit à bit par rapport à la référence C sur des back-ends déterministes (Serial/OpenMP).
   • Kokkos (GPU) : Validé par une proximité statistique par rapport à la référence C sur les GPU (où les ordres de réduction de nombres à virgule flottante diffèrent) et par des « portes » strictes (ex: exécutions de 20 étapes avec glace de mer active) pour détecter les erreurs réelles par rapport à la divergence numérique attendue.
   • Outils de débogage : Des outils personnalisés, tels que des dumps de référence par sous-étape, des diffs d'opérateurs à entrées identiques et des sondes de halo obsolètes, ont été développés pour isoler les échements à des noyaux ou sous-systèmes spécifiques.

Résultats clés

• Fidélité :
  • Le port C a reproduit le modèle Fortran original sur une intégration de cinq ans avec une différence de racine carrante moyenne de la température de surface de la mer (SST) de 0,006 °C et une différence de salinité de 0,002 PSU. Les différences dans l'océan profond étaient statistiquement indiscernables de zéro en dessous de 700 m.
  • Les builds Kokkos CPU étaient bit à bit identiques à la référence C sur une année simulée complète.
  • Les builds Kokkos GPU sont restés statistiquement proches de la référence C, avec des corrélations de SST de 1,0 et des biais de $+10^{-4}$ °C. La divergence induite par le GPU était environ trois ordres de grandeur plus petite que l'incertitude introduite dans la traduction Fortran-vers-C.
• Performance :
  • Sur des maillages à haute résolution (jusqu'à 7,4 millions de sommets de surface), un seul nœud GPU NVIDIA A100 a tourné 1,6 à 3,7× plus vite qu'un nœud CPU.
  • Le modèle a atteint l'objectif de production de 1 à 2 années simulées par jour (SYPD) sur des maillages de plusieurs millions de sommets sur tous les matériels testés.
  • Sur le système NVIDIA GH200, le débit a atteint jusqu'à 3,5 SYPD.
• Portabilité :
  • Une base de code unique Kokkos a réussi à compiler et à s'exécuter sur divers matériels sans réécriture du code de la physique : NVIDIA A100, H100 et GH200 (via CUDA) ainsi qu'AMD MI250X (via HIP). Le portage vers le système AMD a nécessité moins d'un jour de travail, impliquant principalement un changement mineur d'une garde de préprocesseur.

Signification et affirmations
L'article affirme être la première démonstration qu'un port assisté par un LLM peut porter un modèle complet d'océan-glace de mer vers une implémentation compatible GPU tout en conservant la fidélité scientifique et en atteignant des performances de niveau production. Les auteurs soulignent que le succès n'est pas dû à la seule capacité autonome du LLM, mais plutôt à un flux de travail discipliné combinant :

• L'assistance agentique pour la traduction acharnée et la construction de l'infrastructure.
• L'expertise humaine du domaine pour la stratégie, la revue des plans et la détection d'erreurs de physique subtiles.
• Une procédure de validation par paliers qui convertit les erreurs de physique silencieuses en échecs localisés immédiats.

Ce travail établit que les LLM peuvent transférer des modèles Fortran établis vers des langages modernes et performants (C++/Kokkos) en quelques semaines, à condition que la traduction soit contrainte par des règles strictes et validée par des critères d'acceptation appropriés. Les auteurs présentent cela non pas comme une optimisation finale du modèle, mais comme un point de départ validé et compétitif qui préserve la physique du modèle original tout en permettant l'exécution sur des accélérateurs modernes.