Dear Volker,
Not to worry about the delay. Many thanks for answering my question — this is now very clear!
All the best,
Andrew
> On 19 Jul 2022, at 16:22, Volker Springel <vspringel_at_mpa-garching.mpg.de> wrote:
>
> ⚠ Caution: External sender
>
>
> Hi Andrew,
>
> Really sorry for the much belated response. Too much travel lately.
>
> The naming of these fields understandably is quite confusing. Let me try to explain.
>
> To determine the field DescSubhaloNr, the code finds for every subhalo (at most) one subhalo in the next snapshot that is judged to be the most likely subhalo. The match is established by tracking the most bound particles of the subhalo and see where these particles end up. If the particles are not ending up all in the same subhalo, a score is used to single out the one subhalo which contains "the most" of the most-bound particles.
>
> Similarly, the code does the reverse in the opposite direction and determines a primary progenitor subhalo, stored in the field ProgSubhaloNr, by looking at where the most bound particles came from.
>
> It can happen that several subhalos point towards the same DescSubhaloNr. This group of subhalos is accessible by the link-list structure described by FirstProhSubhaloNr and NextProgSubhaloNr.
>
> Likewise, it can happen that several different subhalos point towards the same progenitor ProgSubhaloNr. In this case, the corresponding group of subhalos can be identified via the link-list structure FirstDescSubhaloNr and NextDescSubhalo, exactly in the way you described.
>
> Basically, the field ProgSubhaloNr induces the fields FirstDescSubhaloNr/NextDescSubhalo, and DescSubhaloNr induces the fields FirstProgSubhaloNr/NextProgSubhaloNr. The two pairs of link-lists, FirstDescSubhaloNr/NextDescSubhalo and FirstProhSubhaloNr/NextProgSubhaloNr, are thus strictly speaking adding no extra new information, but they can still be very useful if one wants to navigate in the trees.
>
> A further consequence of this is that the best descendent will usually be given by DescSubhaloNr, but if this fails or gives a questionable link, one can take a look at the set given by FirstDescSubhaloNr/NextDescSubhalo to see whether this contains a better alternative (these subhalos are ultimately based on the ProgSubhaloNr links).
>
> Likewise for ProgSubhaloNr - this is in principle the most natural progenitor, but FirstProgSubhaloNr/NextProgSubhaloNr provide alternatives that are exactly those subhalos which have the current subhalo listed as their DescSubhaloNr.
>
> This makes it also possible that you have, for example, no FirstDescSubhaloNr = -1, but DescSubhaloNr exists and is fine. The opposite is also possible in principle.
>
> I hope this helps a bit to clarify this issue.
>
> Best,
> Volker
>
>
>
>
>> On 3. Jul 2022, at 22:55, Pontzen, Andrew <a.pontzen_at_ucl.ac.uk> wrote:
>>
>> Hi Gadget users,
>>
>> I am currently updating the pynbody toolset (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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwwwmpa.mpa-garching.mpg.de%2Fgadget4%2F09_special_modules%2F&data=05%7C01%7Ca.pontzen%40ucl.ac.uk%7C0029b324045d45f8450008da699a7c76%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637938409476968892%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yJN946lh9sHZZrW83BKSPtLae9LU6cEbqxjr1jSUlE0%3D&reserved=0 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
>>
>>
>> -----------------------------------------------------------
>>
>> If you wish to unsubscribe from this mailing, send mail to
>> minimalist_at_MPA-Garching.MPG.de with a subject of: unsubscribe gadget-list
>> A web-archive of this mailing list is available here:
>> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mpa-garching.mpg.de%2Fgadget%2Fgadget-list&data=05%7C01%7Ca.pontzen%40ucl.ac.uk%7C0029b324045d45f8450008da699a7c76%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637938409476968892%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MpZZhoGCxcV6MwAlx3%2BEJ2liatIVZvdalllUoTWtXzw%3D&reserved=0
>
>
>
>
> -----------------------------------------------------------
>
> If you wish to unsubscribe from this mailing, send mail to
> minimalist_at_MPA-Garching.MPG.de with a subject of: unsubscribe gadget-list
> A web-archive of this mailing list is available here:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mpa-garching.mpg.de%2Fgadget%2Fgadget-list&data=05%7C01%7Ca.pontzen%40ucl.ac.uk%7C0029b324045d45f8450008da699a7c76%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637938409476968892%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MpZZhoGCxcV6MwAlx3%2BEJ2liatIVZvdalllUoTWtXzw%3D&reserved=0
Received on 2022-07-19 20:38:45