Bonjour,
Serait-il possible d'avoir la dernière version de variant effect predictor s'il vous plait? Sauf erreur la dernière version disponible à l'IGBMC est la 98.
Merci par avance,
Quentin
Je fais ça !
Hop:
module load ensembl-vep/103.1
1 « J'aime »
Merci. Très réactif 
Est ce que vous avez mis les plugins de VEP? Si oui ils y sont tous? Si non dois je vous donner la liste de ceux qui m'intéresse ou vous les mettez tous?
Oui, les plugins sont installés ainsi que loftee.
Je n'ai pas l'habitude d'utiliser VEP (ni les plugins), pouvez-vous nous confirmer que c'est bon de votre côté ?
En fait j'aurais besoin de savoir ou sont les caches (par défaut il cherche dans HOME/.vep.homo_sapiens) pour que je ne les retélécharge pas. Dans l'idéal il me faudrait les deux version du génomes humain (Je travaille principalement sur grch38, mais pour des raisons de cohérence avec d'ancien projet pour certain je dois rester sur l'ancienne version).
De même il me faudrait le chemin du cache plugin.
La commande which vep peut vous renvoyer le chemin vers le binaire (créé via un environnement conda).
Les dossiers générés par l'installation se trouvent alors dans cet environnement.
Le dossier des plugins:
/shared/ifbstor1/software/miniconda/envs/ensembl-vep-103.1/share/ensembl-vep-103.1-0/
En revanche, il n'y a pas de cache installé par défaut.
On vous laisse le soin de les (re)télécharger du coup.
@team.bank Ca vaut peut-être le coup de les placer dans /shared/bank ?
Bonjour,
j'aimerais aussi pouvoir utiliser VEP avec les caches installés.
@team.bank, je ne les ai pas vu dans /shared/bank/homo_sapiens, mais peut-être ont-ils été mis ailleurs ?
Si c'était possible, pourrait-on avoir les caches pour la GRCh37 et la GRCh38 ? Comme Quentin, je dois travailler sur d'anciens projets..
Sinon, ben tant pis, je les télécharge de mon côté.
Merci d'avance,
Sandrine
Au final j'ai téléchargé les caches ce n'est pas très lourd et rapide à télécharger, il suffit d'une seule commande, pour l'homme grch38 par exemple avec tous les plugins :
`
> vep_install -a cfp -s homo_sapiens -y GRCh38 -g all --CONVERT
`
Ce qui est plus problématique ce sont les data nécessaires pour les plugins, c'est pas hyper pratique a télécharger et à préparer, certaines sont sur des serveurs avec une très mauvaises connexion rendant leur téléchargement extrêmement lent.
Vep a l'inconvénient de ses avantages, il est très complet mais son installation est un peu un enfer.
1 « J'aime »
Merci Quentin. En effet, ne les trouvant pas, j'ai moi aussi chargé les caches pour GRCh37 et 38.
Les données pour les plugins sont aussi en train de me poser quelques soucis, mais on va y arriver !
Si nous pouvons partager tout ou partie des données de VEP, je pourrais les mettre à disposition.
Donnez-moi les bonnes commandes 
Bonjour Gildas,
pour les caches la commande pour télécharger la version ensembl de grch38 est :
module load ensembl-vep/104.3
vep_install -a cf -s homo_sapiens -y GRCh38 -c /output/path/to/GRCh38/vep --CONVERT
Sinon, et plus globalement il faut les télécharger avec wget ou curl puis les extraire avec tar xzf. Les adresses pour tous les caches de l'homme pour la dernière version de vep:
http://ftp.ensembl.org/pub/release-104/variation/indexed_vep_cache/homo_sapiens_merged_vep_104_GRCh37.tar.gz
http://ftp.ensembl.org/pub/release-104/variation/indexed_vep_cache/homo_sapiens_merged_vep_104_GRCh38.tar.gz
http://ftp.ensembl.org/pub/release-104/variation/indexed_vep_cache/homo_sapiens_refseq_vep_104_GRCh37.tar.gz
http://ftp.ensembl.org/pub/release-104/variation/indexed_vep_cache/homo_sapiens_vep_104_GRCh37.tar.gz
http://ftp.ensembl.org/pub/release-104/variation/indexed_vep_cache/homo_sapiens_vep_104_GRCh38.tar.gz
http://ftp.ensembl.org/pub/release-104/variation/indexed_vep_cache/homo_sapiens_refseq_vep_104_GRCh38.tar.gz
Sinon il y a tous les autres cache ici :
http://ftp.ensembl.org/pub/release-104/variation/indexed_vep_cache/
il est aussi préférable de les convertir avec le script vep_convert_cache
module load ensembl-vep/104.3
vep_convert_cache -dir /path/to/dir/with/cache --species all --version all
Pour les données des plugins c'est bien plus compliqués. Je suis en train de me faire mon dossier avec les données pour les plugins que j'utilise avec un dossier par plugin, le plus simple est peut etre de les prendre depuis là mais il n'y aura évidement pas tout.
Bonjour,
Est ce possible de me confirmer que vep 104 fonctionne chez vous ?
Quand je le lance en utilisant module load ensembl-vep/104.3 et en utilisant les caches de la version 104 il échoue très rapidement avec une erreur disant qu'il ne trouve pas les caches mais surtout il ne les trouve pas car il cherche les caches de la version 103. Ça n'a pas vraiment de sens pour moi donc merci de m'éclairer sur :
Version de vep utilisé
Version du cache
Cache classique ou merged ?
Pour info quand je crée une image singularity à partir de l'image docker de vep 104 ça fonctionne...
Bonjour Quentin,
Oui, moi aussi j'utilise la version 104 de vep.
Dans mon script, j'ai aussi module load ensembl-vep/104.3
donc ce n'est pas ça qui coince.
Je travaille avec des vcf en GRCh37, donc j'ai téléchargé le cache 104_GRCh37 dans mon projet, et je donne le nom du dossier avec --dir_cache (en plus de l'option --cache)
Et en classique, je n'ai pas essayé le merged.
Et enfin j'ai juste à lancer mon script avec une commande en sbatch.
Est-ce que vous lui donnez bien le chemin d'accès au cache 104 ?
Bonjour,
J'ai essayé soit sans mettre le chemin du cache (car il est dans $HOME/.vep donc il doit le trouver tout seul, ce que fait bien la version docker) et en lui mettant le chemin de manière explicite.
Je ne comprend pas bien ce qui coince, je vais essayé avec les caches merged ou refseq pour voir si ca coincerait pas juste avec les caches de grch38 ensembl
Voilà ma commande complète, pour comparaison :
vep -i /shared/projects/metapoi/WES_Radiosensibles/VCFfiles/B00HFY2_HG19_SNP.annot.vcf -o /shared/projects/metapoi/WES_Radiosensibles/VEPoutput/B00HFY2_HG19_SNP.annot-vep.tsv --format vcf --assembly GRCh37 --cache --dir_cache /shared/projects/metapoi/WES_Radiosensibles/Data --tab --force_overwrite --show_ref_allele --hgvs --hgvsg --fasta /shared/bank/homo_sapiens/GRCh37/fasta/Homo_sapiens.GRCh37.dna.primary_assembly.fa --symbol --canonical --biotype --regulatory --flag_pick --pick_order rank --plugin dbNSFP,/shared/projects/metapoi/WES_Radiosensibles/Data/Plugin_Custom/dbNSFP4.0a.gz,ALL --plugin dbscSNV,/shared/projects/metapoi/WES_Radiosensibles/Data/Plugin_Custom/dbscSNV1.1_GRCh37.txt.gz
Je dis que je veux le cache avec --cache, et je lui donne le chemin explicite avec --dir_cache
Ma commande semble bonne donc je ne comprend vraiment pas et surtout ce qui m'étonne c'est que ca fonctionne avec l'image docker (via singularity). La seule chose que je pense c'est un problème au niveau du package conda qui rend l'utilisation du cache grch38 ensembl impossible? Je sais que le package conda a été mis à jour il y a 5 jours (sans qu'il y ai de nouvelle version de vep, c'est juste le conda qui change) donc peut être qu'il y avait des bug?
Ma commande vep avec singularity (qui fonctionne):
singularity exec ${vep_sif} /opt/vep/src/ensembl-vep/vep \
--everything \
--fork ${SLURM_CPUS_PER_TASK} \
--input_file ${VCF_input} \
--output_file ${VCF_output_DIR}/${vcf_output} \
--stats_file ${VCF_output_DIR}/${stat_file} \
-v \
--format vcf \
--cache \
--dir_cache /dev/shm/.vep \
--offline \
--buffer_size 20000 \
--fasta ${REF_Genome} \
--vcf \
--compress_output gzip \
--nearest symbol \
--total_length \
--no_escape \
--custom ${gnomad_genome},gnomADg,vcf,exact,0,AF_AFR,AF_AMR,AF_ASJ,AF_EAS,AF_FIN,AF_NFE,AF_OTH \
--warning_file ${VCF_output_DIR}/${warning_file} \
--vcf_info_field ANN \
--hgvsg \
--check_existing \
--gencode_basic
Et en mettant le cache directement dans le dossier du projet ? Je sais ce n'est pas forcément idéal, mais ce n'est pas lourd, ça vaut la peine d'essayer.
Je n'ai aucune idée de pourquoi ça marche via singularity et pas directement.
Il ya quoi dans le répertoire /dev/shm/.vep \ ?
Dans /dev/shm/.vep c'est juste mes caches (je les met dans la ram pour que ca aille plus vite).
Pour l'instant je vais rester avec singularity ca semble marcher, je verrais plus tard pourquoi ca ne marche pas avec le module load