where should taxa contributed by a lower ranked tree go when there is conflict?

[mtholder]

I put this new example on: https://github.com/OpenTreeOfLife/treemachine/tree/use-edges-of-lower-tree-when-compat Just copying the README here in case we delete that branch:

This is designed as an extension of nontrivialaugmenting. Here tree2 has some agreement with tree1, but also conflict with it

Tree1 is once again much less complete:

(((A,B),C),D)

tree2 is:

(((((A,E),C),B),F),D)

The taxonomy is a polytomy of the groups.

I would expect synthesis to get:

(((((A,E),B),C),F),D)

because:

• tree2 says A+E as a group (and no tree contradicts that)
• tree1 says A and B are sister relative to C and D. tree2 disagrees, but it is weak and ranked second.
• tree2 says A+E+B+C vs F or D, and that is compatible with tree1
• tree2 says A+E+B+C+F vsD, and that is compatible with tree1

Currently (on the branch indicated which is a child of the avoid-trivial-conf branch), the tree returned is:

(((A,B),C),D,E,F)

which seems to ignore all of tree2 because of one disagreement about (A,B,C)

But perhaps others disagree with that. Anyone want to speak up for the current behavior?

[mtholder]

Well, this one appears to be a bit of a blocker. It looks like either:

1. the TAG alignment needs to be tweaked so that n10 and n14 align, OR
2. the synthesis steps need to perform sophisticated traversals and application of phylogenetic logic to realize that you can do things like n3 → n12 → n9 to satisfy both relationship r33 and r20. Another example would be n10 → n15 → n1 to satisfy both r30 and r53

I'm not optimistic about those avenues, but that maybe just because I don't understand the code base very well.

[blackrim]

I am teaching for a good chunk of the day but joseph and cody should be on this soon (if not already). we can see what we can come up with.

when joseph and I had spoken before, I was thinking we would have to do #2 before this example came up. Basically just walk the source tree, generating the phylo statements and then see if the alternative relationships satisfy that. Anyway, perhaps another solution will present itself

On Wed, Feb 4, 2015 at 9:10 AM, Mark T. Holder notifications@github.com wrote:

Well, this one appears to be a bit of a blocker. It looks like either:

1. the TAG alignment needs to be tweaked so that n10 and n14 align, OR
2. the synthesis steps need to perform sophisticated traversals and application of phylogenetic logic to realize that you can do things like n3 → n12 → n9 to satisfy both relationship r33 and r20. Another example would be n10 → n15 → n1 to satisfy both r30 and r53

I'm not optimistic about those avenues, but that maybe just because I don't understand the code base very well.

[image: graph] https://cloud.githubusercontent.com/assets/136067/6041701/2a9c28ea-ac7f-11e4-90d5-9be94a47ad22.png

— Reply to this email directly or view it on GitHub https://github.com/OpenTreeOfLife/treemachine/issues/160#issuecomment-72859739 .

[chinchliff]

Well, we have been making some progress on synth, so I am going to reply to some issues. The major outstanding issue is arbitrary ranking of input trees. How to properly perform ranked synthesis is still not entirely clear. But ranking seems to be a separate item from this particular issue, and I think the new synthesis method solves this problem if we ignore the need for ranks (which we can do here). Running synth using descendant node count as the relationship selection criterion produces this tag, which I think is what we want... Please confirm.

[mtholder]

the TAG certainly looks better - though don't n10 and n11 have the same set of descendants (A, B, C, and E)? That seems undesirable.