modelfinder 2 documentation

[roblanf]

We need a new modelfinder2 page:

New setup is:

• merge-rate (E, I, G, R and combinations)
• merge-exchange (see substiuttion models page)
• merge-frequency (see substitution models page)

no -mset
but yes to -madd (see below)

This page can reference the substitution models page to get the available options for each of these categories.

Also edit the subsitutiton models page

Make sure that for DNA, Protein, Binary, and Codon we have each section split into exchangeability models and frequency models.

The idea is to make a table with:

• Data type: (AA, DNA, Binary, Codon)
• Model: name of a model if and only if it comprises one or more exchangeability matrices, and one or more frequency vectors; anything in this column can be legitimately used with -m and -madd and -mexchange and --merge-exchange; e.g. LG, WAG, LG4X
• Exchangeabilties: same entries as Model plus things like EAL (which is just a rate matrix), the point is that this is everything that can work with -mexchange and --merge-exchange
• Frequencies: anything that has one or more frequency vectors. Everything in the Model column is also in this, but starts with an F, e.g. F.LG is the LG frequencies. But this column also has mixtures of frequencies like C10, UDM8, and F.LG4X; also has F, FU (get freqs only from models), FQ, FO.

[roblanf]

NQ models are stored as Q matrices and Frequencies, so they go in the model column, and the frequency column, but you can't separate out the exchangeabilities because we don't have them.

[thomaskf]

A suggestion from Joanna,

For the modelFinder,

The cleaned substitution matrices should be used: Q.Pfam clean, Q.BACT clean, etc.
And the +G rate model should be avoided.

[roblanf]

Definitely things we should discuss at our meeting tomorrow. Can you find the preprint that she was presenting at the conference - that's the one with her alignment cleaning results, right?

[thomaskf]

I think the preprint is: https://www.biorxiv.org/content/10.64898/2025.12.01.691663v1

[roblanf]

That's it. Annoyingly, it doesn't actually specify how they used QMaker. I have a hunch that there may be a disconnect between the method of inferring Q and the way they used it, perhaps to do with the rate distributions used in both. To me, that could potentially explain the confusing results w.r.t. tree inference.

[roblanf]

I emailed joanna to ask if they could update the CLOAK github with the details.