Difference between pre-made pileup and mini-pileups

[sambrightman]

Our pipeline already spends quite some time producing pileups for VarScan and we also wanted to enable FREEC BAF. I decided to use the pre-existing pileups with inputFormat=pileup and SNPfile instead of re-producing pileups with makePileup. This has the nice side-effect of making FREEC substantially faster as well.

However, I notice quite a discrepancy in operation between the two methods. The main thing is that using SNPfile automatically switching to GC-content normalisation and degree 3/4 in WGS sample-control mode. A few questions:

• Is this intentional?
• Why do the two methods differ in their defaults?
• Am I correct in thinking that it's not possible to disable GC-content normalisation using pre-prepared pileups unless also using targets? (i.e. if using targets you can set degree=1 and forceGC=0 to get the normal sample-control behaviour but without targets you can only control degree).
• Did I miss some part of the documentation about these differences or does it need updating?

Also, #14 probably needs modification as the asymmetry wasn't clear to me at the time.

[valeu]

Is this intentional?

Yes. I personnaly think it is the best way to analyse WGS data: correct for GC-content bias and use the control only to annotate germline events.

Why do the two methods differ in their defaults?

They should not for WGS. However, for WES control data are indispensable to eliminate capture bias.
I will check again that the behavior of FREEC corresponds to what it should be in this case.

Am I correct in thinking that it's not possible to disable GC-content normalisation using pre-prepared pileups unless also using targets? (i.e. if using targets you can set degree=1 and forceGC=0 to get the normal sample-control behaviour but without targets you can only control degree).

It should be possible to do it exactly as you say: forceGC=0. I will check. It may be that it will not have the desired effect: indeed, in my hands, the GC-content normalization always provided better results that control-based normalization for WGS data.

Did I miss some part of the documentation about these differences or does it need updating?

You are right. All these (default) decisions are not documented. However, starting from v10.3 there is an _info.txt file in the output where it is stated whether the GC-content normalization was used or not.

[sambrightman]

Thanks. So the default for WGS with a control is expected to be GC-normalisation (with degree 3/4)? I was under the impression that in several cases both GC-normalisation and sample-control normalisation would be performed – is that correct?

You say "yes" – makePileup vs pileups as input are intended to be different. I'm not sure I understand you: whatever the intended default (let's say: WGS GC-normalisation, annotation of germline) shouldn't the two behave the same when everything else is the same?

[sambrightman]

BTW, I also noticed that it's hard to use the makePileup method if your BAMs use contig naming without "chr" prefix. This is a potential cause of empty pileups – I had to run a customised version which does not hard-code the prefix onto the chromosome lengths bed. Maybe should file this as a separate issue.

[valeu]

Thank you, Sam, for this feedback. Indeed, some users got empty pileups and I could not understand why.

Thanks. So the default for WGS with a control is expected to be GC-normalisation (with degree 3/4)? I was under the impression that in several cases both GC-normalisation and sample-control normalisation would be performed – is that correct?

It should not be so for WGS. Unless the user sets forceGCnormalization to 1 or 2.

You say "yes" – makePileup vs pileups as input are intended to be different. I'm not sure I understand you: whatever the intended default (let's say: WGS GC-normalisation, annotation of germline) shouldn't the two behave the same when everything else is the same?

No, I say that you have BAF information (you get a pileup or you create it) it is better to normalize with GC content. But you are right that it can be different in the code. It is possible that to use GC-content normalization with minipileup creation, the user should set forceGC to 1. I need to modify it.

[aligogon]

BTW, I also noticed that it's hard to use the makePileup method if your BAMs use contig naming without "chr" prefix. This is a potential cause of empty pileups – I had to run a customised version which does not hard-code the prefix onto the chromosome lengths bed. Maybe should file this as a separate issue.

Additionally, if anyone encounters the same problem with the "chr" prefix, you can change this behavior by setting the corresponding Boolean to False in the "BAFpileup.cpp" file:

createBedFileWithChromosomeLengths(bedFileWithRegionsOfInterest,chrLenFileName, false)