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