would it be possible to get the redshift/snap number at which two (or more) subhalos (galaxies) have been merged?
If you are using the example scripts, then you should look at sublink.numMergers() as a starting point. It should be not too hard to modify this function to return, in addition to the number of mergers, the redshift of each merger. Let me know if you need some more suggestions here.
Thank you very much! I would like to ask you a further question: Is it possible to get any information about the x-ray luminosity for a subhalo in order to select for example fossil groups?
There are no saved x-ray calculations, so you would have to compute this yourself.
You can made very simple calculations of free-free emission only, e.g. following Navarro+ (1995) (Eqn 6). If you needed this to be more sophisticated, you would probably want to use a code like APEC or maybe a wrapper to this like pyXSIM.
Ok, thank you! Just one last question: Is there a simple way to get all the subhalo IDs which are in a given halo?
In the API, a halo has links to all its child subhalos (with IDs), e.g.
Alternatively, the list of child subhalo IDs is simply range(GroupFirstSub, GroupFirstSub+GroupNsubs) where these two values are accessible in the halo catalogs or e.g. at info.json.
I am coming back to my question about the merger of subhalos. I have identified groups of galaxies at different redshifts.
Now, I would like to check if and when these systems will merge (merger time). Therefore, I have identified such galaxy
groups for example at redshift 2 and followed them to redshift 0. I followed the merger tree (descendant) of each member of the galaxy group by using the
Task 8. If the descendant IDs are the same at the same snap number, I call this situation a merger. The time range between
the identification of a galaxy group and their merger gives me the merger time.
For example, snap nr. 100 (5.581 Gyrs) - snap nr 130 (0.780 Gyrs) = 4.801 Gyrs.
Do you think this method is ok?
However, I think the situation becomes more complicated, by following the merger tree from higher snap number to
smaller snap numbers. I think this way would not work for my scientific question, because the progenitor only finds the
most massive subhalo in the previous step.
The procedure you described makes sense to me.
Then, you're asking about going the other direction (i.e. backwards in time), as a possible alternative? You can do this, and indeed this is the way we typically do count mergers or measure merger rates. You're right that the "main progenitor branch" isn't enough information, instead you need the full tree (i.e. multiple branches). An example of finding mergers can be found in the illustris_python.sublink.numMergers() function of the example scripts, which walks from higher snap numbers to lower snap numbers.
Do not mind for my message, I solve it. thanks