Problème sbatch ulimit STAR

Bonjour, j'ai un soucis avec un sbatch en utilisant STAR j'ai ce message d'erreur qui s'affiche :
EXITING because of fatal ERROR: could not make run-time genome directory directory: sample1_STARgenome/
SOLUTION: please check the path and writing permissions

Et en cherchant sur github, il semblerait que j'ai un u-limit trop bas et comme STAR créé apparement beaucoup de fichiers temporaires, il dépasse ce u-limit, serait-il possible d'augmenter mon u-limit ?
Voici le lien github avec la solution : https://github.com/alexdobin/STAR/issues/269
Mon login est jmallet

Merci beaucoup

Bonjour Julie,

Nous avons augmenté les limites ("maximum number of open file descriptors" et "stack size") sur les nœuds de calcul.
Merci pour le signalement.
Pouvez-vous nous confirmer que c'est bon pour vous ?

Bonne journée.

J'ai re essayé et j'ai toujours le même message d'erreur
EXITING because of fatal ERROR: could not make temporary directory: sample1_STARtmp/
SOLUTION: (i) please check the path and writing permissions

Je vous mets mon sbatch pour voir si j'ai pas écris quelque chose qui va pas mais je pense pas normalement

#!/bin/bash

#SBATCH --cpus-per-task=8
#SBATCH --mem=40GB
#SBATCH -p fast
#SBATCH --ntasks=2
module load star/2.7.2b

INPUTS=('sample1' 'sample2')
for INPUT in "${INPUTS[@]}" ;
do
echo "$INPUT"

srun --ntasks=2 -c 8 STAR --genomeDir /shared/bank/rosa_chinensis/OBDH_1.0/star --runThreadN 8 --outFileNamePrefix "$INPUT" --readFilesIn Clean_Data/"$INPUT"*.fq --outSAMtype BAM SortedByCoordinate --sjdbGTFfile /shared/bank/rosa_chinensis/OBDH_1.0/gff/OBDH_1.0_gene_models.gff3

samtools index "$INPUT"_Aligned.sortedByCoord.out.bam

done

Désolé pour la suite de message mais au final, même s'il y a le message d'erreur pour les fichiers temporaires, le mapping à l'air de marcher, j'ai mon fichier BAM qui à l'air d'être correct et j'ai réussi à faire un index dessus après donc bon

Je pense que le problème vient de l'option --genomeDir /shared/bank/rosa_chinensis/OBDH_1.0/star

Vous n'avez pas le droit d'écrire dans ce dossier et STAR a besoin de cette permission (cf. https://github.com/alexdobin/STAR/blob/master/doc/STARmanual.pdf):

--genomeDir specifies path to the directory (henceforth called ”genome directory” where the
genome indices are stored. This directory has to be created (with mkdir) before STAR run
and needs to have writing permissions.

Je ne sais pas quel impact cela a.

Désolé du temps de réponse.
Je n'ai pas l'impression que cela vient de ça car c'est juste pour lui spécifier où se situe le génome de ref.
Et surtout que dans l'erreur j'ai : ERROR: could not make temporary directory: bam_data/sample2_STARtmp/

et bam_data est un de mes dossiers dans mon espace projet donc le problème semble venir de par là. Mais comme je l'ai dit malgré les messages d'erreur, mon alignement semble quand même marcher.

Bonjour ,
j ai le même erreur par STAR,alors que j ai pu aligner auparavant sans soucis,
voici les limits que je vois sur le cluster :

core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 1030662
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) 40960000
open files                      (-n) 131072
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200

Le message exacte :

EXITING because of fatal ERROR: could not open temporary bam file: 10WC_5D_S9__STARtmp//BAMsort//b8
 SOLUTION: check that the disk is not full, increase the max number of open files with Linux command ulimit -n before running STAR

Mais le bizarre est que le fichier b8 est de taille 0 ! Est -ce normal ? Il a même pas pu le remplir partiellement ?
Du coup, je peux pas évaluer quelle taille me faudrait de fichiers ouverts !

( à voir dans : /shared/projects/shmbnl_rnaseq/4W_et_10W/Nextflow_Pip/Pip_Out/6f/2e3699834f0527daf1a6d48fe9ea58/10WC_5D_S9__STARtmp/BAMsort/ )

Bonjour Maria,

Est-ce que vous reproduisez le problème (et si oui, pouvez-vous nous donner le jobid) ?
Je me demande si c'est pas une saturation d'un disque (ie. je ne suis pas sûr que la limite "open files" ait été atteinte).

Bonjour @dbenaben ,
Oui,effectivement, j ai re-essayé le pipeline,en déplacant les fastq pour avoir plus d espace disque, et ça a marché.

Bonjour Maria,
Tant mieux. Merci pour le retour !