Template does not work with exampe file

[rbouckaert]

The BEAUti template fails when trying to import the example file minimal.nex. Is there an example file that succeeds with the template?

[Anaphory]

I gave up writing the template pretty early and thus doubt that I can provide you with a combination of beast xml file and template that will work together. Apologies for leaving the misleading stub around, which makes it look like it should work.

[rbouckaert]

Would it be possible to provide a few more examples -- the single example is a bit hard to generalise and looks quite different from the template. If you have an example with say one n>=2 and one m>=3 valued attributes, or three binary attributes that would be helpful.

[Anaphory]

That I will do, but I'm currently trying to wrangle too many other things in parallel, so I may need a reminder if it slips my mind.

[rbouckaert]

How frequently do you want to be reminded?

[rbouckaert]

Once every 4 weeks?

[rbouckaert]

Once every 8 weeks?

[Anaphory]

I actually wanted to work on it last week, but then I fell ill.

[Anaphory]

There is now a 2×3×4 example for the evolution along cardinal axes part of the problem in the repository.

I indend to expand it soon to also show the merge and join parameter values reversible jumps part, the components for which have now been merged into this repository.

[rbouckaert]

Great -- looking forward to more examples!

[Anaphory]

There is now a better-commented example containing both bits. Currently, its data set is still very very small and not generated by such a process.

However.

There is a big conceptual problem with using data that is of shape more than 2×2: This model is very difficult to resolve due to the “unbiased partitions” approach of the reference. Independent evolution is becomes more and more unlikely under the all-partitions-are-equally-likely prior that we currently assume. In particular, adding an independent character to an existing compound decreases the chance to infer the other characters as independent. It is possible that an explicit, different prior on the partitions may alleviate this low chance, but no such prior exists yet, and the Merge and Split operators make some assumptions about the priors in their hastings ratios, which would need to be considered.

In numbers,

8 possible rates (2×2) have 22 partitions. An independency means that two pairs of rates are clamped together (eg. r(0→1|T)=r(0→1|F) and r(1→0|T)=r(1→0|F) would mean that the evolution in the 0/1 component is independent of the T/F state), which means that there are p[8-2]=11 partitions each where evolution is independent of the other, and p[8-2-2]=5 for complete independence, leaving a total of 5 partitions for complete co-dependency of the two evolutionary processes.

144 possible rates (2×3×4) have 22 540 654 445 different partitions. The weakest independence assumption is that evolution of the binary trait does not depend on the ternary trait. This gives 16 equality relations between the states – namely r(T→F|A,0)=r(T→F|B,0)=r(T→F|C,0), …, r(F→T|A,3)=r(F→T|B,3)=r(F→T|C,3); (3-1) × (2×[2-1]) × 4, that is –, and the remaining possible partitions are p[144-16]= 4 351 078 600 – or less than a fifth.

[rbouckaert]

Thanks for the update! Running the independent vs dependent model using path sampling/stepping stone analysis is one way to test which model fits best. A 50/50 independent/dependent prior would be nice.

[Anaphory]

There is dormant support for putting a prior on the dependency structure, I'm currently working on tests to expose that feature properly.

[Anaphory]

Hm, it does not look very promising. I have generated data through completely independent evolution according to the underlying model (in fact all individual rates are 1), for 2400 tip taxa, with a tree with branch lengths in the order of magnitude of 1/rates, but the MCMC has serious difficulties and tends to highly overfit the rate estimates.

I think this model might not be very useful for inferring the dependency of something more general than two binary traits. A model that explicitly accounts for dependency may be both more efficient (in the independent case, it would have to exponentiate smaller matrices) and more helpful, I guess.

[rbouckaert]

You mentioned operators being dependent on priors. Is this because they are sharing code, or the Hastings ratio taking the prior in account. If the latter, that may be of concern since proposals should not rely on the prior. Perhaps this is a source of the lack of model identifiability?

[Anaphory]

Currently, the whole setup assumes that partitions are uniformly distributed and that rates are distributed according to a flat rescaled (by #{rates}, so the average rate is 1) Dirichlet prior. I believe¹ I played around with the setup last time I looked at it in detail – I believe I found changing the prior on the rates wreaks havoc on the uniform distribution of partitions, because the Hastings ratios of the operators make assumptions about the prior in ways I then didn't properly understand.

I have learned more about Hastings ratios and reversible jumps in the meantime, but unfortunately I have also gained an entirely different focus of research topics, which has so far disincentivized me from looking at this particular model in enough detail to properly fix the issue.

¹) I wanted to turn this into a Beast test – the file generating the run is there, but I haven't yet managed to dig into the logger or modify some other class, in order to give me some data structure for which I could calculate how close it is to a uniform distribution of partitions.