Negative Copy Numbers and double internal node names

[huy29433]

Hi, I am a colleague of @anlo328 and was using lazac, where I encountered two issues that I explain below.

Background

I was using lazac to retrieve ancestral profiles for 16 cells. The output contains the original profiles and additional profiles root, internal_0, ..., internal_11.

The Issue

In the outputfile ..._cn_profile.csv

1. there were negative copy numbers in the internal nodes and the root
2. the names internal_3 and internal_4 appeared twice each (with different profiles). Also they appeared twice each in the newick tree at different positions.

To my limited understanding,1. is not necessarily a problem of the implementation but it could just be that a negative-CN internal node produces the optimal solution for the ZCNT problem. As a (uninformed) suggestion, maybe it could be possible to introduce a "reality condition" to the candidate trees, so that trees with negative copy numbers are not even proposed?

The 2nd problem seems to simply be a mislabeling in the production of the profiles.

Reproducing this Issue

Because I'm using unpublished data from collaborators, I unfortunately cannot post them here. Maybe my explanations above are already enough to understand the issues, if not, I will try to get permission to post only one chromosome or something like that.

---

Thanks a lot in advance!

[schmidt73]

Yes, negative copy number states are valid under the ZCNT model. This is necessary for quickly filtering through candidate trees purposes, but is perhaps undesirable for the output labeling. A fix would be to solve the CNT small parsimony problem (which does not allow negative copy number states) for the final tree output by Lazac. I think this is relatively straightforward to do, but will need some testing.

To the second issue is simply a bug which will be promptly fixed. I will leave this open until both issues are resolved.

For my curiosity, are there any other issues with the trees output by Lazac? That is, do the topologies look consistent with what you expect (modulo the internal labeling issues)?

[huy29433]

Once again thank you so much for your prompt reply! :)

Regarding your suggestion for a fix: There is no reason to assume that the ZCNT-optimal topology also is the CNT-optimal one, right?
Also, how do you propose to solve the CNT small parsimony problem? I'm by no means an expert in the field, but from your paper I take that there is no solution for that one, correct?

Thank you for taking the time to answer my questions, I understand that this is beyond the intended application of lazac.

---

Regarding your questions about the output tree: The tree so far makes sense to us and is more or less what one would expect when looking at the distance matrix or more primitive approaches like neighbour joining. We're happy to update you as soon as we have more remarks!

[schmidt73]

No, there is no reason to assume that ZCNT optimal is CNT optimal, though ZCNT does appear to be a relatively good approximation to CNT (as shown in our paper). The main reason for using ZCNT is that, while it is not great for ancestral labeling, it provides a good score that is efficiently computable for the purposes of ranking candidate trees.

However, if we only have to solve the CNT small parsimony problem once (on the output tree) to obtain an ancestral labeling, this may be tractable using a MILP. If not, other fixes are possible.

[huy29433]

I see thank you very much. Then we will use the output tree for now and look into solving the CNT small parsimony problem for that one. If you have any leads on this, we'd be happy if you let us know.

[schmidt73]

I can work on code to better infer ancestral labelings this week, along with other bug fixes.

A simple idea is to solve ZCNT small parsimony with the added constraint that the inferred copy number profiles are non-negative. That is, infer ancestral labelings to minimize total ZCNT distance, but disallow negative copy number profiles at internal nodes. This should be relatively easy to solve with an ILP, but it may be trickier to merge into the C++ code.

Please reach out over email (henri.schmidt@princeton.edu) for further discussion.

[schmidt73]

Also, the bug regarding multiple internal labels has been fixed.

[schmidt73]

As an update, sorry for the delay on the ancestral labeling code. I have been swamped with preparing conference submissions, but will hopefully have time in the coming weeks. Just wanted to add that I had not forgotten about this!