Nextflow

Nextflow est un logiciel permettant d'exécuter des flux de travail scientifiques reproductibles. Le terme Nextflow est utilisé pour décrire à la fois le langage spécifique au domaine (DSL) dans lequel les pipelines sont écrits et le logiciel utilisé pour interpréter ces flux de travail.

Utilisation

Chargez le module Nextflow avec module load nextflow.

Bien que vous puissiez créer votre propre flux de travail, vous pouvez également utiliser les pipelines nf-core qui sont publiés. Nous décrivons ici une configuration simple qui vous permettra d'exécuter des pipelines nf-core sur nos systèmes et vous aidera à configurer correctement Nextflow pour vos propres pipelines.

Dans notre exemple, nous utilisons le pipeline nf-core/smrnaseq.

Installation

Cette procédure doit être exécutée sur un nœud de connexion.

Installez d'abord un paquet pip pour aider à la configuration; veuillez noter que les outils nf-core peuvent prendre beaucoup de temps à installer.

module purge # pour éviter la pollution par des modules précédemment chargés 
module load python/3.8
module load postgresql/15.3
python -m venv nf-core-env
source nf-core-env/bin/activate
python -m pip install nf_core==2.6

Entrez le nom du pipeline à tester et chargez Nextflow et Apptainer. (Apptainer est le successeur de Singularity.) Nextflow s'intègre bien à Apptainer.

export NFCORE_PL=smrnaseq
export PL_VERSION=1.1.0
module load nextflow/22.10.6
module load apptainer/1.2

Une étape importante consiste à télécharger toutes les images Apptainer qui seront utilisées pour exécuter le pipeline, en même temps que nous téléchargeons le flux de travail lui-même. Si cela n'est pas fait, Nextflow essaiera de télécharger les images à partir des nœuds de calcul, juste avant l'exécution des étapes. Cela ne fonctionnera pas sur la plupart de nos grappes car il n'y a pas de connexion internet sur les nœuds de calcul.

Créez un dossier dans lequel les images seront stockées et configurez la variable d'environnement NXF_SINGULARITY_CACHEDIR pour y pointer. Les images des flux de travail sont souvent volumineuses; ne les stockez donc pas dans votre espace $HOME car son quota est limité. Stockez-les plutôt dans l'espace /project.

mkdir /project/<def-group>/NXF_SINGULARITY_CACHEDIR
export NXF_SINGULARITY_CACHEDIR=/project/<def-group>/NXF_SINGULARITY_CACHEDIR

Partagez ce dossier avec les membres de votre groupe qui utiliseront Nextflow avec Apptainer, afin de réduire la duplication. De plus, vous pouvez ajouter la commande export à votre ~/.bashrc pour plus de commodité.

La commande suivante télécharge le pipeline smrnaseq dans votre répertoire /scratch et place toutes les images dans le répertoire cache.

cd ~/scratch
nf-core download --singularity-cache-only --container singularity  --compress none -r ${PL_VERSION}  -p 6  ${NFCORE_PL}
# Alteratively, you can run the download tool in interactive mode
nf-core download

Ce flux de travail télécharge 18 conteneurs pour un total d'environ 4Go et crée le dossier nf-core-${NFCORE_PL}-${PL_VERSION} avec les sous-dossiers workflow et config. Le sous-dossier config inclut la configuration pour votre établissement, tandis que le flux de travail se trouve dans le sous-dossier workflow.

Un pipeline type nf-code ressemble à ceci :

$ ls nf-core-${NFCORE_PL}-${PL_VERSION}/workflow
assets  bin  CHANGELOG.md  CODE_OF_CONDUCT.md  conf  Dockerfile  docs  environment.yml  lib  LICENSE  main.nf  nextflow.config  nextflow_schema.json  README.md

Quand le pipeline est prêt à être lancé, Nextflow examine le fichier nextflow.config ainsi que le fichier ~/.nextflow/config (s'il existe) pour contrôler l'exécution du flux de travail. Les pipelines nf-core ont tous une configuration par défaut, une configuration de test et des configurations de conteneur (singularité, podman, etc.). Vous avez également besoin d'une configuration personnalisée pour la grappe (Narval, Béluga, Cedar ou Graham) sur laquelle les pipelines sont exécutés. Les pipelines Nextflow peuvent également s'exécuter sur Niagara s'ils ont été conçus expressément pour cette grappe, mais nous vous déconseillons généralement d'y exécuter tout pipeline Nextflow.

Configuration pour nos grappes

Vous pouvez utiliser la configuration suivante en modifiant la valeur par défaut des processus nf-core et en entrant les informations appropriées pour la grappe Béluga ou Narval. Cette configuration est enregistrée dans un bloc de profil qui sera chargé lors de l'exécution.

File : ~/.nextflow/config

singularity {
  autoMounts = true
}

apptainer {
  autoMounts = true
}

process {
  executor = 'slurm' 
  clusterOptions = '--account=<my-account>'
  errorStrategy = 'retry'
  maxRetries = 1
  errorStrategy = { task.exitStatus in [125,139] ? 'retry' : 'finish' }
  memory = { check_max( 4.GB * task.attempt, 'memory' ) }
  cpu = 1  
  time = '3h' 
}

executor {
  pollInterval = '60 sec'
  submitRateLimit = '60/1min'
  queueSize = 100 
}

profiles {
  beluga {
    max_memory='186G'
    max_cpu=40
    max_time='168h'
  }
  narval {
    max_memory='249G'
    max_cpu=64
    max_time='168h'
  }
}

Remplacez <my-account> par votre propre compte qui est semblable à def-pname. Le bit singularity.autoMounts = true fait en sorte que tout le dossier sera correctement monté à l'intérieur du conteneur Singularity.

Cette configuration garantit qu'il n'y a pas plus de 100 tâches dans la file d'attente Slurm et que seules 60 tâches sont soumises par minute. Elle indique que les nœuds de calcul Béluga ont 40 cœurs et 186 Go de RAM avec un temps réel maximum d'exécution d'une semaine (168 heures).

La configuration est liée au système sur lequel se fait l'exécution, mais elle est également liée au pipeline lui-même. Par exemple, ici cpu = 1 est la valeur par défaut, mais certaines étapes du pipeline peuvent en utiliser plus. Cela peut devenir assez compliqué et les étiquettes dans le fichier workflow/conf/base.config sont utilisées pour identifier une étape avec une configuration spécifique, ce dont nous ne parlons pas ici.

Le script implémente un comportement de redémarrage par défaut qui ajoute automatiquement de la mémoire aux étapes ayant échoué qui ont le code ret 125 (mémoire insuffisante) ou 139 (processus annulé car il a utilisé plus de mémoire que ce qui était alloué).

Exécution du pipeline

Use the two profiles provided by nf-core—test and singularity-and the profile we have just created for Béluga.

Utilisez les deux profils fournis par nf-core (test et singularity) et le profil que nous venons de créer pour Béluga. Notez que Nextflow est principalement écrit en Java et a tendance à utiliser beaucoup de mémoire virtuelle. Sur Narval, cela ne posera pas de problème, mais avec le nœud de connexion de Béluga, vous devrez modifier la mémoire virtuelle pour exécuter la plupart des flux de travail. Pour définir la limite de mémoire virtuelle à 40Go, utilisez la commande ulimit -v 40000000. Nous suggérons aussi d'utiliser un multiplexeur de terminal, de sorte que le pipeline Nextflow fonctionnera toujours si vous êtes déconnecté, et vous pourrez ensuite vous reconnecter au processus du multiplexeur. Notez que l'exécution de Nextflow est facile sur les nœuds de connexion de Béluga et Naval, mais plus difficile sur Graham et Cedar puisque la limite de mémoire virtuelle des nœuds de connexion ne peut pas être modifiée sur ces grappes; nous vous recommandons de lancer Nextflow à partir d'un nœud de calcul, où la mémoire virtuelle n'est jamais limitée.

nextflow run nf-core-${NFCORE_PL}-${PL_VERSION}/workflow -test de profil,singularité,beluga --outdir ${NFCORE_PL}_OUTPUT

Vous avez maintenant démarré le sous-ordonnanceur Nextflow sur le nœud de connexion. Ce processus envoie les tâches à Slurm lorsqu'elles sont prêtes à être traitées.

Vous pouvez voir la progression du pipeline. Il est aussi possible d'ouvrir une nouvelle session sur la grappe ou de vous détacher de la session tmux pour voir les tâches dans la file d'attente Slurm avec squeue -u $USER ou sq.

Problèmes connus

Des erreurs SIGBUS du processus principal de Nextflow ont été signalées. Nous soupçonnons que c'est à cause des problèmes Nextflow suivants :

 * https://github.com/nextflow-io/nextflow/issues/842
 * https://github.com/nextflow-io/nextflow/issues/2774

Le fait de définir la variable d'environnement NXF_OPTS="-Dleveldb.mmap=false" à l'exécution de nextflow semble résoudre le problème.