Question: Copy ratio close to but not exactly 1
0
11 months ago by
twtoal0
twtoal0 wrote:

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 • 166 views
modified 11 months ago by markus.riester110 • written 11 months ago by twtoal0
Answer: Copy ratio close to but not exactly 1
0
11 months ago by
markus.riester110 wrote:

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.