Call with --filter ci question

[Poly44]

Hi, I am trying to understand how the --filter ci parameter works.

From what I could gather, it should fuse and discard segments with ci incuding zero, while keeping every other segment as it is (that is, not fusing them).

I am worinkg on germline exome sequencing, I have a sample with a known small deletion (2 contiguos exons, about 500 bases total).

I've produced segmetrics and call files for this single sample with slightly different pooled references, and got to fairly similar segmetrics files but the output for the call --filter ci seems to work differently and I can't understand why.

Segmetrics 1

Segmetrics 2

Call with --filter ci 1

Call with --filter ci 2

In case 2, my segment of interest is, for some reason, being fused with the previous segment, though log2 values are clearly different. I was wondering if there's anything extra that the command call --filter ci takes into account to produce the final calling. The only difference I can see is that in case 1 my segment of interest is surrounded by segments whose ci includes zero, while in the second case this is not the case for one of the surrounding segments. Maybe this is an expected behavior?

Hope you can help figure this out, I am prone to remove the --filter ci from my scripts at the expense of some false positives.

Thanks!

[etal]

Let me investigate a little more. The CI calculation repeatedly resamples the bin log2 values in a given segment and the statistics can get dicey with small numbers. The biggest difference I see between cases 1 and 2 is the "weight" column; case 2 essentially has a lot more weight on those 3 bins, implying the pooled reference had less variance in coverage at each of those 3 bins among the control samples. That still doesn't explain why non-overlapping CIs of adjacent segments would get merged, but it's notable, so... let me keep looking.

Could you tell me if there are any other nonstandard parameters you use in your pipeline? And, what are the log2 values and weights for those 3 hemizygous bins in this test sample?

[Poly44]

Hi etal, thank you very much for your help. I've noticed that the values in the tables I uploaded before were a bit off (some of them had misplaced decimal points, something to do with importing in excel, so sorry). I've uploaded the correct images now. There is actually no difference in weight between case 1 and 2, though the weight is low. Still doesn't explain the difference in behaviour in the call --filter ci, or does it?

I think the only non-standard parameter I've used is --smooth-cbs when segmenting (without this parameter, my segment of interest is not even visible after segmenting).

cnvkit.py coverage sample.bam target.bed -o sample.targetcoverage.cnn
cnvkit.py coverage sample.bam antitarget.bed -o sample.antitargetcoverage.cnn
cnvkit.py fix sample.targetcoverage.cnn sample.antitargetcoverage.cnn mypon.cnn -o sample.cnr
cnvkit.py segment --smooth-cbs sample.cnr -o sample.cns
cnvkit.py segmetrics sample.cnr -s sample.cns --ci -o sample.segmetrics.cns
cnvkit.py call sample.segmetrics.cns --filter ci -o sample.segmetrics.call.cns

log2 values and weights (for the 3 hemizygous bins)

Look forward to your insights, many many thanks!

[barkoneus]

Caveat: version 0.9.10, but the code is current from github.

What seems to be happening is that the --filter ci option is simply merging adjacent segments by the sign of the ci (eg less than 0 or greater than 0).

In the segfilters.py code:

levels[segarr["ci_lo"].to_numpy() > 0] = 1
levels[segarr["ci_hi"].to_numpy() < 0] = -1

So ci_lo and ci_hi are both just converted to values of -1, 0 or 1. And then adjacent segments are merged on these transformed ci values.

So in your second case ci_lo and ci_hi are both negative for your variant of interest, as well as for the segment immediately prior. This is why they are merged together. You can see this a few segments later where the two segments with 9 probes each and also negative ci_lo and ci_hi are merged into a single segment with 18 probes.

I'm seeing this in my own data where I have a very clear deletion (-1.06973 -> -1.02102) get merged with an adjacent segment (-0.0298796 -> -0.021028).