Question about --no-default-filter being automatically applied in lofreq call-parallel #153
Description
Hi there,
I'm encountering some unexpected behavior with lofreq call-parallel and would like to understand why --no-default-filter is being automatically applied when I didn't specify it in my command.
Command used:
lofreq call-parallel --pp-threads 60 -f ../data/general_data/ref/reference_seq.fasta -o ../data/processed_data/lofreq_vcf/PRJ_F/F5.vcf ../data/processed_data/bwa_bam_sample/PRJ_F/F5.bam
Issue observed:
Looking at the VCF header, I can see that the actual command executed internally was:
##source=lofreq call -f ../data/general_data/ref/reference_seq.fasta --no-default-filter -r 69438-NA1-genomic:1-118 -o /tmp/lofreq2_call_parallelz2y723oa/0.vcf.gz ../data/processed_data/bwa_bam_sample/PRJ_F/F5.bam
Questions:
Why does lofreq call-parallel automatically add --no-default-filter?
According to the documentation, LoFreq has built-in filtering criteria that should be sufficient without additional filtering. How can I ensure the default filters are applied when using call-parallel?
Comparison test:
When I run the regular lofreq call command without the parallel option:
lofreq call -f ../data/general_data/ref/reference_seq.fasta -o ../data/processed_data/lofreq_vcf_new/PRJ_F/F5.vcf ../data/processed_data/bwa_bam_sample/PRJ_F/F5.bam
I get slightly different variant counts, and both approaches seem to have some strand bias issues in the results.
Could you please clarify the expected behavior of call-parallel regarding default filtering, and advise on the best practice for applying LoFreq's built-in filters with parallel processing?
Attached files:
I have attached two VCF files for your reference:
VCF file generated by call-parallel (with --no-default-filter)
VCF file generated by regular call
You can see the differences in variant calling results between the two approaches.
Thank you for your time and assistance!