standalone empress tree-plot generates html that get stuck in loading screen

[YasinEl]

Hello,

I have installed the standalone empress distribution. After running

empress tree-plot --tree nf_output/treeGraph_6356_53477895.nw -fm nf_output/treeAnnotation_6356_53477895.tsv -o LacCer_34_1_O2

I get:

LacCer_34_1_O2.zip

However, when opening the html it never stops loading.

I am on Ubuntu 20.04.6 LTS

[fedarko]

Thanks for reporting this. I did some digging, and was not able to reproduce the problem. Would you mind sharing the following?

• Your original tree and feature metadata files
• The output of running pip list (you can run pip list > piplist.txt and upload that, if that's easier)
• The output of running conda list, if you are using conda

Tentatively, I suspect that something is going wrong with your installations of numpy and/or iow. I wonder if you have numpy 2 installed -- if so, maybe try downgrading (using e.g. pip install "numpy<2"), then recreating the visualization; this might fix the problem?

Details on what's going wrong

From looking at the visualization ZIP file you shared (thank you!), it looks like the balanced parentheses representation of your tree is malformed. (This is the cause for the visualization remaining stuck at the loading screen: Empress' javascript code hits an error when reading this information during loading.)

The specific error occurs on line 723 in the empress.html file. This line should contain a balanced parentheses representation of your tree (in the form of a list of 51-bit integers); however, in your HTML file, the numbers are:

1. Wrapped by the term np.uint8(), for some reason

2. Very tiny (these numbers should be on the order of 2**51, but they're all less than 1,000 -- suspiciously, the biggest of them is exactly 255).

Tentative guess of the cause of the problem

It looks like what's happening is:

1. iow loads the tree using parse_newick(), and treats each of the bits (0s and 1s) as np.uint8 objects.
2. Empress converts the iow tree to a list of 51-bit integers using its shifting() function.
3. The elements in the output list retain the np.uint8 type. Since they retain this type, they are all constrained to being ≤ 255, which results in this function outputting a malformed representation of the tree's structure.

Assuming that this is the cause of the problem, I think the problem should be fixed by modifying Empress' shifting() function to cast all bits to ints. A workaround would be capping numpy's version to < 2, if that is what's causing the bits to be np.uint8s and not just ints.

Copying @kwcantrell and @wasade.

[YasinEl]

Thank you for the fast response and explanations! installing a "numpy<2" indeed solved the problem.

Anyway here are the requested files in case it helps to fix something:

treeFiles_and_condaList.zip

[fedarko]

Perfect, glad that fixed things!