Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vt normalize crashes with conda but works with singularity #100

Open
maehler opened this issue Nov 9, 2022 · 0 comments
Open

vt normalize crashes with conda but works with singularity #100

maehler opened this issue Nov 9, 2022 · 0 comments
Labels
bug Something isn't working

Comments

@maehler
Copy link

maehler commented Nov 9, 2022

Description of the bug

When running a workflow that includes running vt normalize, I experience crashes when running it with conda. This is the command I use to run the integration test for genomic-medicine-sweden/Twist_DNA_Hematology:

snakemake \
  -c1 \
  --use-conda \
  --configfile config/config.yaml \
  --notemp \
  -s ../../workflow/Snakefile \
  --show-failed-logs

And this is the error message I get:

/usr/bin/bash: line 1:  2859 Floating point exception(core dumped) ( vt normalize -n -r reference/FLT3.fasta -o snv_indels/freebayes/HD829_T.normalized.vcf.gz snv_indels/freebayes/HD829_T.decomposed.vcf.gz ) &>snv_indels/freebayes/HD829_T.normalized.vcf.gz.log
[Wed Nov  9 12:40:27 2022]
Error in rule snv_indels_vt_normalize:
    jobid: 40
    output: snv_indels/freebayes/HD829_T.normalized.vcf.gz
    log: snv_indels/freebayes/HD829_T.normalized.vcf.gz.log (check log file(s) for error message)
    conda-env: /home/nima18/git/Twist_DNA_Hematology/.tests/integration/.snakemake/conda/be6f18bc3f819c7c47718a8b01879f46_
    shell:
        (vt normalize -n -r reference/FLT3.fasta -o snv_indels/freebayes/HD829_T.normalized.vcf.gz snv_indels/freebayes/HD829_T.decomposed.vcf.gz ) &> snv_indels/freebayes/HD829_T.normalized.vcf.gz.log
        (one of the commands exited with non-zero exit code; note that snakemake uses bash strict mode!)
Logfile snv_indels/freebayes/HD829_T.normalized.vcf.gz.log:
normalize v0.5

options:     input VCF file                                  snv_indels/freebayes/HD829_T.decomposed.vcf.gz
         [o] output VCF file                                 snv_indels/freebayes/HD829_T.normalized.vcf.gz
         [w] sorting window size                             10000
         [n] no fail on reference inconsistency for non SNPs true
         [q] quiet                                           false
         [d] debug                                           false
         [r] reference FASTA file                            reference/FLT3.fasta

[E::idx_find_and_load] Could not retrieve index file for 'snv_indels/freebayes/HD829_T.decomposed.vcf.gz'

The error message states that and index for the input VCF file cannot be found, and this is true. However, rerunning after adding the index manually still results in the same error. This is something I have been able to reproduce both locally and using Github actions.

If I understand things correctly, the version in the conda environment should be the same as in the corresponding Docker image. The version in the docker image is just listed as 2015.11.10, and the one in the conda environment is 2015.11.10, build h5ef6573_4. Looking in bioconda, this particular build of this version is not the one that has the largest number of downloads. This is instead the build he941832_3.

Out of curiosity I cloned a local copy of snv_indels and modified the vt environment yaml to use the he941832_3 build:

channels:
    - bioconda
    - conda-forge
    - defaults
dedendencies:
    - cryptography=3.4.8
    - vt==2015.11.10=he948132_3

This behaved as expected, and produced a normalized file identical to what is produced when running the same workflow using singularity, with the exception of a different version of bcftools in the header:

63,66c63,66
< ##bcftools_viewVersion=1.13+htslib-1.13
< ##bcftools_viewCommand=view --output-type v -; Date=Wed Nov  9 12:32:50 2022
< ##bcftools_concatVersion=1.13+htslib-1.13
< ##bcftools_concatCommand=concat --output-type v -o snv_indels/freebayes/HD829_T.merged.vcf snv_indels/freebayes/HD829_T_chr13.vcf.gz; Date=Wed Nov  9 12:32:58 2022
---
> ##bcftools_viewVersion=1.14+htslib-1.14
> ##bcftools_viewCommand=view --output-type v -; Date=Wed Nov  9 13:38:09 2022
> ##bcftools_concatVersion=1.15.1+htslib-1.15.1
> ##bcftools_concatCommand=concat --output-type v -o snv_indels/freebayes/HD829_T.merged.vcf snv_indels/freebayes/HD829_T_chr13.vcf.gz; Date=Wed Nov  9 13:40:06 2022

The question is then whether this can be considered the same version that is included in the Docker image, and whether it makes sense to change the version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant