Inconsistent polygon behaviour when including CP column

[whelena]

I'm plotting single-sample SRC results using the fish-plot + tree feature. The data frame input looks like:

parent	label	length.1	CP
5	1	8	0.865
4	14	37	0.560
5	4	11	0.990
1	7	48	0.860
NA	MRCA	122	0.930

Output plot :

I think this output is because CP of node 4 is greater than MRCA. But, this is also inconsistent with different CPs

CP 4 = 0.93 ($CP_4 = CP_{MRCA}$)

CP 4 = 0.8

CP 4 = 0.3 ($CP_4 < CP_14$)

Here the colour ordering is changed too

[whelena]

Fixed on hwinata-issue-sweep (ee96daa).

Your diagnosis was right: the malformed polygon is caused by node 4's CP exceeding the MRCA's. Measured on your exact table, node 4's polygon spans x = [-50.95, 57.53] while the MRCA trunk spans [-54.24, 54.24] — the child overshoots its own ancestor by 3.29 native units, with no warning.

The chain: make.clone.tree.grobs.R:65 normalises v$vaf <- v$ccf / max(v$ccf) against the global max CP, so when a descendant carries the highest CP that descendant gets vaf = 1 and the root gets less. Then in position.clones.R:58-75 a sibling group is laid out inside parent$vaf * wid, but per.gap is applied only from the second child onward, so the first child's right edge lands at -0.5 * parent.vaf * wid + child.vaf * wid. The arithmetic makes the last child always land exactly on the parent bound, so only the first child can spill — and only when its CP exceeds its parent's. That is exactly the inconsistency you saw across CP values.

Fix: clamp.CP.to.parent() in R/prep.tree.R walks breadth-first from the root and reduces any node whose CP exceeds its parent's, warning once and naming every offending node with its parent. Clamping rather than erroring, because CP estimates routinely breach the constraint by measurement noise (0.99 vs 0.93 here) and refusing to plot over a 0.06 discrepancy is worse than drawing the biologically meaningful limit case. CP_4 = 0.990 now renders identically to CP_4 = 0.930, and node-4 widths are monotone in CP: 108.48 / 108.48 / 93.32 / 39.70.

On the colour ordering — that one is not a colour bug. The fill assigned to each node is identical across all four CP values (MRCA #3F3F3F, 4 #BEBEBE, 1 #E9E9E9, 7 #7E7E7E, 14 #D3D3D3); colours are bound to the input row in prep.tree before reorder.nodes() runs. What changes is that reorder.nodes.by.CP re-ranks by descending CP, which drives both left-to-right sibling placement and polygon draw order — and since the polygons are 50% alpha and overlapping, swapping which sibling sits underneath changes the composited shading. The flip actually happens when CP_4 crosses CP_1 = 0.865, so already at 0.8 rather than at 0.3. The rule (larger clone leftmost and underneath) is deterministic and sensible, so it is now pinned by tests rather than changed.

tests/testthat/test-issue-138.R adds 82 assertions — the first direct coverage for get.CP.polygons.R / position.clones.R / calculate.clone.polygons.R.

One thing this surfaced that is not fixed: sibling CP sums are never validated. The user guide states "the sum of all child nodes must not be larger than their parent node's value", but nothing enforces it — in your tree siblings 1 (0.865) and 4 (0.8) sum to 1.665 against a parent of 0.93, which drives total.space negative and overlaps the siblings. They stay inside the parent so it is not malformed, but it is a separate unpoliced constraint worth its own issue.