Howdy, everyone!!! I'm running nf-core/sarek 3.8.1 (tumor-only Mutect2,

step: variant_calling

) on a cfDNA sample processed with the Twist cfDNA library + UMI + UDI + capture panel. The input BAM was generated by nf-core/fastquorum (duplex consensus). After FilterMutectCalls, I'm getting a surprisingly high number of variants flagged as

orientation

(~418 out of 662). I'm wondering whether this filter makes sense when the input is a consensus BAM. Is orientation bias artifact detection expected to work correctly in this context? If it doesn't, is there a supported way in sarek to skip

LearnReadOrientationModel

/ the orientation priors step? Any help with this would be amazing! Thank you in advance!

we don't have skipping of LearnReadOrientationModel in sarek yet. I would recommend trying to catch the output of MERGE_MUTECT2 that should contain the non filtered vcfs

Hello @Maxime Garcia I had two potential solutions: • Option 1 — Strip the

orientation

flag from the filtered VCF. Simple, but statistically incorrect:

FilterMutectCalls

runs a joint probabilistic model and removing one flag after the fact leaves an internally inconsistent VCF. • Option 2 — Re-run

FilterMutectCalls

on the raw VCF without passing

--ob-priors

. All other filters remain active; the orientation model simply never fires. This is the cleaner approach and sarek already saves all necessary intermediates. I believe that this issue will affect any fgbio UMI pipeline, not just ours.

CallDuplexConsensusReads

normalises all output to F1R2 by design (see a snapshoot of an IGV window), so the orientation filter will always fire on consensus BAMs. Might be worth flagging in the docs or adding a parameter to skip

LearnReadOrientationModel

for consensus BAM inputs.

Yeah, when you make duplex consensus reads the fgbio default is to make them all align onto one strand (as you have combined the two strands)

Exactly @Simon Pearce. That's what I see on the consensus BAM files (above).