Hi, does anyone have issues with GATK4_MERGEVCFS when using FreeBayes for somatic calling? The variant calling ran successfully up to the annotation step, but when I checked the annotated outputs, they were empty. I then looked at the

freebayes.filtered.vcfs

, and they can’t be opened due to a parsing error:

[E::vcf_parse_format_fill5] Invalid character '.' in 'GQ' FORMAT field at chr1:10146
Error: VCF parse error.

However, the per-chromosome VCFs (before the merging step) are fine. So my guess is that the issue might be related to GATK4_MERGEVCFS. Interestingly, VCFs from other tools like Mutect2 or Strelka work without issues. Here is my run cmd:

nextflow run nf-core/sarek -r 4bd2948 \
    -w /storage/temp \
    -c custom.config \
    -C my_nextflow.config \
    --input samplesheet.csv \
    --outdir results \
    --genome GATK.GRCh38 \
    --step variant_calling \
    --only_paired_variant_calling \
    --normalize_vcfs true \
    --tools strelka,mutect2,freebayes,manta,vep \
    -with-report \
    -resume

Appreciate any ideas!

FreeBayes should be setting the

GQ

format field correctly, but it could be that in some cases it is

.

. Can you compare the filtered FreeBayes VCF with the original one at the position (

chr1:10146

) where the error occurs to see what

GQ

looks like?

I've checked the original vcf .chr1_10001-207666.gz.sort.vcf.gz and there is GQ 16.2991 at position chr1:10146. However in merged .freebayes.vcf.gz from MERGE_FREEBAYES step, I already got that error: [E::vcf_parse_format_fill5] Invalid character '.' in 'GQ' FORMAT field at chr1:10146 Error: VCF parse error It’s the same for all samples in my dataset; it always displays this error on chr1 at similar positions. And the GQ value is always present. What seems strange to me is that the pipeline continues normally after this step, producing corrupted (with parsing errors) or empty annotated VCFs.

generally, I avoid using gatk tools for anything other than gatk based outputs 😕

I found the bug reported on the site of Freebayes. Is this sth which can be solved in sarek? @Rike Hanssen @Maxime Garcia? https://github.com/freebayes/freebayes/issues/784 https://github.com/freebayes/freebayes/issues/818 Also, it is really weird that nobody has encountered this so far

so for the first issue, that is something that can be done indeed

so, what is the solution then?🤔

I am confused about 818, but 784 you can indeed fix with a custom config for now

Ok, I’ll try it ☺️ , thank you

Yes, I have run into such issues with wrong data types in VCFs before. Not while running the pipeline though (but I may not have done the same type of merging as you), but in postprocessing. My brute-force solution was to fix the type in the VCF headers with something like

sed

or

awk

. But if you can get

--strict-vcf

to work (check the module config if you need to copy over any other parameters to the

ext.args

in your custom config), that should be much more elegant and potentially more compatible. @Maxime Garcia, @Rike Hanssen, is there anything that speaks against making

--strict-vcf

the default? (I have no problem with

GQ

being a float, but then that should also be advertised in the header, otherwise it will break any tool that does common-sense checks.)

Thank you @Thomas Danhorn ! I added —strict-vcf together with defaults ext.args and it worked ☺️