Estimated mtDNA copy number incorrect in raredisease pipeline

[NicoleCMMS]

Just found another problem with the raredisease pipeline with regard to mtDNA. We have run three samples through the pipeline now and all three have got a mean MT coverage of just 127 in the mtDNA report. MtDNA coverage in the Chanjo report appears to be correct so it seems to be a problem only for the mtDNA report. Since all three cases got a mean MT coverage of 127 it looks very suspicious. The cases are:

25290-RD
25293-RD
25261-RD

[northwestwitch]

Hi @NicoleCMMS, I'll take a look!

[dnil]

Downsample file used for coverage calculation maybe @ramprasadn and @jemten?

[northwestwitch]

Ok, the thing is that since yesterday we have chanjo2 in production and the MT report is now using chanjo2 instead of chanjo to compute the stats.

And the number comes actually from chanjo2:

Chanjo2 is using different intervals than chanjo for calculating the stats - if it's a WGS sample then it computes on the whole chromsome instead on transcripts only - but it's still weird that it's only 127. And 127 for all 3? 🤔

[northwestwitch]

AH wait. That 127 is the mean coverage in chanjo2, not the copy number! whoops. I'll fix!

[northwestwitch]

To recap, the bug is in scout, specifically in the code used to create the MT report from values collected from chanjo2. It's reporting the mean coverage instead of the estimated copy number

[dnil]

Huh?

[northwestwitch]

Huh?

No, right, I got confused. And if it was a bug like that that it would be systematic, but other cases look fine..

[jemten]

Looks like it could be a bug in the pipeline (mosdepth). Generating d4 files with mostdepth and then checking the mean coverage of the mt gives 127x, while generating the d4 file with d4tools on the bam file (subsetted to mt only) and then checking the stats gives a coverage of 4013x. Will continue to investigate

[jemten]

Issue posted on mosdepth, brentp/mosdepth#254. Thanks @peterpru
We are also looking into incorporating d4tools directly in the pipeline