Rescaling during support mapping unclear

[bmichanderson]

Hi, I'm trying to map bootstrap support from an SVDquartets analysis. I have 100 bootstrap trees in a Nexus file (boots_sp.tre) and I want to use them to map support onto my inferred tree (qfm_92_sp.tre). Here's the command I am using with IQ-TREE v. 2.4.0 for Linux x86 64-bit:

iqtree -sup qfm_92_sp.tre -t boots_sp.tre

It runs fine, but shows this output:

Reading tree qfm_92_sp.tre ...
unrooted tree detected
Reading input file boots_sp.tre...
100 tree(s) loaded
0 split(s) discarded because frequency <= 0.000
9 taxa and 23 splits.
Rescaling split weights by -33.333
23 splits found
Creating bootstrap support values...
Tree with assigned support written to boots_sp.tre.suptree

In previous runs on larger datasets (more than the 9 taxa here), I had to add -scale 1 to switch to percentages (IQ-TREE default is 100* the value). But in this case, it is dividing all support values by 3 for some reason I can't understand. I can correct it by setting -scale 3, but I'm unclear why and how to predict that value beforehand.
Does anyone know what might be going on?
I'll attach the relevant files (renamed to *.txt for upload) for replication.
boots_sp.tre.suptree.txt
qfm_92_sp.tre.txt
boots_sp.tre.txt

[bmichanderson]

Note that the same behaviour persists in IQ-TREE version 3.0.1 for the above two files. However, running the same command on files from a different run of the same analysis (attached to this message) produces the expected behaviour of rescaling by 100. I cannot see what the difference is between the files.

boots_sp.tre.txt
qfm_92_sp.tre.txt

[roblanf]

Hey @bmichanderson,

I'm experimenting with Claude code, so I'm interested to see how useful it is...

Short answer seems to be that you might be able to convert to newick and it will work. Long answer (pure Claude code...) is below. It thinks there's a bug in how we handle nexus files...

Very intersted to know if this helps. Figuring out these issues has (perhaps until now?) been rather beyond me. But maybe now I can help get them fixed. Let's see...

Rob

P.S. @bqminh, what is your opinion of this brave new world - did Claude get the bug?

Claude said:

I traced through the iqtree3 source code and I believe this is a bug in how -sup handles NEXUS-format bootstrap tree files. (Disclosure: this analysis was done by Claude, an AI assistant.)

The bug: two interacting problems in the NEXUS code path

When -sup reads bootstrap trees, it checks the file format (phyloanalysis.cpp:5983). For Newick files, it correctly uses SW_COUNT to count how many trees contain each split, then divides by the total number of trees to get percentages. But for NEXUS files, it takes a different code path (sg.init(*params) → convertFromTreesBlock()) that has two problems:

1. Wrong weighting mode: The NEXUS path uses params.split_weight_summary, which defaults to SW_SUM (tools.cpp:1185), instead of SW_COUNT. With SW_SUM, split weights are accumulated using branch lengths rather than simple occurrence counts.

2. Missing branch lengths default to -1.0: Your trees are topology-only (no :length annotations). When the parser encounters a branch with no length, it defaults to -1.0 (node.cpp:206-207). Each split's weight is initialized from this branch length (mtree.cpp:1564).

How -33.333 arises

With SW_SUM and branch lengths of -1.0, each time a split appears in a tree it accumulates a weight of -1. A split in N trees gets total weight = -N. After processing your 100 bootstrap trees, the code divides 100.0 by sg.maxWeight() — the maximum (least negative) split weight. Your rarest split appears in exactly 3 trees, giving it weight -3:

scale = 100.0 / (-3) = -33.333

This also explains why -scale 3 appears to fix the output: 3.0 / (-3) = -1.0, which flips the negative weights to positive counts.

Why it works with other datasets

If the bootstrap tree file is in plain Newick format (starts with ( rather than #NEXUS), the code takes a different branch (phyloanalysis.cpp:5998) that correctly uses SW_COUNT and divides by sumTreeWeights(). The bug only manifests when bootstrap trees are in NEXUS format — which is what PAUP*/SVDQuartets outputs.

Where the fix should go

The NEXUS path in assignBootstrapSupport() should force SW_COUNT for split accumulation (matching the Newick path), and should normalize with sumTreeWeights() instead of maxWeight(). The simplest fix would be at splitgraph.cpp:294 in convertFromTreesBlock(), or by restructuring the NEXUS path to extract trees and process them through the same counting logic as the Newick path.

Workaround

Convert the NEXUS tree file to plain Newick format (one tree per line, just the tree strings ending with ;), and the default rescaling should work correctly.

[bmichanderson]

Thanks for that @roblanf!

Yes, I think Claude correctly identifies the problem, and it makes sense:

1. Running a second analysis in SVDquartets and using the resulting files gives a better output from IQ-TREE (using -scale 1), which makes sense if the second analysis didn't detect the rare split from the first that was only present in three trees
2. Converting the original file to Newick and running through IQ-TREE produces correct output (with no need to specify -scale).

I think the problem is as you say: IQ-TREE doesn't handle NEXUS tree files properly for interpreting support.

As an aside, I don't really use these newer language model tools, but that output is pretty impressive for detecting problems and explaining them. Maybe I will have to consider using them more in the future...

[roblanf]

Thanks so much for confirming @bmichanderson. We're just starting to get to grips with Claude code, and we're a bit shocked by how useful it is so far. I think for small bugs like this it's a complete game changer - it's able to quickly (and usually accurately) trace code paths, develop and run tests, understand bugs, and propose fixes. Once we get it properly hooked up and we get a bit better at using it, I think fixing a lot of small bugs like this will be the work of minutes, where often it would have been days before.