Nos outils de simulation

Nous sommes un bureau d’études indépendant : nous ne vendons pas de logiciel et nous ne distribuons pas d’équipements. Nous n’avons donc aucun intérêt à prescrire un outil plutôt qu’un autre, et nous choisissons celui qui permet de traiter le problème et de justifier le résultat.

Cette position a une conséquence pratique pour nos clients qui ne disposent pas d’environnement de simulation. Selon le besoin, nous livrons soit le résultat seul, accompagné de sa note de calcul et de ses hypothèses, soit le modèle complet. Dans ce second cas, le modèle est open source : vos équipes peuvent l’ouvrir, le lire, le modifier et le relancer sans acquérir de licence, et sans dépendre de nous pour l’exploiter.

La transparence des équations n’est pas qu’un principe. C’est ce qui rend une justification relisible par un tiers et une qualification d’outil atteignable, là où un code fermé oblige à faire confiance à son éditeur.

Si vous disposez déjà d’outils dédiés, nous nous adaptons à votre environnement. Nous possédons notamment une licence Dymola pour les travaux Modelica menés dans les chaînes de nos clients : l’open source est chez nous un choix méthodologique, pas une contrainte budgétaire.

Une étude mobilise rarement un seul outil. Le calcul 3D alimente le modèle système, la donnée d’entrée alimente le modèle et la note, les résultats alimentent le rapport. Chaque transfert manuel entre ces étapes est à la fois du délai et un risque d’écart entre ce qui a été calculé et ce qui est écrit.

Nous avons donc construit nos outils pour qu’ils communiquent. Les modèles sont générés et pilotés par scripts, les échanges entre codes passent par des standards ouverts, les données d’entrée proviennent d’une source unique, et les notes récupèrent automatiquement les résultats. Les blocs qui suivent décrivent ces briques.

Le bénéfice se mesure au moment où le projet change. Une hypothèse révisée, une interface modifiée ou un cas de calcul ajouté se traduisent par une relance de la chaîne, non par une reconstruction de l’étude.

Nous réalisons nos études système en langage Modelica qui adapté à la modélisation système et au couplage de composants. L’approche 0D/1D permet de simuler un système entier (production, distribution, consommateurs, régulations) avec des temps de calcul compatibles avec des campagnes de plusieurs centaines de cas.

C’est ce qui rend possible ce qu’un calcul 3D ne permet pas : explorer des plages de paramètres, comparer des architectures, quantifier des sensibilités et identifier les grandeurs réellement dimensionnantes avant de figer la conception.

L’intérêt de ces modèles réside dans la maîtrise des hypothèses. Nous savons ce que contient chaque composant, quel phénomène est représenté et lequel est négligé, et nous pouvons donc énoncer le domaine de validité du modèle condition pour qu’un résultat soit défendable en instruction.

Nos bibliothèques Modelica sont développées en interne. TAeZoSysPro, dédiée à la simulation des systèmes de ventilation, est co-développée avec EDF R&D et qualifiée au sens du guide n°28 de l’ASN, avec note théorique, validation par composant, cas de référence et tests de non-régression. ChillerSysPro couvre le comportement des groupes frigorifiques avec différents fluides et conditions de fonctionnement. Nous contribuons par ailleurs au consortium OpenModelica.

La même logique s’applique à la CFD. Nous développons des fonctions utilisateur dans code_saturne pour adapter les modèles aux problèmes rencontrés et réduire les temps de calcul, et nous échangeons directement avec ses développeurs sur les évolutions de l’outil.

Pour un client, la différence est concrète : une limite de l’outil n’est pas une limite de l’étude. Lorsqu’un phénomène n’est pas représenté par les modèles standards, nous l’implémentons et nous le validons, au lieu de contourner le problème par une hypothèse majorante dont personne ne sait chiffrer le coût.

L’approche système repose sur des volumes considérés homogènes. Certaines configurations invalident cette hypothèse : convection naturelle, stratification, répartition spatiale des sources, écoulements fortement dépendants de la géométrie. Le calcul 3D devient alors nécessaire, non pour remplacer le modèle système, mais pour vérifier ou corriger ce qu’il suppose.

Nous utilisons code_saturne, développé par la R&D d’EDF, pour les simulations thermo-aérauliques et fluidiques, et code_aster pour les analyses mécaniques : efforts, déplacements, contraintes et modes propres.

Ces calculs ne restent pas isolés. Les résultats 3D sont réinjectés dans les modèles système sous forme de coefficients d’échange ou de corrélations ajustées, de manière à ce que les études de dimensionnement s’appuient sur un comportement local représentatif tout en conservant la rapidité de l’approche 0D.

Nous développons en Python les modèles spécifiques pour lesquels ni une bibliothèque système ni un calcul 3D ne constituent le bon outil, ainsi que l’ensemble de notre outillage d’automatisation : 

• génération des modèles et des jeux de cas, 
• lancement des campagnes,
• post-traitement et production des figures. 

Une étude ainsi structurée se reprend en quelques heures lorsqu’une donnée change, là où une chaîne manuelle demanderait de tout refaire.

Le standard FMI permet d’exporter nos modèles pour les faire communiquer entre eux ou avec vos propres outils (neutronique, thermohydraulique, contrôle-commande), en conservant chaque discipline dans son environnement de référence. Associé à Python, il permet également de construire des interfaces graphiques exploitant les modèles en temps réel, utiles pour l’aide à la décision comme pour la formation des équipes d’exploitation.

Cette automatisation ouvre enfin l’accès aux études probabilistes. Avec Persalys, nous propageons les incertitudes sur les données d’entrée pour distinguer ce qui relève de la marge physique de ce qui relève du conservatisme des hypothèses.

Sur un projet dont les données d’entrée évoluent, la même valeur finit recopiée dans un modèle, un tableur et plusieurs notes. Lorsqu’elle change, la mise à jour est partielle et l’écart n’apparaît qu’à la relecture finale, voire en instruction. Ce mécanisme est l’une des premières causes d’erreur sur les études longues.

Nous avons développé SAPPHIRE, notre outil Python de source unique de la donnée. Chaque grandeur d’entrée y est définie une fois, avec son unité, son origine et son statut, puis référencée par les modèles comme par les documents.

La rédaction des notes s’appuie sur Typst, qui interroge directement cette source et intègre automatiquement les résultats et figures produits par les modèles. Une révision de donnée devient alors une relance de la chaîne, et non une vérification manuelle de chaque document.

Modèles, scripts et documents sont versionnés sous Git, sur notre instance Gitea. Chaque modification est datée et attribuée, les évolutions sont relues, et les tests de non-régression sont exécutés sur les bibliothèques. Un résultat livré est rattachable à une version précise du modèle et des données qui l’ont produit.

Cette traçabilité est ce qui rend la démarche de qualification possible, et ce qui permet de reprendre une étude plusieurs années après sa livraison, situation courante lorsqu’un dossier revient en instruction ou qu’une installation évolue.

Le choix d’outils ouverts et sobres y contribue également. Un modèle en texte, un script Python et une note Typst restent lisibles et exécutables sans dépendre de la feuille de route commerciale d’un éditeur ni d’un format propriétaire devenu obsolète.