j'ai tenté de relancer un script que j'utilisais au mois de janvier/février pour analyser des mutations entre un génome de référence et une souche d'intérêt. Pour cela, le script faisait appel à GATK4 (installé sur vos serveurs). Ce dernier arrivait à tourner complètement et sans retourner d'erreur.
Dernièrement, lorsque je lance ce script l'erreur suivante apparait : java.lang.NullPointerException.
Auriez-vous vu une idée de l'origine de celle-ci ?
J'ai tenté d'échanger les module load de place (comme cela avait fonctionné pour la commande gatk AnalyzeCovariates) mais rien n'y fait. La commande, les options et l'existence des fichiers ont également été vérifiés.
java.lang.NullPointerException
at org.broadinstitute.hellbender.utils.SequenceDictionaryUtils.getContigNames(SequenceDictionaryUtils.java:463)
at org.broadinstitute.hellbender.utils.SequenceDictionaryUtils.getCommonContigsByName(SequenceDictionaryUtils.java:457)
at org.broadinstitute.hellbender.utils.SequenceDictionaryUtils.compareDictionaries(SequenceDictionaryUtils.java:234)
at org.broadinstitute.hellbender.utils.SequenceDictionaryUtils.validateDictionaries(SequenceDictionaryUtils.java:150)
at org.broadinstitute.hellbender.utils.SequenceDictionaryUtils.validateDictionaries(SequenceDictionaryUtils.java:98)
at org.broadinstitute.hellbender.engine.GATKTool.validateSequenceDictionaries(GATKTool.java:701)
at org.broadinstitute.hellbender.engine.GATKTool.onStartup(GATKTool.java:643)
at org.broadinstitute.hellbender.engine.AssemblyRegionWalker.onStartup(AssemblyRegionWalker.java:156)
at org.broadinstitute.hellbender.cmdline.CommandLineProgram.runTool(CommandLineProgram.java:137)
at org.broadinstitute.hellbender.cmdline.CommandLineProgram.instanceMainPostParseArgs(CommandLineProgram.java:192)
at org.broadinstitute.hellbender.cmdline.CommandLineProgram.instanceMain(CommandLineProgram.java:211)
at org.broadinstitute.hellbender.Main.runCommandLineProgram(Main.java:160)
at org.broadinstitute.hellbender.Main.mainEntry(Main.java:203)
at org.broadinstitute.hellbender.Main.main(Main.java:289)
Using GATK jar /shared/mfs/data/software/miniconda/envs/gatk4-4.0.10.0/share/gatk4-4.0.10.0-0/gatk-package-4.0.10.0-local.jar
Running:
java -Dsamjdk.use_async_io_read_samtools=false -Dsamjdk.use_async_io_write_samtools=true -Dsamjdk.use_async_io_write_tribble=false -Dsamjdk.compression_level=2 -jar /shared/mfs/data/software/miniconda/envs/gatk4-4.0.10.0/share/gatk4-4.0.10.0-0/gatk-package-4.0.10.0-local.jar HaplotypeCaller -I /shared/projects/mbovis_diversity/Mbv-analyze/4_bam/Mbv-11325C1.sort.rg.md.fixmate.bam -O /shared/projects/mbovis_diversity/Mbv-analyze/5_vcf/recalls_gvcf/Mbv-11325C1_init.g.vcf -R /shared/projects/mbovis_diversity/data/reference/Mbv-L15762C1.fasta -ERC GVCF --min-base-quality-score 20 --minimum-mapping-quality 30 --sample-ploidy 1 --QUIET --verbosity ERROR
srun: error: cpu-node-81: task 0: Exited with exit code 3
L’environnement r/3.5.1 a changé, il a été mis à jour et entre autre java y a été mis à jour aussi. (A noter que r/3.6.3 est aussi disponible)
Du coup avec les 3 module load ca fait trois version de java disponible: un java dans r, un dans java-jdk et un dans gat4.
Pas toujours avec la même version:
./r-3.5.1/bin/java -version
openjdk version "1.8.0_192"
OpenJDK Runtime Environment (Zulu 8.33.0.1-linux64) (build 1.8.0_192-b01)
OpenJDK 64-Bit Server VM (Zulu 8.33.0.1-linux64) (build 25.192-b01, mixed mode)
./java-jdk-8.0.112/bin/java -version
openjdk version "1.8.0_112"
OpenJDK Runtime Environment (Zulu 8.19.0.1-linux64) (build 1.8.0_112-b16)
OpenJDK 64-Bit Server VM (Zulu 8.19.0.1-linux64) (build 25.112-b16, mixed mode)
./gatk4-4.0.10.0/bin/java -version
openjdk version "1.8.0_192"
OpenJDK Runtime Environment (Zulu 8.33.0.1-linux64) (build 1.8.0_192-b01)
OpenJDK 64-Bit Server VM (Zulu 8.33.0.1-linux64) (build 25.192-b01, mixed mode)
Pour commencer, vous pourriez donc peut-être tester sans charger java-jdk et peut-être même sans charger r si vous n'en avez pas besoin dans ce script.
Malheureusement R est nécessaire pour la commande AnalyzeCovariates de GATK qui arrive quelques lignes plus tard dans mon script. Celui que je vous ai transmis n'est en réalité qu'un extrait simplifié de la ligne où une erreur est rencontrée.
Je présume que la "solution" de rapidité serait donc de charger R juste avant AnalyzeCovariates et de le décharger après (car il m'est impossible d'isoler cette étape) ?
je viens de lancer le test avec les modules que vous m'avez transmis (merci pour votre aide !).
Mais la même erreur se produit... Idem sans charger l'environnement R.
java.lang.NullPointerException
at org.broadinstitute.hellbender.utils.SequenceDictionaryUtils.getContigNames(SequenceDictionaryUtils.java:463)
at org.broadinstitute.hellbender.utils.SequenceDictionaryUtils.getCommonContigsByName(SequenceDictionaryUtils.java:457)
at org.broadinstitute.hellbender.utils.SequenceDictionaryUtils.compareDictionaries(SequenceDictionaryUtils.java:234)
at org.broadinstitute.hellbender.utils.SequenceDictionaryUtils.validateDictionaries(SequenceDictionaryUtils.java:150)
at org.broadinstitute.hellbender.utils.SequenceDictionaryUtils.validateDictionaries(SequenceDictionaryUtils.java:98)
at org.broadinstitute.hellbender.engine.GATKTool.validateSequenceDictionaries(GATKTool.java:701)
at org.broadinstitute.hellbender.engine.GATKTool.onStartup(GATKTool.java:643)
at org.broadinstitute.hellbender.engine.AssemblyRegionWalker.onStartup(AssemblyRegionWalker.java:156)
at org.broadinstitute.hellbender.cmdline.CommandLineProgram.runTool(CommandLineProgram.java:137)
at org.broadinstitute.hellbender.cmdline.CommandLineProgram.instanceMainPostParseArgs(CommandLineProgram.java:192)
at org.broadinstitute.hellbender.cmdline.CommandLineProgram.instanceMain(CommandLineProgram.java:211)
at org.broadinstitute.hellbender.Main.runCommandLineProgram(Main.java:160)
at org.broadinstitute.hellbender.Main.mainEntry(Main.java:203)
at org.broadinstitute.hellbender.Main.main(Main.java:289)
Using GATK jar /shared/mfs/data/software/miniconda/envs/gatk4-4.0.10.0/share/gatk4-4.0.10.0-0/gatk-package-4.0.10.0-local.jar
Running:
java -Dsamjdk.use_async_io_read_samtools=false -Dsamjdk.use_async_io_write_samtools=true -Dsamjdk.use_async_io_write_tribble=false -Dsamjdk.compression_level=2 -jar /shared/mfs/data/software/miniconda/envs/gatk4-4.0.10.0/share/gatk4-4.0.10.0-0/gatk-package-4.0.10.0-local.jar HaplotypeCaller -I /shared/projects/mbovis_diversity/Mbv-analyze/4_bam/Mbv-11325C1.sort.rg.md.fixmate.bam -O /shared/projects/mbovis_diversity/Mbv-analyze/5_vcf/recalls_gvcf/Mbv-11325C1_init.g.vcf -R /shared/projects/mbovis_diversity/data/reference/Mbv-L15762C1.fasta -ERC GVCF --min-base-quality-score 20 --minimum-mapping-quality 30 --sample-ploidy 1 --QUIET --verbosity ERROR
srun: error: cpu-node-13: task 0: Exited with exit code 3
Il ne semble pas y avoir d'erreur avec --list.
La liste des commandes de GATK apparait sur le terminal mais avec ce message de fin :
Using GATK jar /shared/mfs/data/software/miniconda/envs/gatk4-4.0.10.0/share/gatk4-4.0.10.0-0/gatk-package-4.0.10.0-local.jar
Running:
java -Dsamjdk.use_async_io_read_samtools=false -Dsamjdk.use_async_io_write_samtools=true -Dsamjdk.use_async_io_write_tribble=false -Dsamjdk.compression_level=2 -jar /shared/mfs/data/software/miniconda/envs/gatk4-4.0.10.0/share/gatk4-4.0.10.0-0/gatk-package-4.0.10.0-local.jar --help
Bien-sûr ! Je peux vous proposer la commande suivante (si tenter que vous aillez accès à mes fichiers, sinon je peux vous les transmettre) qui devrait créer le fichier fichier_out_test.g.vcf à l'endroit où elle est lancée.
Remarque : elle demande plus d'espace mémoire que les commandes lancées directement dans le terminal
Cela marchait avant oui avec le même jeu de données et la même commande, je n'ai pas changé le script depuis (Janvier/Février 2020)
Merci pour votre aide, je vais tenter de refaire un alignement en rajoutant l'option -R décrit dans l'erreur du github. L'explication derrière tout cela m'échappe un peu, je l'avoue (Pourquoi cette erreur apparaît tout d'un coup ?).
Il semblerait que le java utilisé par mon script (celui de GATK) ne convienne pas : Using GATK jar /shared/mfs/data/software/miniconda/envs/gatk4-4.0.10.0/share/gatk4-4.0.10.0-0/gatk-package-4.0.10.0-local.jar
De souvenir il me semble bien que les sorties précédentes (Janvier) donnaient une adresse de java différente, celle relative au module java-jdk/8.0.112.
Je vous prie de m'excuser pour le dérangement, ces résultats sont très importants pour mon mémoire de stage que je dois rendre d'ici la fin du mois... Sans eux je risque d'être amputée d'une grosse partie de mes analyses.
La version de java utilisé dépend de l'ordre dans lequel les modules sont chargés (parce que plusieurs module inclus java avec des versions différentes)
C'est pour ca que je vous ai fait tester en changeant l'ordre.
On va rajouter les version 4.1.4.1 et 4.1.7.0 de gatk4 sur le cluster pour vous permettre de les tester:
Merci infiniment. Je suis actuellement en train de tester la version gatk4/4.1.4.1.
L'erreur ne semble pas se reproduire pour le moment, mais j'attends de voir avec l'ensemble des commandes. Comme HaplotypeCaller produisait la première erreur et que ses sorties étaient nécessaires pour la suite, je ne sais pas si les autres commandes de GATK4 fonctionnaient correctement.
NB: GATK4 semble avoir modifié cette version pour vérifier l'entête des fasta, il n'accepte plus certains caractères spéciaux
