Question about --no-default-filter being automatically applied in lofreq call-parallel

[YangJingqii]

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!

vcf.zip