Copy ratio close to but not exactly 1
Entering edit mode
twtoal ▴ 10
Last seen 12 months ago
United States

In my PureCN results I see with most samples that there will be long stretches of the genome, e.g. many separate chromosomes, where the copy ratio (2 ^ log ratio) is approximately but not exactly 1, such as for example 1.02, 1.03, 0.98.  Typically the number is consistent in any given sample, perhaps differing by no more than 0.01.  When I try to get a p-value for whether or not such a long segment has a copy ratio significantly different than 1, I apply a Wilcoxon test to the copy ratios of the markers within the segment, comparing them to the value 1 (not to 1.03 or whatever).  And often, the result of the test is that the copy ratio IS significantly different than 1.  This is surprising to me, it implies that the copy ratios of the markers in that region must exhibit almost no variance.  This suggests that PureCN could do a slightly better job normalizing the data.  I'm not sure what method would work best, but it ought to be able to identify that such long segments with copy ratio almost exactly 1 should normalize to exactly 1.  Is there room for improvement to PureCN here?  For now, I need to modify my Wilcoxon test so that I locate these approximately-1 regions myself, and test for marker copy ratio significantly different from THAT number rather than from 1.  In a separate question you suggested using a better approach to calculating p-values, that took into account the changing variance of marker copy ratios, especially with regard to small segments.  Since these are large segments, I presume that does not apply here.

PureCN CopyRatio • 830 views
Entering edit mode
Last seen 20 months ago
United States

There is a log-ratio calibration step that shifts the log-ratios slightly up or down in the likelihood model. This happens when the measured log-ratios do not properly align to integer copy numbers. There can be various reasons for this, but it most often happens in small panels when major copy number alterations are not captured (i.e. when measured ploidy does not perfectly match the true ploidy). There is a log.ratio.offset IIRC somewhere stored. Not sure that fixes your observed offsets, but might partly explain it.



Login before adding your answer.

Traffic: 607 users visited in the last hour
Help About
Access RSS

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6