Comment des outils de développeurs profitent au projet DIVERSE et à l'écologie forestière ?

Les écologistes doivent de plus en plus souvent traiter des modèles informatiques et des scripts alambiqués, avec de nombreuses dépendances, sans avoir de formation en informatique. Lorsque ces modèles sont difficiles à comprendre et à exécuter, les résultats ne sont pas réplicables, parfois même pas reproductibles, surtout à long terme. Cependant, avec une combinaison d'outils informatiques bien connus comme Docker, Jupyter Notebook et GitHub (plus d'informations à venir), nous pouvons nous assurer que notre recherche dans DIVERSE reste reproductible et utile à moyen et long termes. 

Le développement de modèles à grande échelle pour simuler des systèmes complexes est pour le moins ardu. En écologie, le monde de la modélisation est confronté à trois défis importants : 

• La question de la reproductibilité des modèles et simulations complexes 

• Le dilemme "ça fonctionne sur ma machine" 

• L'utilisation à long terme des modèles 

La bonne nouvelle ? Ces défis sont surmontables lorsque les chercheurs vont cogner à la porte des développeurs informatique pour obtenir de l'aide. 

Avant d'entrer dans le vif du sujet, voici comment notre équipe de recherche s'est retrouvée confrontée à la question de la réplicabilité. DIVERSE, une initiative de recherche pancanadienne visant à faire progresser la gestion forestière, utilise LANDIS-II. Ce modèle de paysage forestier de pointe permet d'évaluer les impacts à long terme et à grande échelle de différentes stratégies de gestion forestière sur les forêts canadiennes. La calibration de ce modèle est très complexe. Elle repose sur de nombreuses extensions que l'utilisateur peut choisir, chacune nécessitant des dizaines, voire des centaines de paramètres. Ces paramètres doivent être calibrés de manière à ce que les résultats de chaque extension soient réalistes. Ainsi, des décisions sont prises à chaque étape de la calibration de chaque extension sur la base des données de la littérature et des sorties observées du modèle, avec de nombreuses itérations. 

Par exemple, dans DIVERSE, nous travaillons avec l'extension PnET pour LANDIS-II, laquelle simule la croissance des arbres sur la base de la concurrence entre les arbres en matière de lumière et d'eau. Si les résultats de l'une de nos simulations PnET montrent que les jeunes pousses d'érable d'une forêt atteindront 5 mètres en un an [croissance beaucoup trop importante], cela nous indique que nos calibrations sont érronées.  

Ainsi, la calibration de LANDIS-II pour les simulations peut prendre des mois de travail. Ce n'est pas une tâche facile. 

Jusqu'à présent, les chercheurs en écologie ont eu du mal à conserver des traces de la myriade de décisions nécessaires à la calibration de leurs modèles. Les procédures de calibration ont tendance à être divisées dans plusieurs fichiers remplis de chiffres, d'équations, de graphiques et de petites notes qui n'ont même plus de sens pour leurs propres auteurs après quelques mois. Dans ce contexte, si un chercheur veut reproduire une étude publiée il y a 5 ans, il y a de fortes chances que ses auteurs ne se souviennent plus des détails de la calibration de leur modèle. Cela laisse peu de place à la critique, à l'amélioration et surtout à la réutilisation des procédures de calibration ou des paramètres qu'elles ont produits. 

Si la reproductibilité est la clé d'une bonne science et que nous ne pouvons pas reproduire les simulations que nous faisons en raison d'un manque d'informations sur nos calibrations, alors quel est l'intérêt de tout ce travail ? 

Un outil que nous avons commencé à utiliser au sein de DIVERSE pour relever ce défi et créer une archive de notre processus de calibration est Jupyter Notebook. Cette interface est devenue très populaire parce qu'elle est pratique, permettant aux utilisateurs d'écrire du code Python et de l'exécuter dans des cellules tout en écrivant de la documentation textuelle, le tout en utilisant leur navigateur web. Les pages qui en résultent sont une danse entre des morceaux de texte, des codes et des sorties, ce qui va au-delà de la conservation d'un script. On pourrait comparer cela à un livre de recettes fait à la main par votre grand-mère, avec des recettes tirées d'un journal et des notes manuscrites sur les modifications qu'elle a apportées à la recette originale, incluant sur le goût des différentes itérations. Jupyter devient un "livre de recettes" avec des traces et des notes de ce qui a été fait précédemment dans le modèle, avec des explications et des justifications claires. 

L'équipe de recherche de DIVERSE peut utiliser Jupyter Notebook pour documenter la calibration de son modèle LANDIS-II. C'est formidable ! Mais ce n'est que la première étape pour assurer la reproductibilité et la collaboration. La deuxième étape consiste à s'assurer que toutes les extensions LANDIS-II et de Jupyter Notebook peuvent fonctionner ensemble et être utilisées sur différents ordinateurs par tous nos chercheurs, car croyez-nous, vous ne voulez pas faire cela tout seul. 

Vous vous demandez peut-être si nous ne pourrions pas simplement exporter nos fichiers pour les envoyer à un collègue qui en a besoin ? Malheureusement, ce n'est pas si simple à cause d'un phénomène tristement célèbre appelé l'enfer de la dépendance.  Pour mieux comprendre ce défi, revenons à l'analogie du livre de recettes fait à la main par votre grand-mère.  

Normalement, on devrait pouvoir réaliser les recettes de sa grand-mère à partir de son livre fait à la main et les faire goûter exactement comme elle les préparait. Mais que se passe-t-il si certains ingrédients n'existent plus ? Et si les marques ont changé ? Ou si vous n'avez pas les mêmes instruments de cuisine que votre grand-mère ? Tous ces éléments rendraient la recette plus difficile à reproduire et vous devriez procéder à vos propres ajustements. 

Il en va de même pour les modèles : pour reproduire leurs résultats, nous devons utiliser les mêmes ingrédients et outils que lorsque les modèles ont été développés dans leur environnement virtuel. En d'autres termes, chaque modèle est dépendant de son environnement virtuel. Le défi est que ces environnements virtuels (paquets R, scripts Python, etc.) sont régulièrement mis à jour, ce qui est nécessaire, mais peut créer des erreurs lorsque l'on essaie d'exécuter le modèle. Cela peut également se produire lorsque le modèle est exécuté sur un autre ordinateur, étant donné que chaque ordinateur possède son propre environnement virtuel et peut facilement avoir des fonctions différentes de celles d'autres appareils.  

Ces dépendances deviennent rapidement un problème lorsque nous effectuons de la recherche avec ces modèles : soit d'autres scientifiques ne peuvent pas facilement faire fonctionner un modèle sur leur propre ordinateur, soit le modèle ne peut même plus fonctionner. Pour les personnes travaillant dans le développement de logiciels, il existe même un meme pour décrire ce problème : "Mais ça marche sur ma machine !''  

Pour éviter ce piège, nous avons commencé à utiliser Jupyter Notebook au sein d'une plateforme appelée Docker. Docker crée des machines virtuelles, c'est-à-dire qu'il simule un ordinateur dans un ordinateur.  

Lorsque vous utilisez Docker, vous pouvez créer une image Docker; un schéma de la machine virtuelle créée. Ce simple ensemble d'instructions peut être ouvert dans des fichiers texte et envoyé à des collègues, des réviseurs ou des collaborateurs pour leur permettre de recréer votre machine virtuelle sur leur propre ordinateur et d'exécuter votre modèle sans difficulté. C'est comme si vous expédiiez votre ordinateur avec votre modèle.  

Pourquoi vouloir faire cela ? Parce que vous pouvez ainsi créer l'environnement virtuel nécessaire à l'exécution de votre modèle et le geler de façon à ce qu'il ne change plus, qu'il reste obsolète. Votre modèle et ses dépendances resteront les mêmes et seront encore utilisables dans 10 ans. Qui aurait cru qu'être obsolète pouvait être aussi pertinent ? 

Avec ces deux innovations, Jupyter Notebook et Docker en tandem, les chercheurs en écologie forestières peuvent faire beaucoup de progrès en termes de partage de leurs modèles, de leurs méthodes de calibration et de leurs approches. La dernière étape manquante est l'approche collaborative de la science : avoir de nombreux scientifiques du même domaine qui travaillent à l'amélioration des modèles et des calibrations existants plutôt que de réinventer la roue à chaque fois. 

Afin de catalyser la collaboration scientifique autour du modèle LANDIS-II, l'équipe DIVERSE a créé un dépôt GitHub de notre image docker contenant les calibrations de notre modèle. GitHub est une plateforme libre d'accès où chacun peut télécharger les fichiers pour les modifier et les utiliser pour ses propres projets. Les gens peuvent également accéder et modifier les codes partagés dans le système de Git Versioning, qui est un système robuste où toutes les modifications des codes sont enregistrées et associées à un utilisateur, ce qui rend le processus de collaboration transparent.  

Enfin, GitHub dispose du système GitHub pages , lequel permet de distribuer gratuitement et facilement le Notebook de Jupyter sous la forme d'une page web. DIVERSE a partagé tous ses fichiers Jupyter Notebook contenant l'approche de calibration de LANDIS-II sur des pages GitHub, rendant la procédure de calibration facile à lire sans même avoir à installer Docker ou à exécuter le modèle complet sur votre propre ordinateur. 

Maintenant, au lieu de se battre avec leurs propres modèles qui ne peuvent pas être facilement reproduits ou utilisés par d'autres équipes de recherche, les chercheurs peuvent désormais travailler en collaboration sur des modèles complexes et les améliorer ensemble. 

En résumé, les trois innovations que nous partageons ici constituent un pas dans la bonne direction en écologie forestière, qui pourraient probablement être étendues à tous les domaines de l'écologie et à d'autres sphères de la science.

• Jupyter Notebook pour montrer le processus allant de la calibration aux simulations des modèles ; 

• Docker pour partager le modèle et sa calibration avec d'autres ; 

• GitHub pour travailler en collaboration et assurer la prospérité des modèles que nous mettons des années à développer. 

Bien que ces outils soient ceux que nous utilisons dans DIVERSE, il existe de nombreuses autres possibilités à découvrir dans des programmes tels que Data Carpentry.

En bref, les ordinateurs sont très complexes et, bien que nous ayons l'impression qu'ils ont toujours fait partie de notre vie parce qu'ils sont omniprésents aujourd'hui, c'est une technologie relativement récente dans l'ensemble de l'histoire de la science. Nous devons ainsi adapter nos méthodes de travail en écologie pour nous assurer que les recherches que nous menons respectent les principes directeurs de la science, notamment la reproductibilité et la réplicabilité des recherches.