TreePlot does not account for skipped snapshots

[Morkney]

I have been looking at merger trees produced for the TNG and Auriga simulations (the LHaloTree format), and occasionally the progenitor of a halo will skip one snapshot. From the IllustrisTNG website:

To allow for the possibility that halos may temporarily disappear for one snapshot, the process is repeated for Snapshot n to Snapshot n+2. If either there is a descendant found in Snapshot n+2 but none found in Snapshot n+1, or, if the descendant in Snapshot n+1 has several direct progenitors and the descendant in Snapshot n+2 has only one, then a link is made that skips the intervening snapshot.

Skipped snapshots are not considered when assigning pydot nodes in the TreePlot command (I think this would be possible to do, if a little fiddly). This means two mergers may appear to be concurrent when they are not, and all progenitor nodes will be displaced from that node onwards. Since there is no explicit time axis anyway, perhaps this is not really a problem at all?

[brittonsmith]

Hi, thanks for creating this issue! Does the LHaloTree format for TNG contain information that can be used to identify halos that fall into this category? Is it necessary to check that all ancestors have the same redshift or come ancestor/descendent redshifts with a list of snapshot redshifts? If there is a simple way to identify these, this is probably doable.

[Morkney]

Hello!

There is no specific identifier that I am aware of. The simplest test, as you suggest, would be to check whether the descendant of a halo is on the next snapshot or on the next snapshot +1 (TNG includes a 'SnapNum' property). I found that performing such a test took quite a long time in practise, but I am probably not using ytree to its fullest potential.

[brittonsmith]

One way forward could be to implement a function to insert virtual TreeNodes representing the lost halo from the intermediate snapshot. It could be inserted in between TreeNodes whose snapshot numbers differ by more than 1. It's field values could be linearly interpolated from its progenitor and descendent. This could be something that a user optionally runs on a tree if they need it.

This isn't something I have time to work on in the near future, but I would be happy to work with you if you're interested in taking a shot at it.

[manodeep]

Chipping in - in the off-chance this helps. In the past, when I created mergertree plots with dot, I would use the snapshot to set the depth where the node should be placed. Basically, once you have the ancestors, you also read the ancestors' snapshot number (which is available per the format specification) and (somehow) pass that information through to pydot and let pydot decide how to setup the layout.

[manodeep]

Looking through old dot files, I can see that I used rank and a combined snapshot+ID mechanism to get this feature. Here's what an example *.dot files contained:

First, sets up the redshifts:

graph merger{
{
node [shape=plaintext,fontsize=100,rankdir=BL]
"0.57" -- "0.61"[penwidth=30.0];
"0.61" -- "0.66"[penwidth=30.0];
"0.66" -- "0.71"[penwidth=30.0];
"0.71" -- "0.77"[penwidth=30.0];
"0.77" -- "0.82"[penwidth=30.0];
"0.82" -- "0.88"[penwidth=30.0];
"0.88" -- "0.93"[penwidth=30.0];
"0.93" -- "0.99"[penwidth=30.0];
"0.99" -- "1.05"[penwidth=30.0];
"1.05" -- "1.11"[penwidth=30.0];
"1.11" -- "1.18"[penwidth=30.0];
"1.18" -- "1.25"[penwidth=30.0];
"1.25" -- "1.31"[penwidth=30.0];
"1.31" -- "1.38"[penwidth=30.0];
"1.38" -- "1.46"[penwidth=30.0];
"1.46" -- "1.53"[penwidth=30.0];
"1.53" -- "1.61"[penwidth=30.0];
"1.61" -- "1.69"[penwidth=30.0];
"1.69" -- "1.77"[penwidth=30.0];
"1.77" -- "1.85"[penwidth=30.0];
"1.85" -- "1.94"[penwidth=30.0];
"1.94" -- "2.03"[penwidth=30.0];
"2.03" -- "2.12"[penwidth=30.0];
"2.12" -- "2.22"[penwidth=30.0];
"2.22" -- "2.31"[penwidth=30.0];
"2.31" -- "2.42"[penwidth=30.0];
"2.42" -- "2.52"[penwidth=30.0];
"2.52" -- "2.63"[penwidth=30.0];
"2.63" -- "2.74"[penwidth=30.0];
"2.74" -- "2.85"[penwidth=30.0];
"2.85" -- "2.97"[penwidth=30.0];
"2.97" -- "3.09"[penwidth=30.0];
"3.09" -- "3.21"[penwidth=30.0];
"3.21" -- "3.34"[penwidth=30.0];
"3.34" -- "3.47"[penwidth=30.0];
"3.47" -- "3.61"[penwidth=30.0];
"3.61" -- "3.75"[penwidth=30.0];
"3.75" -- "3.89"[penwidth=30.0];
"3.89" -- "4.04"[penwidth=30.0];
"4.04" -- "4.19"[penwidth=30.0];
"4.19" -- "4.35"[penwidth=30.0];
"4.35" -- "4.52"[penwidth=30.0];
"4.52" -- "4.68"[penwidth=30.0];
"4.68" -- "4.86"[penwidth=30.0];
"4.86" -- "5.03"[penwidth=30.0];
"5.03" -- "5.22"[penwidth=30.0];
}

This redshift line is followed by a chunk of text like the following:

{
node [shape=circle,style=filled,fillcolor="black",nodesep=0.1,ranksep="0.2 equally",fontcolor="white",fontsize=100];
"85A68848"[width=6.00000,style=filled,fillcolor="red",label="85A68848 M 7.1"];
{rank=same;"0.57";"85A68848" };
"84A68848"[penwidth=20.0,width=29.105299,label="84A68848 M 9.2 F 48"];
{rank=same;"0.61";"84A68848" };
"84A68848"[style=filled,fillcolor="yellow",fontcolor="black"];
"85A68848" -- "84A68848"[penwidth=30.0] ;
"83A68848"[penwidth=20.0,width=25.771323,label="83A68848 M 9.0 F 48"];
{rank=same;"0.66";"83A68848" };
"83A68848"[style=filled,fillcolor="yellow",fontcolor="black"];
"84A68848" -- "83A68848"[penwidth=30.0] ;
"82A68848"[penwidth=20.0,width=31.812367,label="82A68848 M 9.3 F 0"];
...

}
}

Here, each node is assigned a unique ID by = <snapshot>A<unique_haloID> (where unique_haloID itself stays the same along a halo's main progenitor branch) to generate a new dot ID that is unique per snapshot. Then the line {rank=same;"0.57";"85A68848" }; sets the depth at which each node should be placed; in this case node with ID 85A68848 should be set to the depth for z=0.57. I am also setting the width and label based on some physical halo properties - which I think TreePlot already can do.

Connecting the nodes should remain unchanged.