Réunion Chemflow Agflow au LBE Narbonne le 15 nov 2017 10h00


Estelle Ancelet : travaillait sur Agrosyst (Java) système d'information des systèmes de cultures et phytosanitaires, chambres d'agricultures
Patrick Chabrier : depuis la naissance de Recard, il y a 10 ans. Responsable production logiciel.
Hélène Raynal : responsable de la plate-forme Record, animation, projet. Il y a un comité scientifique composé des chefs de départements (EA, MIA, SAE2, SAD, GAP, PHASE).
Record : équipe de 6 ingénieurs et un réseau d'utilisateurs. Record sera une ISC (infrastructure scientifique collective) et possiblement intégrée dans une e-infrastructure (fin 2018).

Virginie Rossard : ingénierie logicielle. Avant : SI sur les données de procédés (SILEX, CATI CODEX, utilisé à présent au LEPS pour Phénome par ex, volonté de généricité). Outil repris par Bio&Tech. Partie "près du capteur" faite par l'Inria, dev repris récemment. Maintenant :  ChemFlow + Typol (SI sur propriétés des micro-polluants). Voir site du LBE > Thème de recherche > Partie SI. Typol reprend une partie des dev de SILEX.
Éric Latrille : IR triple casquette : fait de l'instrumentation de bio-procédés, correspondant stats, dev informatique (arrivé par l'automatique). Utilise plusieurs languages (scilab, R, python...). Impliqué dans les CATI.

Au LBE : SI très près de la donnée et modélisation, stats.

Typol : Analyses faites avec R-Studio, installé sur un serveur. Lié à BDD relationnelle. Typol est en voie d'être passé sur Galaxy. Un stagiaire travaillera là-dessus à partir de février/mars 2018.

La spectro ( ChemFlow) fait partie de l'instrumentation.
Historique de Chemproject et de  ChemFlow

Développement avec planemo

La fonctionnalité de récupération des données dans une base de données de façon automatique n'est pas utilisé mais c'est une fonctionnalité que nous devrons développer pour l'outil Typol.
Pour  AgFlow : il faudra bien prévoir la traçabilité complète à partir des bases de données de sol.

Faut-il avoir une seule instance de Galaxy pour des communautés différentes ? Quelles contraintes pour l'OS et pour les différentes versions de R, par exemple.
Il sera par contre intéressant d'avoir une collaboration sur les outils du toolshed.

Record :
Voir schéma :
BD BDGSF (Benoit Toutain) : INRA Orleans BD sol
BD Climat : INRA  AgroClim (Patrick BERTUZZI et Olivier Maury)+ Meteo France
Passage difficile entres les données de la pédologie à l'agronomie (modèle de culture STICS)
BD RPG : lien recensement parcellaire graphique (projet PAC pour les agriculteurs) : prévoir la culture qu'il va y avoir
Enquête INSEE sur les pratiques culturales : extrapolation
différentes sources, prétraitements, chaine de traitement : reproductibilité et traçabilité parfaite pour avoir un bon résultat.
Le modèle STICS permet 300 sorties brutes. Repération de outliers à la main avec des scripts fastidieux.
Financer par les projets scientifiques. C'est une plateforme reconnue. Les utilisateurs sont les experts.
Passage à Galaxy pour ouvrir à un public plus large ?
Intérêt de le passer à Galaxy : intégrer facilement des outils et des modèles par rapport à VLE (logiciel graphique actuel),
workflow paramétrable (échelle géographique (m2) différente).
Via le projet EPHESE différents paramètres ont été testé. Il y a N mailles Safran.
On est sur les clusters de Toulouse.
Représentation graphique ? collègues ODR (Observatoire du développement rural à l'INRA Toulouse, Eric Cahuzac) qui ont mis un SI qui permet de faire de la cartographie en leur fournissant le bon format (SIG).
Ont-ils des API ? BD sol non mais ils ouvrent leur BD. BD Climat Oui.
Modèle PASIM modèle prairie développé à Clermont SOERE et ACBB (Katia klumb).
Il y a aussi les aspects traitements statistiques des résultats qu'il faudra inclure.
C'est un projet pour des experts et pour des utilisateurs nouveaux et plus larges. Les simulations se feront à partir de scénarios climatiques ou de pratiques culturales. L'échelle de simulation se fait au niveau national, territorial ou local.

Une lettre d'intention a été faite aux départements de tutelle pour travailler sur ces aspects de workflows BDD + plateforme. Équipe Record fortement encouragée à continuer.
Les informaticiens des différentes bases de données sont impliquées. Accès sur une table spécifique des bases de données.

MISTEA, utilise Galaxy (via une API) en sous-couche de SILEX.

Voir plateforme  SouthGreen.

MOOC
Autour de la communauté chimiométrie (infra-rouge).
Agropolis Fondation a fourni 200 000 euros. Projet sur 2 ans. Condition : En langue français, pour les pays du Sud. Puis 6 à 10 000 € pour la traduction en anglais.
6 mois de CDD pour la gestion de projet avec mise en place d'outils collaboratifs.
 SupagroFlorac a accepté d'être le lieu de tournage. Ont tout ce qu'il faut pour ça. De plus sont partenaires du projet.
 SupagroFlorac ont toute une équipe spécialisée dans les outils collaboratifs (du libre). Voir rencontres Moustic.
Très bon endroit pour agir collectivement. Et pas cher !
La FPN a également financé 10 000 € pour une partie du MOOC.
Pour les évolutions (notebook iPython), le LBE se tourne plutôt vers le mécénat.

*Choix de Galaxy
Pour la partie exercice du MOOC, équipe LBE s'est demandé comment ils allaient pouvoir gérer les install pour un millier d'apprenants. D'autant plus pour les pays du Sud qui n'ont pas forcément bcp de ressource en info.
L'équipe a étudié :  OpenAlea, CNIME avec R, notebook ePython. Galaxy résolvait tous les soucis.
Suite au choix de Galaxy : formation

Qui utilise Galaxy en dehors de la bioinfo ?
W4M : hébergé sur Genotoul mais pas bioinfo. Dep PHASE à l'IMH. Traitement données RMN, (tout ce qui est spectre hors IR). Voir Christophe Carron. Informaticiens de ROSCOFF ? et Clermont. Majoritairement, reprennent des outils R.


*Utilisation de Galaxy par le LBE
Prise en main : rapide pour des personnes connaissant un langage info (ex : R).
Pour le moment, le LBE fait des wrappers. Presque dispo depuis une toolshed.
Pas trop de contraintes pour l'intégration d'outils (wrapper) dans Galaxy. Si on part d'un projet déjà conçu (ex : typol, record) il faut revoir un peu l'architecture et "penser workflow". Il faut trouver la bonne granularité du wrapper.
Seule contrainte : il faut imposer la structure du fichier d'entrée et d'échange entre wrappers.

FACT (SCilab)

Actuellement les utilisateurs exécutent outils par outils. L'équipe LBE souhaite publier des workflows (en dehors des corrections d'exercice).

2 personnes (voir 3) dans le développement de wrappers.

Hébergé cher Genotoul. France Grille va bientôt ne plus être utilisé. Tout tourne sur la VM, pas d'utilisation de grille ou espace disque.

 ChemFlow est en anglais.

L'installation des wrappers par le LBE est faite "manuellement". Sur W4M la condition est que les wrappers doivent être installable depuis la toolshed.

Encapsulation des dépendances du wrapper avec Bioconda.

*Galaxy : technique
Pour passer de l'historique au workflow, il va parfois falloir faire des choix d’enchaînement des étapes.
A partir du moment où on partage un historique, toutes les modifs futures sont aussi partagées.
Métadonnées de l'utilisateur : voir dans l'encadré historique, tag (partagé entre user en même temps que les workflows) + annotations.

Pour les contraintes des formats d'entrée : il faut prévoir tous les cas de figure dans le wrapper si on veut des retours parlants aux utilisateurs. De plus, dans le paramétrage du wrapper, vu qu'on défini les formats attendus, ne sont proposés par défaut que les fichiers

Écriture de wrapper : voir Planemo. Outil qui initialise le wrapper et le test.
On ne peut peut-être pas alimenter les métadonnées du wrapper de manière dynamique (par exemple en fonction de données provenant d'une BDD). À explorer (notamment regarder ce qui est fait pour le wrapper scatterplot).

Lien avec une BDD (autre que databanks) : a été l'objet d'une thèse. Pour le moment l'équipe utilise des fichiers à plat (créé par des partenaires du MOOC). Ces fichiers sont accessibles par URL.
Le LBE préconise aux utilisateurs de créer les fichiers csv selon un protocole bien précis depuis Excel.


*À approfondir
Référence thèse lien BDD.
Donner un accès au wiki agFlow.
Partage de dev entre les 2 équipes ?

*Questions Galaxy

GCC 2017, diapo 22 : pour la liaison avec les BDD, c’est en prospection, c’est bien ça ?
Ce sera l'objet du stage début 2018 au LBE et Toxalim (Rémi Servien).

Avez-vous testé d’autres manières de restituer les résultats que par des fichiers téléchargeables ? (ex : versement dans une BDD, dépôt sur un serveur) Si oui, vous avez des composants pour cela ?
Pour l'historique, on peut les transférer d'une instance Galaxy à une autre en utilisant des liens. (History/ Export history to file)
Mais il n'y a pas l'air d'y avoir une fonctionnalité Galaxy qui propose d'aller verser quelque part des sorties.
Essayer avec un wrapper.
Voir aussi appeler Galaxy via API (mais attention au temps de simulation).

GCC 2017, diapo 22 : avez-vous eu l’occasion de bien utiliser Planemo ? Si oui, quelles fonctionnalités utilisez-vous ? Quelles sont vos impressions sur l’outil ?
Initialisation d'un wrapper (crée le squelette du wrapper avec les inputs). Les inputs peuvent être créés en ligne de commande.
Sert pour les tests : valide la forme du xml. Aussi tests des composants. /!\ Pb d'arrondis des nombres (planemo compare des lettres).
Des tests de charge ont été fait.
Tests fonctionnels avec Planemo : tests I/O. Obligatoire pour publier dans un toolshed. On peut avoir notre propre toolshed en local pour tester nos wrappers.
 MiniConda s'occupe d'installer les dépendances des wrappers.
Voir comment tout cela s'articule avec Stics et du fortran. Voir avec équipe de Franck Giacomoni (inra clermont).
Jean-Claude l'a fait pour Scilab (FACT). Gildas Le Corguillé (Roscoff).
Le LBE va étudier ces questions dès janvier 2018.
Test de workflows : fait avec Galaxy directement (on lance les workflows lors de la maj et on voit s'ils passent au vert ou au rouge).
Tests unitaires dans le code.
 PlanemoServ qui lance tous les tests Planemo d'un coup.

P12 : Qu’appelez-vous exactement les tests fonctionnels ?
Réalisez-vous des tests unitaires de vos composants ?
Et des tests automatisés de l’interface ?

Eric, peux-tu me rappeler la fonctionnalité python que vous explorez actuellement et son but ?
 NoteBook iPython.

Doc install  ChemFlow :
p4 Pour accéder à la BDD de Galaxy, pourquoi utilisez vous plutôt phppgadmin que pgAdmin ?
Vous allez souvent voir ce qui se passe dans la BDD ? Dans quel but ?


Sur Mulcyber, s'il y a des documents en plus du document d'installation de Galaxy que tu nous as fourni, est-il possible que nous (Patrick, Hélène et moi) ayons un accès ?
Il n'y a pas vraiment plus. Il faudra accéder au sourcesup.

Est-il possible d’avoir accès au code de composants « maison » ? Par ex, est-il possible d’accéder au code du « scatter plot » dont le formulaire évolue suivant le choix (champ « use a column of a dataset as spectra color ») ?
Et à des types de données « maison » ?

Avez-vous travaillé avec des métadonnées (sur les modèles ou les données) ? Si oui, de quelle manière (services web, écriture directement dans le xml de conf des outils) ?
Au niveau traçabilité des workflows et de leur partage, avez-vous des bonnes pratiques ?
Proposez-vous de la multi-simulation ? (avec par exemple un fichier Excel qui listerait un ensemble de simulations à réaliser avec une certaine combinaison de fichier)



Optionnel
Vous payez une licence R-Shiny ?
Vous utilisez également Googlevis (google charts dans R) ? Votre retour sur cet outil ?
*Serveurs
Poster JDEV : vous utilisez  FranceGrille pour la sauvegarde ? Comment ça se passe ? Quelles sont leurs conditions ? Pourquoi Génotoul + France Grille ?

Procedure install :
« Nous avons fait avec l’aide de Christophe Caron un rétroplaning de ce qu’il y a à installer. Ce tableau
se présente sous la forme de 5 colonnes : date, composant, commentaires, qui et statut. » → est-il possible d’avoir ce rétroplanning ?


Optionnel
Vos serveurs de tests, ils sont hébergés par qui ?
*Gestion de versions et tests
*Comment gérez-vous les versions (des composants, des dépendances, de galaxy) ?
*
Quand on change de version de wrapper, comment gérer l'accès à l'ancien ?
Possibilité de cacher des wrappers. Donc on peut rejouer les historiques mais on ne pourra plus le sélectionner à gauche.
Le numéro de version du wrapper est incrémenté.
Annonce de changement de version sur la page d'accueil.
Attention aux versions de langages et outils utilisés.
Il doit y avoir plusieurs versions de R installées ou alors  MiniConda ?

Sigenae ne fonctionne pas comme cela. Ils passent à une nouvelle version et enlève l'ancienne.

*P14 : « Framagit pour la gestion de version des codes sources des wrappers et des outils et  SourceSup pour le code public » → est-ce qu’il y a du code non public ? Si oui, pourquoi ?
*


Quelles sont les étapes/ recommandations pour jongler du bac à sable → bac opérationnel (test à dev)
*Outils collaboratifs
Qui héberge et maintien votre wiki ? Il a vraiment beaucoup de fonctionnalités.
Combien de personnes ont travaillé ensemble sur ce projet ?

3 wikis : Wiki du MOOC - Wiki de chemproject - Wiki de mulcyber (sera transféré sur sourcesup).
Voir projet Chemflow publix sur  SourceSup.
Pour les sources il y a gitlab, et sourcesup pour les sources propres.

Les évolutions et les bugs sont dans un google sheet. Sera bientôt dans le gestionnaire de tickets de Gitlab.


*Com - Divers
Fanny Monod a fait vos illustrations. Est-ce quelqu’un mandaté par l’Inra ? Ou c’est vous qui avez fait la démarche de la recruter et de la payer ?

Sur quels aspects avez-vous travaillé avec MISTEA ?