Ces trois études ont mené à, d’une part, la mise au point d’un estimateur dans le cadre de la betterave avec LNAS et dans le cadre du blé pour STICS, et d’autre part, la démonstration de la faisabilité technique d’une étude dans le cas d’un simulateur indépendant à tout le système avec un modèle de croissance du pin basé sur LIGNUM et écrit sous la plateforme GroIMP.
Il faut bien prendre conscience que ce l’on cherche à montrer ici c’est l’utilisation du noyau et du langage défini dans les précédents chapitres.
Ainsi il est important de comprendre que ces études ont été menées grâce à un simplefichier où nous avons entré les différentes configurations. Nous avons affiné les calculs en les relançant plusieurs fois et en cherchant les bons paramètres en fonction des sorties des différents algorithmes. La syntaxe et sémantique communes permettent de passer d’un algorithme à l’autre facilement pour peu que l’on connaisse le domaine d’application et les types de résultats produits. Nous avons ainsi drastiquement réduit le temps d’apprentissage et la faisabilité de phases de validation et vérification des modèles implé-mentés. Un modèle qui ne passerait pas par ces phases ne devrait même pas être considéré comme un candidat comme modèle en production (utilisation par un expérimentateur, utilisation par un organisme externe, ...)
Nous allons voir quelques éléments factuels autour du développement de cette plateforme et de son utilisation avant de conclure sur ce chapitre.
3.3.1 Coût en développement
En terme de développement, les plateformes représentent un temps de total de 785 jours d’activité de développement. Un jour étant considéré comme actif s’il y a eu au moins un commit dans le système de version. Le rythme est de 4 commits par jour actif. Dans la première version, il y a eu au total 140 000
lignes de code C++ tout confondus et 25 000 lignes de code pour la seconde version. Pour la description des différentes architectures on peut se reporter à la section2.2.1. Le système étant codé en C++ nous avons utilisé différents compilateurs afin de s’assurer de sa portabilité à savoir le compilateur GNU GCC sous Linux, le compilateur Clang basé sur LLVM sous Mac OS X, le compilateur de Visual Studio sous Windows 7 et enfin le compilateur ICPC d’Intel pour le cluster sous CentOS6. L’ensemble est intégré dans une chaîne d’intégration continue avec production automatique de documentation Doxygen et passage de tests unitaires et d’intégration sur chaque commit.
3.3.2 Utilisation sur un cluster
En ce qui concerne le passage à l’échelle, le travail effectué a permis de former environ 30 personnes autour des notions développées.
En regardant les temps calculs de l’équipe qui utilise cette base de code, nous pouvons visualiser sur le graphique3.44la consommation totale en termes de temps calcul avec une projection sur l’année 2016 qui correspondant à une simple multiplication par 3 des 4 premiers mois effectués. On peut voir qu’il y a depuis l’introduction de la plateforme, une augmentation du temps cpu total par année avec un nombre d’utilisateurs variant autour de 10 mais avec une augmentation du nombre d’années de temps calcul par utilisateur. Cela pourrait traduire soit une meilleure efficience de l’utilisation générale du système sinon une amélioration dans les choix techniques dédiés aux algorithmes.
Figure 3.44 – évolution de la consommation calcul aufil du temps
En enlevant les utilisateurs avec le moins de travaux effectués sur le cluster de CentraleSupélec, nous passons de 24 personnes à 18 et nous pouvons créer une lecture des profils ”types” de la plateforme en rapportant le temps moyen par calcul sur un coeur.
On peut voir, sur lafigure3.45, quelques types de profils qui se dégagent très peu de travaux mais temps cpu long, généralement des gens qui analysent un modèle, beaucoup de travaux mais temps cpu court, généralement de la conception d’algorithmes sur des modèles ”jouets”, et les profils atypiques comme très peu de jobs et très peu de temps cpu, généralement des personnes qui sont restés peu de temps, ou beaucoup de jobs et beaucoup de temps, on retrouve ici plutôt aussi des concepteurs d’algorithmes. Pour information, le profil de l’auteur est le profil numéro 4.
Figure 3.45 – profils utilisateurs en fonction du nombre de jobs et temps moyen par job sur un coeur
3.4 Conclusion
Nous avons vu l’utilisation d’une plateforme développée par le truchement du langage créé en amont. Ce langage est dédié à la chaîne d’analyse des modèles, mais peut aussi s’appliquer dans le cadre de la création d’un modèle. Il possède une version implémenté en tant que langage dédié embarqué en C++ et une version autonome avec son propre compilateur mais restreint au cadre de modélisation des systèmes dynamiques stochastiques discrets en temps.
Cette utilisation a permis de fédérer l’ensemble des personnes autour de la création d’un environnement commum permettant de réaliser l’ensemble de la chaîne d’étude des modèles et pouvant aussi être appliqué à n’importe quel simulateur extérieur à la plateforme en restreignant le cadre formel.
La normalisation du langage, en n’introduisant que très peu de concepts extérieurs au modèle mathé-matique d’origine, permet une communication efficace entre les modélisateurs et les algorithmes. Cette plateforme a été utilisée par environ 30 personnes aufil des années.
L’utilisation du cube de simulation comme cadre conceptuel a permis de développer les algorithmes autour des notions de calcul parallèle, permettant ainsi d’accumuler entre 2011 et 2015 plus de 135 années de temps calcul si l’ensemble était calculé sur une machine mono-coeur.
Aujourd’hui, il existe des outils permettant de traiter une partie ou une autre de la chaîne, l’ensemble de la communauté y gagnerait à utiliser le formalisme développé comme base conceptuelle et langage d’échange afin de permettre, à minima, la comparaison des expériences faites. On pourrait imaginer une plateforme centrale lançant indifférement tel ou tel outil sur la base de ce langage.
Chapitre 4
Perspectives et conclusion
La conclusion revient sur les diverses contributions scientifiques en termes de logiciels et de publications ainsi que sur les perspectives de développement du système informatique décrit.
4.1 Contributions
Cette thèse a donné lieu à plusieurs publications et développements logiciels.
4.1.1 Apports de nos travaux
Si nous reprenons la formulation de notre problématique, nous pouvons apporter quelques éléments de réponse :
”Quels sont les éléments de vocabulaire, la sémantique et l’arbre de syntaxe nécessaires à la création d’un langage dédié pour la simulation et l’analyse quantitative des modèles ?” À partir de la représentation d’un système dynamique à espace d’états, nous avons construit un vocabulaire associé à des types et des signatures permettant la création à la fois d’un langage dédié embarqué pour la création de certains modèles et des algorithmes d’analyse, mais aussi d’un langage dédié permet-tant de créer plus facilement des modèles dynamiques discrets stochastiques. Nous verrons dans les perspectives comment faire évoluer ce langage en essayant notamment d’aller vers d’autres domaines spécifiques.
”Comment coupler N modèles à M algorithmes afin d’éviter de redévelopper chaque algorithme pour chaque modèle, ce qui est généralement la norme dans les développements actuels ?” Nous avons proposé de modifier nos algorithmes afin de fonctionner avec tout type de simulateur ex-terne. Toutefois, cette généralisation est à l’heure actuelle peu performante du fait des coûts en entrées-sorties. Il faudrait voir à créer un format adapté basé sur une représentation binaire pour stocker l’en-semble des simulations. Nous verrons cela dans la prochaine section. Il nous faudrait aussi voir comment réinsérer le tout dans desflux de programmation plus classiques du domaine comme MATLAB ou R.
”Comment gérer l’aléatoire dans le cadre des modèles et des algorithmes ?” Nous avons étudié le champ des générateurs aléatoires et avons implémenté une solution pragmatique qui ne représente pas l’état de l’art mais permet néanmoins d’être confiant dans les résultats produits. Toutefois, il serait bon de revoir si des bibliothéques ou des logiciels candidats ont émergé depuis dans la communauté et que nous serions à même d’intégrer dans notre simulateur.
”Comment mettre en place unflux de travail permettant de sélectionner le bon modèle vis à vis d’une problématique tout en garantissant son domaine de validité ?” Nous avons montré des études mettant en jeu différents modèles et l’ensemble de la chaîne des bonnes pratiques de modéli-sation en discutant du choix des algorithmes implémentés. Ceflux utilise le langage créé en amont afin d’interfacer l’ensemble des algorithmes. Nous verrons par la suite qu’il serait bien de s’inspirer de ce travail afin de proposer un standard pour échanger les différentes expériences virtuelles menées entre les différents logiciels d’analyse et d’estimation sur un même modèle.
”Comment réduire la courbe d’apprentissage et l’opérationnalité d’un nouveau modélisateur ?” Nous avons présenté ce langage et ces outils à des personnes n’ayant pas fait parti du processus de conception et développement qui ont réussi à prendre en main l’ensemble sans réelle indication si ce n’est les concepts relatifs au domaine de l’analyse de sensibilité ou à l’estimation paramétrique. Une fois les concepts compris, les études ont pu être menées sans trop d’intervention. Cela laisse à penser que l’étude formelle du domaine et la construction de l’ensemble permet de réduire la complexité des études. Toutefois, pour l’instant il faut avoir certaines connaissances en termes de manipulation des calculateurs. Nous montrerons quelque perspectives permettant de réduire encore plus la complexité et d’aller au délà en tentant de fédérer une communauté.
”Comment exploiter les architectures modernes de calcul afin de pouvoir gérer la montée en charge et ainsi renforcer la performance et par extension la robustesse de la chaîne de travail ?” Pour l’instant, nous exploitons les architectures à mémoire partagée. Cela s’est montré suffisant pour l’ensemble de nos études. Toutefois, il apparait clair que nous devons mettre au point un simulateur permettant de monter en charge sur des architectures à mémoire distribuée voire massivement parallèle. Pour résumer :
Nos travaux ont porté sur la formalisation de la chaîne des bonnes pratiques de modélisation en démarrant de la représentation d’état de systèmes dynamiques discrets stochastiques. L’ori-ginalité de notre démarche tient dans la cohérence générale du système qui lui est conféré par la mise en place d’un langage développé sur la base de la modélisation mathématique adaptée à notre cadre de modélisation mécaniste. Au lieu de regarder vers la composition des systèmes sous-jacents du modèle, nous avons regardé la composition des systèmes au-dessus du système considéré qui permettent ensemble de conduire une bonne étude de modélisation permettant de passer du statut de modèle à celui de modèle vérifié et validé. Cette formalisation a permis le dé-veloppement d’une plateforme cohérente et pouvant exploiter certaines capacités parallèles des calculateurs. Il permet à la fois la conception du système interne mais aussi l’ensemble des com-munications entre les différents programmes. Nous sommes en train de travailler sur le passage à l’échelle de l’ensemble avant de voir comment l’utiliser pour connecter d’autres éléments qui ont été initialement non-prévues pour la plateforme. Nous pensons que ces éléments de langage vont permettre de définir un format standard d’échange concernant la validation et vérification des modèles. Nous en reparlerons plus loin lors des perspectives et de la notion de passeport de modélisation.
4.1.2 Logiciels
Il y a eu un important effort de développement fourni à différents niveaux. Si l’on pense l’ensemble de la plateforme au moyen d’une architecture trois-tiers alors nous avons des logiciels pour chaque tiers à savoir le tiers données, le tiers applications, le tiers présentation.
nom du projet but tiers stochasticity étude du comportement de plusieurs
généra-teurs
application quantitative-agronomy-ontology rédaction d’une ontologie avec Protégé données data-manager utilitaire en ligne de commande pour interragir
avec une base de donnéesfichier (csv, json)
données pygmalion A bibliothèque C++ utilisant des modèles
templati-sés
application pygmalion B bibliothèque C++ utilisant des modèles
templati-sés ou des bibliothèques dynamiques ou le lan-gage dédié
application
kaffee prototype de client-serveur avec pygmalion B en tant que serveur
application cinammon outil en ligne de commande interfaçant
data-manager et pygmalion-b qui a pour but d’être le client de kaffee
présentation
coconut webgui de cinnamon avec gestion de comptes -orienté applications métiers de la modélisation
présentation
gaia web-gui de cinnamon orienté applications
mé-tiers de l’agronomie
présentation
4.1.3 Publications
Nous faisons la distinction entre les publications en tant qu’auteur principal et les publications en tant qu’auteur associé.
4.1.3.1 En tant qu’auteur principal
— Towards an EDSL to enhance good modelling practice for non-linear stochastic discrete dynamical models Application to plant growth models (Bayol, Chen et Cournède 2013) décrit les bases du modèle informatique, de l’EDSL, du cube de simulation et introduit les fonctionnalités des bonnes pratiques de modélisation.
— Promoting Good Modeling Practice with a Domain-Specific Language and Statistical Algorithms designed for Parallel Computing (WIP) (Bayol et al. 2015) introduit le DSL et montre les perfor-mances d’un algorithme de type CPF.
4.1.3.2 En tant qu’auteur associé
— Development and Evaluation of Plant Growth Models : Methodology and Implementation in the PYGMALION platform (Cournède et al.2013) est une revue générale de certaines méthodes et de la méthodologie au sein de la plateforme.
— Sensitivity Analysis for Plant Models with Correlated Parameters : Application to the Characteri-zation of Sunflower Genotypes (Wu et al.2013) montre l’application des méthodes d’analyse de sensibilité implémentées dans la plateforme sur des modèles de plantes dans le cadre de la ca-ractérisation des génotypes du tournesol.
— Filtrage par noyaux de convolution itératif (Chen et al.2012) présente la méthode du Convolution Particle Filter existant dans la plateforme.
— A Comparison of a Generic MCMC-based Algorithm for Bayesian Estimation in C++, R and Julia. Application to Plant Growth Modeling (Viaud et al.2015) montre les différences de performances
existantes entre un code MCMC tournant sur le modèle LNAS et implémenté soit en C++, en Julia ou en R.
— Impact of geometrical traits on light interception in conifers : analysis using an FSPM for Scots pine (Streit et al.2016). Les méthodes d’analyse et de calibration sont celles de PyGMAlion qui utilise le simulator GroIMP en tant que simulateur externe.