+FU (user-defined frequencies) silently ignored for codon (GY) models in 3.1.2, correct in 2.4.0
Versions
- Broken: IQ-TREE version 3.1.2 for Linux x86 64-bit (bioconda
iqtree=3.1.2)
- Correct: IQ-TREE multicore version 2.4.0 for Linux x86 64-bit (built from
v2.4.0-22-ga00094e0)
Summary
-m "GY{omega,kappa}+FU{f1,...,f61}" — pinning all 61 codon-state frequencies via +FU — gives a
log-likelihood that's off by ~52 nats in 3.1.2 compared to 2.4.0, on the same alignment/tree/model
parameters, with -blfix confirming 0 optimization iterations on both sides (so it's not a
re-optimization difference — the same fixed point is being mis-evaluated).
More specifically: two runs with different +FU frequency vectors (real F3X4-derived
frequencies vs. flat 1/61 uniform) give the exact same wrong log-likelihood (-950.5760) in 3.1.2,
while 2.4.0 correctly gives two different values for the two inputs. This suggests 3.1.2 isn't
actually reading the +FU values for a 61-state model — it silently falls back to some fixed
default with no warning.
The .iqtree report confirms this directly: for the same +FU-pinned command, 2.4.0 prints
Model of substitution: GY+FU, State frequencies: (user-defined), and Number of free parameters: 0 (frequencies correctly held fixed). 3.1.2 instead prints Model of substitution: GY+F — silently dropping the U — omits the State frequencies: line entirely, and reports
Number of free parameters: 60 (61 frequencies − 1 simplex constraint), i.e. it's treating the
pinned frequencies as free parameters rather than fixed values. This happens identically for both
the real and uniform frequency vectors, which is why both collapse to the same lnL. So the bug
isn't just "the values aren't read" — 3.1.2 appears to misparse/mishandle the +FU token itself
for codon (K=61) models and silently fall back to estimating frequencies instead of fixing them.
Nucleotide (K=4) +FU/+F{...} pinning is unaffected in 3.1.2, as is unpinned +F3X4 (IQ-TREE
deriving its own codon frequencies) — both agree between 2.4.0 and 3.1.2. The discordance is
specific to user-supplied (+FU) frequencies at K=61.
Reproduction
Alignment (aln.fasta), tree (tree.nwk), and exact model strings attached. Command:
iqtree -s aln.fasta -st CODON -te tree.nwk -blfix -m "GY{0.804368,1.075225}+FU{f1,...,f61}" --prefix out -T 1
| Run |
Model string |
2.4.0 lnL |
3.1.2 lnL |
| A |
GY{0.804368,1.075225}+FU{<real F3X4-derived freqs>} |
-1002.3436 |
-950.5760 |
| B |
GY{0.804368,1.075225}+F3X4 (not pinned) |
-1002.3436 |
-1002.3436 |
| C |
GY{0.804368,1.075225}+FU{<uniform 1/61 freqs>} |
-1016.8162 |
-950.5760 (same as A) |
Total number of iterations: 0 in every run — -blfix held throughout.
| Run |
Model of substitution: (2.4.0 / 3.1.2) |
Number of free parameters (2.4.0 / 3.1.2) |
| A |
GY+FU / GY+F |
0 / 60 |
| C |
GY+FU / GY+F |
0 / 60 |
Expected
+FU-pinned codon-model likelihood should match between versions (as it does for nucleotide
models and for the unpinned +F3X4 case), and should change when the supplied frequency values
change (as it does in 2.4.0).
Actual
3.1.2 disagrees with 2.4.0 by ~52 nats when frequencies are pinned via +FU at K=61, and returns
an identical result regardless of what those 61 frequencies actually are.
Full repro package (inputs + raw IQ-TREE logs from both versions, plus a from-scratch reproduction
script) attached here.
+FU(user-defined frequencies) silently ignored for codon (GY) models in 3.1.2, correct in 2.4.0Versions
iqtree=3.1.2)v2.4.0-22-ga00094e0)Summary
-m "GY{omega,kappa}+FU{f1,...,f61}"— pinning all 61 codon-state frequencies via+FU— gives alog-likelihood that's off by ~52 nats in 3.1.2 compared to 2.4.0, on the same alignment/tree/model
parameters, with
-blfixconfirming 0 optimization iterations on both sides (so it's not are-optimization difference — the same fixed point is being mis-evaluated).
More specifically: two runs with different
+FUfrequency vectors (real F3X4-derivedfrequencies vs. flat 1/61 uniform) give the exact same wrong log-likelihood (-950.5760) in 3.1.2,
while 2.4.0 correctly gives two different values for the two inputs. This suggests 3.1.2 isn't
actually reading the
+FUvalues for a 61-state model — it silently falls back to some fixeddefault with no warning.
The
.iqtreereport confirms this directly: for the same+FU-pinned command, 2.4.0 printsModel of substitution: GY+FU,State frequencies: (user-defined), andNumber of free parameters: 0(frequencies correctly held fixed). 3.1.2 instead printsModel of substitution: GY+F— silently dropping theU— omits theState frequencies:line entirely, and reportsNumber of free parameters: 60(61 frequencies − 1 simplex constraint), i.e. it's treating thepinned frequencies as free parameters rather than fixed values. This happens identically for both
the real and uniform frequency vectors, which is why both collapse to the same lnL. So the bug
isn't just "the values aren't read" — 3.1.2 appears to misparse/mishandle the
+FUtoken itselffor codon (K=61) models and silently fall back to estimating frequencies instead of fixing them.
Nucleotide (K=4)
+FU/+F{...}pinning is unaffected in 3.1.2, as is unpinned+F3X4(IQ-TREEderiving its own codon frequencies) — both agree between 2.4.0 and 3.1.2. The discordance is
specific to user-supplied (
+FU) frequencies at K=61.Reproduction
Alignment (
aln.fasta), tree (tree.nwk), and exact model strings attached. Command:GY{0.804368,1.075225}+FU{<real F3X4-derived freqs>}GY{0.804368,1.075225}+F3X4(not pinned)GY{0.804368,1.075225}+FU{<uniform 1/61 freqs>}Total number of iterations: 0in every run —-blfixheld throughout.Model of substitution:(2.4.0 / 3.1.2)Number of free parameters(2.4.0 / 3.1.2)GY+FU/GY+FGY+FU/GY+FExpected
+FU-pinned codon-model likelihood should match between versions (as it does for nucleotidemodels and for the unpinned
+F3X4case), and should change when the supplied frequency valueschange (as it does in 2.4.0).
Actual
3.1.2 disagrees with 2.4.0 by ~52 nats when frequencies are pinned via
+FUat K=61, and returnsan identical result regardless of what those 61 frequencies actually are.
Full repro package (inputs + raw IQ-TREE logs from both versions, plus a from-scratch reproduction
script) attached here.