Copy ratio close to but not exactly 1
1
0
Entering edit mode
twtoal ▴ 10
@twtoal-15473
Last seen 5 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 • 1.0k views
ADD COMMENT
0
Entering edit mode
@markusriester-9875
Last seen 2.5 years 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.

 

ADD COMMENT

Login before adding your answer.

Traffic: 1028 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

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

Powered by the version 2.3.6