Question about tree linking

From: Pontzen, Andrew <a.pontzen_at_ucl.ac.uk>
Date: Sun, 3 Jul 2022 20:55:10 +0000

Hi Gadget users,

I am currently updating the pynbody toolset (pynbody.github.io<http://pynbody.github.io>) to work smoothly with Gadget-4’s subfind implementation. Mostly everything now works well on the latest version of pynbody but I’ve come a bit unstuck when trying to import merger trees from a gadget 4 simulation into tangos (our database system for storing halos and trees). I am wondering if anybody can shed some light on the following.

I understand from https://wwwmpa.mpa-garching.mpg.de/gadget4/09_special_modules/ that progenitors and descendants of a halo are both stored by gadget 4 following a linked list schema.

Based on reading this I have assumed that to enumerate all descendants (or progenitors, with some small changes of details), I would:

1) look at FirstDescSubhaloNr (stored in subhalo_desc_nnn.hdf5) for the sub halo I am interested in.
2) look in the subhalo_prog_mmm.hdf5 for the next snap (m=n+1) and follow NextDescSubhaloNr to find the next descendant, if any
3) keep following the chain of NextDescSubhaloNr, until I hit a -1.

This works some of the time, but I am very confused about the role of the plain “DescSubhaloNr” (not prefixed by ‘First’ or ’Next’). In my first attempt at decoding trees, I ignored “DescSubhaloNr". However I have hit a case where “DescSubhaloNr” points to a sensible descendant for a halo, while “FirstDescSubhaloNr” is -1 seemingly indicating no descendant. (Equally there are cases where “FirstDescSubhaloNr” seems sensible but “DescSubhaloNr” points somewhere else entirely. ) Is anybody able to shed light on what the role of DescSubhaloNr is?

Thanks very much if anybody can provide hints or point me in the right direction; I’m afraid I didn’t get very far from reading the code as yet.

All the best,

Andrew Pontzen

Received on 2022-07-03 22:55:23

This archive was generated by hypermail 2.3.0 : 2023-01-10 10:01:33 CET