Bonjour Jacques,
Quelques éléments de réponses, je laisse le soin aux collègues de me corriger ou compléter si besoin.
Existe--t-il une page où on explique comment lancer un script R avec srun sur le cluster ?
La documentation actuelle doit encore être mise à jours pour intégrer srun.
En attendant, Julien propose "The 5 minutes IFB Core Cluster tutorial" : The 5 minutes IFB Core Cluster tutorial - asciinema.org
Pour le moment j'utilise coupablement sinteractive, mais si vous m'indiquez les bonnes pratiques je contribuerai volontiers à la rédaction d'une page de doc spécifique sur cette question.
On prends évidemment toute aide pour la rédaction de documentation. Peut-être qu'une page de doc "exemple" sur l'usage du cluster via R serait utile.
Les principes données me semblent correctes.
Les pages de documentation (IFB Core Cluster Documentation) sont au format Markdown et gérées via le dépôt gitlab: Institut Français de Bioinformatique / Cluster / doc · GitLab
La rédaction est ouverte et discuté via des "Merge Request".
Au fait, si les librairies ne sont pas installées, peut-on en installer dans son compte ? Le fait-on avec conda ou directement via R install.package() ?
Tout est possible. On peut installer des librairies dans son /home (via conda, install.package ou autre). Et il est possible de demander ou contribuer à l'installation de ces paquets sur l'environnement commun pour qu'ils soient accessible à tous les utilisateurs.
Suivant le cas ("test d'une librairie", "installation d'une librairie pour un groupe d'utilisateurs", etc.) on privilégiera l'une ou l'autre solution.
Sur la méthode d'installation (conda, install.package, ...) je n'ai pas de recommandations particulières.
Tester son script pas à pas pour voir comment ça tourne. Au fait comment faites-vous ?
Personnellement, je privilégie toujours les scripts lancé via sbatch.
Les commandes de traitement au sein de ce script sont préfixées par srun.
Je construis le script au fur et à mesure en testant les commandes via srun (et une fois la commande validée, je copie/colle).
PS: j'avoue avoir découvert srun assez récemment (j'utilisais auparavant d'autre mécanisme tel que sinteractive).
srun permets entre autre d'avoir des métriques et un suivi plus précis et il remplace avantageusement sinteractive:
$ module load r/3.5.1
$ srun --pty R
# Toutes les commandes sont alors exécuté sur un noeud de calcul (grâce à srun)
> Sys.info()["nodename"]
nodename
"cpu-node-83.ifb.local"
sinteractive est pour l'instant indispensable pour les commandes necessitant un affichage déporté (via X11).
Attention, dans les deux cas, cela monopolise un CPU sur un nœud de calcul. De ce fait, il ne faut pas laisser traîner ce type de connexion si ce n'est pas nécessaire.
Capturer les sorties STDERR et STDOUT dans des fichiers .err et .out.
Au fait, doit-on utiliser &1 et &2 ou bien SLURM le fait-il tout seul ? Si oui comment choisit-on le chemin de ces fichiers, ou bien comment les trouve-t-on ?
Slurm capture les sorties standard et d'erreur.
Par défaut, les deux sorties sont redirigées vers un fichier "slurm-%j.out" (%j = jobid).
A noter aussi que le fichier est remplit en "live" (et pas seulement à la fin de l'exécution du job). Cela permet donc de suivre l'exécution du job.
Mais il est possible de changer ce comportement en spécifiant les fichiers pour chacune des sorties:
-o, --output=<filename pattern>
-e, --error=<filename pattern>
Vérifier le bon déroulement du script en suivant les captures de SDTOUT et STDERR
Oui en suivant le/les fichiers de sorties.
Pour avoir des inforamtions sur le/les jobs, j'aime bien utiliser aussi les commandes suivantes:
# Voir les jobs
squeue -l
# Voir mes jobs
squeue -l -u $USER
# Information sur le job
scontrol show job <jobid>
# Si on utilise srun, on peut avoir des informations précises sur les ressources utilisées
# Par exemple avec la commande ci-dessous (chaque "step" étant une commande srun):
sstat --allsteps --format=JobID,AveCPU,AveRSS,AveVMSize,AveDiskRead,AveDiskWrite,NTasks -j <jobid>
# La commande sacct remonte également beaucoup d'information sur les jobs et les ressources utilisés
sacct
# Ou en sélectionnant les colonnes qui m'interessent
sacct --format=JobID,JobName,State,Elapsed,Partition,ReqCPUS,ReqMem,ReqNodes,NodeList,AveCPU,AveRSS,AveVMSize,AveDiskRead,AveDiskWrite,ExitCode -j <jobid>
J'aime bien également recevoir un email en début/fin du job en spécifiant les options suivants à sbatch:
--mail-user=email@address
--mail-type=ALL
Accéder à ses résultats y compris les fichiers graphiques.
Quelques infos complémentaire: https://ifb-elixirfr.gitlab.io/cluster/doc/data/
Récupérer les résultats sur son ordi (rsync, filezilla, coincoin)
Sans oublier scp 
Peut-être que d'autres personnes auront d'autres pratiques ?
N'hésitez pas venir partager vos façons de faire, questionnements ou conseils.
Bonne journée
