J'aimerais faire appel à la communauté pour lancer un débat/une discussion sur les gestionnaires de workflow, notamment ceux scriptable comme Nextflow, Snakemake, et autres...
Le but ici n'est pas de générer un débat houleux pour savoir quel est le meilleur gestionnaire dans l'absolu, mais de permettre aux nouveaux venus de prendre des décisions informées pour choisir les outils qui répondent le mieux à leurs besoins.
Sur la plateforme bilille, nous sommes encore tout jeunes et nous n'avions pas encore eu le besoin de formaliser des pipelines d'analyse standard. Maintenant que nous avons des types de projets qui reviennent régulièrement nous souhaiterions pouvoir les automatiser pour une utilisation interne et pourquoi pas les partager à long terme.
Naturellement, nous avons identifié 2 gestionnaires de workflow qui semblent être beaucoup utilisés et pour lesquels nous avons déjà quelques compétences très parcellaires, et qui sont Snakemake et Nextflow. Par ailleurs, j'imagine qu'il doit y avoir des gestionnaires plus confidentiels ou en cours de dev qui mériteraient d'être évalué. Avant d'investir plus de temps pour nous former sur l'une ou l'autre des technologies, nous souhaitions faire le point sur celles qui sont utilisés dans la communauté bioinfo FR et plus particulièrement dans les plateformes de l'IFB.
Peut-on faire le point sur qui en france/europe utilise quelle techno, en particulier sur les plateformes ? Quels sont les avantages et les défauts ? Et sur quelle techno conseilleriez vous une jeune plateforme de se focaliser maintenant en 2020 ?
Je pense que ça peut être aussi l'occasion de réfléchir au futur de ces technos et si nous en tant que communauté nous souhaitons nous focaliser sur une ou plusieurs d'elles et mutualiser nos compétences.
Voilà, à vos claviers !
Merci d'avance pour vos contributions
Pierre Pericard
Bonjour Pierre,
ça m'intéresse aussi beaucoup. On est un peu dans le même cas, on commence à développer des pipelines pour notre jeune plateforme. J'ai commencé à implémenter sur l'IFB core (et modifier pas mal) RASflow (en snakemake) pour l'analyse RNAseq. Ca tourne à peu près. Je voudrais tester aussi le nf-core RNAseq (du nextflow donc). Je n'ai pas encore beaucoup de recul, mais je suis pour l'entraide!
A INRAE, nous (une petit groupe de bioinfo) nous sommes posés cette question il y a quelques temps.
Nous avons fait un tableau (en 2017 dont qui n'est plus à jour, mais ça peut vous inspirer) pour comparer les caractéristiques des gestionnaires plus ou moins en vogue sur différents critères.
La conclusion, très original, était que Snakemake et Nextflow semblait les plus "simple", compatible avec la plupart des infras et en tout cas la nôtre (Genotoul), et avec une communauté vivante et un développement actif.
Ensuite nous nous sommes créés un repo pour partager des workflows développés sur un de ces deux gestionnaires de workflow, et tant qu'à faire de le faire évoluer au fur et à mesure des projets rencontrés.
Personnellement je suis sur snakemake (je développe en python et il fallait bien commencer par un système), certains de mes collègues sont sur Nextflow dont la disponibilité de workflows existant semble mieux structuré.
Ma conclusion après ces quelques temps d'utilisation est que je n'ai pas pris le temps de tester un autre gestionnaire et que je suis très satisfaite de snakemake. Ma collègue plutôt Nextflow s'est retrouvée à utiliser un de mes pipelines snakemake et a priori n'a eu aucun problème particulier d'utilisation tout comme d'autres qui n'étaient pas particulièrement impliqués dans le développement de workflow mais plus utilisateur.
Finalement notre repo fonctionne "presque" par projet. Les projets suivant partent du dernier pipeline existant correspondant à la même analyse pour le mettre à jour et le faire évoluer. Nous avons donc les deux gestionnaires utilisés dans notre petite communauté.
ça ne répond pas complètement à votre demande, mais finalement on est assez satisfait de cette façon de fonctionner alors je me permets de le partager.
Parmi la communauté IFB, je crois qu'il y a de gros fan de Snakemake, mais c'est peut être parce qu'ils parlent plus que les autres
@mariabernard, si c'est exactement le genre de retours qui font avancer la discussion.
Donc chez vous pour l'instant les 2 technologies cohabitent c'est ça ? Tu sais si c'est le cas sur la plateforme Genotoul-bioinfo ?
Et est-ce que vous utilisez des pipelines développés par la communauté (comme nf-core par exemple) ?
Question complémentaire, à laquelle pourront probablement répondre les membres de la taskforce NNRC, c'est dans quelle mesure ces différents gestionnaires de workflow sont intégrés/compatibles avec les ressources de calcul de l'IFB?
Je pense notamment à la fonctionnalité de nextflow qui peut soumettre chaque sous-job d'un pipeline au systeme SLURM via un appel à sbatch. Est-ce qu'on pourrait envisager d'avoir un script Nextflow lancé sur le node maitre du cluster et qui ne fait que soumettre des jobs en sbatch sur les autres noeuds ? Ou bien est-ce que vous recommandez de lancer des pipelines complets (snakemake, nextflow, ...) comme un job unique ?
Bonjour,
La plupart des clusters du NNCR sont sous SLURM ou SGE. Ces deux ordonnanceurs/gestionnaires de resources sont tout à fait compatibles avec Snakemake ou Nextflow.
Comme l'a très bien dit Maria, chaque règle lance un job via sbatch ou qsub en fonction du cluster.
Côte Snakemake que je connais mieux, il est possible d'utiliser la lib DRMAA qui est une couche d'abstraction pour de nombreux ordonnanceurs (voir https://en.wikipedia.org/wiki/DRMAA#Implementations).
L'avantage de DRMAA est que le contrôle des jobs est plus fin pour le suivi du déroulement de chaque job et éventuellement l'arrêt du pipeline.
Bonjour,
Je suis bien d'accord avec Pierre sur le fait qu'un gestionnaire de workflow ne s'évalue pas dans l'absolu mais relativement à la plateforme, son infrastructure, ses compétences, etc. Je crois effectivement que la question est bien de faire un choix informé, relativement aux besoins de la plateforme.
Et c'est donc là que je mets mon grain de sel. Comparer les gestionnaires de workflow dans un débat, même idéal, n'est probablement pas suffisant. Ce serait un peu comme choisir une voiture avec force brochures et discussions avec spécialistes. Il est certain qu'à un moment ou un autre, vous aurez besoin de l'essayer. Pour résumer mon idée, je reprendrais donc les mots désormais célèbres du président de l'OMS à propos du covid19: "Il n'y a qu'une seule chose à faire, test, test, test, and test again"
C'est aussi l'occasion d'injecter dans cette discussion une idée de longue date:
Pourquoi ne pas essayer sérieusement les gestionnaires de workflow ?
Un groupe indépendant travaille à choisir, à partir d'articles publiés pour lesquelles les données réelles existent, quelques taches complexes d'analyses à effectuer. (Le mieux serait que ce groupe ne connaisse rien aux gestionnaires de workflows)
A Jour 0, on présente ces taches complexes (extraites des méthodes des articles) à N équipes chacune constituées autour d'un gestionnaire de workflow à tester - et bien sûr expertes dans ce gestionnaire.
Ces équipes travaillent i) à constituer les workflows ii) à exécuter les workflows iii) et à collecter les résultats et à les publier. Au moment de la publication des résultats, elles communiquent également leur métriques (quelle infrastructure, combien de temps, combien de personnes, etc) et leur opinion (problèmes rencontrés, points appréciés, etc
Des utilisateurs biologistes donnent aussi leur avis sur le produit fini produit par le workflow.
Alors, on est bien d'accord, ce petit "challenge" ne reviendrait pas à conduire la voiture (pour les bioinformaticiens en quête de gestionnaire). Ce serait plutôt faire un tour avec un conducteur expert du modèle. Mais il me semble que cela aiderait au delà d'un bon débat.
Ouvert à toute adaptation de l'idée pour la rendre plus concrète.
Ah ! au fait, je me porte volontaire pour faire partie de l'équipe Galaxy
Bonjour @ppericard
En ce qui concerne Curie, nous sommes partie sur nextflow, mais comme le dit @mariabernard, je pense que les différences entre snakemake et nextflow sont assez mineures, et que dans l'ensemble, les deux outils répondent au mme besoin.
Après si vous partez de zéro et n'avez pas énormément de ressources humaines, le projet nf-core est vraiment un plus. D'ailleurs, aujourd'hui, j'ai le sentiment que c'est surtout le nf-core qui porte nextflow, et je n'ai pas l'impression que la mm communauté existe coté snakeMake.
Cela vous donne accès a un grosse dizaine de pipelines validés que vous pouvez utilisez comme tels ou comme base de développements, à des bonnes pratiques de développement, et à un communauté très active pour répondre à vos questions, et vous aider.
Au plaisir d'en reparler
Nicolas
Salut Christophe,
ça m'a l'air d'être l'un des objectifs des ReproHackathons organisés entre autres par l'IFB. Je n'y ai pas participé , mais peut être les participants aux différentes éditions ont ils un avis étayé après test et comparaison ?
Salut Valentin,
J'ai suivi sans avoir le temps d'y participer l'initiative des reprohackathons et les matériels générés dans les repos GitHub.
Je n'ai pas vraiment compris que l'évaluation des gestionnaires de workflow en était un objectif. Mais peu importe ce que j'ai compris: Manifestement la question se pose encore pour BILILLE.
Moi, je me suis fait une opinion, mais la question m'intéresse aussi car j'ai tendance à me lasser de mes opinions, et j'aime bien les passer à la machine à laver
