Bonjour,
Si je comprends bien les recommendations pour l'utilisation/l'installation d'outils sur le cluster, il est conseillé d'utiliser en priorité:
- les modules déjà installés et dispo via module avail
- sinon par défaut, les environnements conda partagés accessible en chargeant le module conda: module load conda & conda env list
- et en dernier recours des environnements conda privés.
Tout d'abord une question préliminaire pour être sur que je comprenne bien le fonctionnement. Est-ce que tous les environnements conda partagés sont dispo sous forme de modules, ou bien il y a-t'il plus d'outils dispo via les environnements conda partagés ?
En fonction des projets sur lesquels je travaille, et en particulier s'il s'agit de projets exploratoires, je peux être amené à tester un certain nombre d'outils récents et pas forcément "standard", mais dispo sur bioconda. Généralement, je laisse tomber assez vite un certain nombre de ces outils après avoir identifié celui ou ceux qui répondent le mieux à mes besoins. Par conséquent, ce n'est pas forcément pertinent de demander au support du cluster d'installer et de mettre à dispo de la communauté ces outils.
De même, je préfère souvent utiliser les dernières versions des outils, pour des raisons de perf ou de correction de bugs, mais je n'ai pas envie d'embêter le support trop souvent pour mettre à jour des modules.
Si je comprends bien les recommendations ce serait alors un cas d'application adapté à un environnement conda privé.
Pouvez-vous me confirmer que j'interprète bien les recommandations d'utilisation du cluster ?
En testant l'utilisation d'environnement conda privés sur le cluster j'ai rencontré un problème avec la soumission de jobs via sbatch.
Par exemple, j'ai souhaité utilisé la dernière version de cutadapt (v2.6; la plus récente dispo dans les modules est la 1.10 qui n'est pas multi-threadé). Je l'ai donc installé comme j'en ai l'habitude dans un environnement conda privé (conda create -n cutadapt cutadapt).
Lorsque je lance un job directement depuis mon terminal, ça fonctionne correctement (conda activate cutadapt & srun cutadapt --help). Par contre, si je lance la même chose depuis un script bash via sbatch j'ai l'erreur suivante:
CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.
To initialize your shell, run
$ conda init <SHELL_NAME>
Currently supported shells are:
- bash
- fish
- tcsh
- xonsh
- zsh
- powershell
See 'conda init --help' for more information and options.
IMPORTANT: You may need to close and restart your shell after running 'conda init'.
slurmstepd: error: execve(): cutadapt: No such file or directory
slurmstepd: error: execve(): cutadapt: No such file or directory
slurmstepd: error: execve(): cutadapt: No such file or directory
slurmstepd: error: execve(): cutadapt: No such file or directory
slurmstepd: error: execve(): cutadapt: No such file or directory
slurmstepd: error: execve(): cutadapt: No such file or directory
slurmstepd: error: execve(): cutadapt: No such file or directory
slurmstepd: error: execve(): cutadapt: No such file or directory
srun: error: cpu-node-81: tasks 0-7: Exited with exit code 2
Pouvez-vous m'expliquer la manière correcte d'utiliser un environnement conda privé via une soumission sbatch ?
Merci d'avance
Pierre
Entre temps, j'ai trouvé comment faire fonctionner mes environnements conda privés. Je rajoute juste un simple "source ~/.bashrc" dans le script sbatch avant le "conda activate cutadapt". Ca permet à conda de s'initialiser correctement.
Par contre je me suis aussi rendu compte que une installation locale de conda (type Miniconda) interfère avec le conda dispo via les modules. Justement à cause de l'initialisation de conda dans le .bashrc, si je fait un "module load conda", conda est bien dispo depuis /shared/software/miniconda/bin/conda.
Par contre, si j'enchaine avec "conda env list" ce sont mes environnements privés qui sont listés par le conda partagé.
Bilan des courses, il faut commenter la partie initialisation de conda dans le .bashrc et se reloguer pour pouvoir accéder correctement au conda partagé et ses environnements.
Je pense que ça mérite un warning dans la doc pour indiquer que il faut choisir entre utiliser le conda partagé ou bien un conda privé, parce que les deux ne peuvent pas fonctionner ensemble.
Bonjour Pierre,
Nos réponses se croisent à quelques minutes 
Pour répondre à vos premières interrogations et en espérant que mes collègues me corrigeront si je dis des bêtises, nous avons adopté la logique suivante:
-
Nous utilisons "module" pour présenter les logiciels disponibles et les charger.
Avec l'idée de "un logiciel = un module" (et non un environnement complet comme le permets Conda).
Derrière, peu importe ce qui est utilisé (Conda, Singularity ou autre).
Normalement, les outils installés via Conda sont tous disponibles par module.
-
Il est tout à fait possible d'utiliser conda, singularity ou autre pour installer les logiciels dans son /home
-
Comme vous le dites, c'est en fonction du besoin ("test d'outil" versus "outil partagé") et des connaissances de chacun (conda, singularity, etc) que l'on privilégiera l'une ou l'autre solution.
Sur les versions d'outils, cela ne nous embête pas de les mettre à jours. Cela bénéficie en effet à toute la communauté.
Si vous êtes à l'aise avec conda, il est tout à fait possible de contribuer (ajout d'un logiciel, ajout d'une version, etc) via le dépôt mis en place: Institut Français de Bioinformatique / Cluster / conda-env · GitLab (c'est expliqué dans le README, vous pouvez aussi consulter les "MergeRequest" précédentes).
En testant l'utilisation d'environnement conda privés sur le cluster j'ai rencontré un problème avec la soumission de jobs via sbatch.
En effet, je constate le même problème. Merci pour la remarque.
Depuis Conda 4.6 (Anaconda | Conda 4.6 Release), il est necessaire d'initialiser son environnement avec conda init.
Cette commande modifie le .bashrc pour ajouter les variables d'environnement qui vont bien.
Mais lorsqu'un job est soumis et exécuté via Slurm, le fichier .bashrc n'est pas chargé (Slurm Workload Manager -).
D'où l'erreur. Apparemment on est pas seul à tomber dessus: "conda activate" can't activate or switch environments during a job submitted to a queuing system, even though passing full environment_variables. · Issue #8536 · conda/conda · GitHub
En attendant de trouver une meilleur solution, je vous propose d'ajouter les deux lignes suivantes dans votre script (après avoir chargé conda et avant d'activer l’environnement privé cutadapt):
module load conda
# Lignes à ajouter:
CONDA_ROOT=/shared/software/miniconda/
source $CONDA_ROOT/etc/profile.d/conda.sh
conda activate cutadapt
Note: On pourrait également exécuter source ~/.bashrc après avoir chargé l'environnement. Cela fonctionne mais renvoie quand même le warning (Your shell has not been properly configured to use).
Bon après-midi
4 « J'aime »
Merci beaucoup David pour la réponse super complète !!!