Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ancestral nodes inferred in unexistent regions. #5

Open
iago-lito opened this issue Jan 17, 2023 · 0 comments
Open

Ancestral nodes inferred in unexistent regions. #5

iago-lito opened this issue Jan 17, 2023 · 0 comments

Comments

@iago-lito
Copy link
Collaborator

Hi @champost. Nathan has just been running into a strong inconsistency within DECX output, currently flawing his PhD manuscript. He has been able to reproduce with the following reduced analysis: Pipridae.zip [Harvey 2020]

The problem in this example is that some ancestral nodes are being inferred to range in regions that were not supposed to exist at all at the time. Here for instance, the region labeled DC is supposed not to exist prior to 11Ma according to the adjacency matrices, but the model finds it likely that ancestral node number 98 (age 11.6406Ma) was ranging over AM_AF_DC.

I have reverted the project to commit 68a5a1b to assert that this behaviour was already present then. Today in d8b390a, I have featured a special --check-considered-ranges-detail argument to display the detail of RateModel::incldists_per_period. ASAIU, the faulty region does not appear within these "considered ranges", which makes it very surprising that it eventually ends up ranked as one of the most likely guesses from DECX.

Are the model constraints specified with the adjacency matrices supposed to be absolutely respected? Or are they just smooth indications given to the optimizer? If they are supposed to be hard constraints, then I believe the above behaviour is a bug.

I have worked so far on improving the program interface and portability, and never actually had to open up the underlying DEC implementation which we've been just trusting. Now that we are finding a suspicious behaviour within it, I have no code documentation or rigourous tests suite to rely on and to help me track this down. Maybe your input would be helpful here because you authored it? Otherwise, I would have to read through the old codebase, and through Ree 2005, Ree 2008 and your preprint to get a sense of the problem and I unfortunately don't have the bandwidth to get this deep into it :\

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant