Hello, I would like to build a galaxy catalogue at different redshifts in order to reproduce ground base observations. I was thinking of selecting all the subhaloes restricted with a mass threshold at each snapshot and then saving the merger trees of each galaxy.
I was thinking of using the "sublink_simple" tree of a subhalo. Could you confirm that it is a reliable reference to set if 2 galaxies are considered merged at a specific snapshot if at some point they get the same ID?
For the galaxy mass, is it 'massinrad_stars' the one that I should use as a reference?
Thank you in advance.
In general, a "galaxy catalog" would be derived from the subhalo catalog, where you impose some threshold on stellar mass (or luminosity).
I would do this for each redshift you are interested in, separately.
I would avoid using the merger tree for any reason to create a "observable galaxy catalog", unless there is some motivation you can explain further.
You are free to take any stellar mass definition (i.e. aperture) that makes the most sense. As you say, I would suggest the default to start, e.g. the stellar mass within twice the stellar half mass radius.
Thank you Dylan for your answer, I am just interested in making a catalogue of galaxy mergers based on their position.
For example, knowing that A and B are at a specific redshift and distance, are they going to merge? So I need the position, the masses and redshift, then to know if they merge, that explains the merger tree.
What would be the best command to get a subhaloes population and limit their minimum masses while knowing their IDs to find them in the halotree? I didn't find a way except to use the API link which could get some connexion issues.
Just to be clear, if you make a catalog of true galaxy mergers, it cannot be "in order to reproduce ground base observations", as true merger times are not observable, only proxies for mergers, e.g. pair separation or morphological parameters.
One idea to make a galaxy merger catalog based on their positions at a given redshift would be:
(1) load the subhalo catalog at the redshift of interest, select all subhalos with stellar mass above your threshold of interest, for each search for any nearby companions within some threshold distance (e.g. 100 kpc, 1 Mpc).
(2) this will produce a catalog of pairs, and for each pair, you should save the subhalo IDs
(3) load the merger trees of each subhalo of the pair, looking at their Descendant's. when the two subhalos have the same Descendant (at the same snapshot), then they have merged. You can record this as the (future) merger time. Some pairs may never merge.
Practically, I would suggest to download the subhalo catalog at the redshift of interest, and do steps (1)+(2) on your local computer (or use the Lab service). Depending on how many pairs you end up with, you may want to get the tree of each (with the API, i.e. sublink.hdf5), or again, just use the Lab service (if you would be downloading more than say 10k trees).
That is what I was planning to do indeed. I am quite well aware of the order of magnitude for the time delay for galaxy mergers.
My problem is just technical. I am planning to reproduce hundreds of thousands of samples for machine learning. I do need a lot of samples to train on galaxy merger.
In fact, I have used the function il.groupcat.loadSubhalos() but I cannot find the ID label to call for the subhalo to relate them to the merger tree. I was hoping to find it in the specification but I didn't. I'm pretty sure it might be obvious but I can't find it.
The Subhalo ID is just the index, e.g. you can make it as np.arange(Nsubhalos).
Perfect, thank you for your time
Hello Dylan, I need your wisdom once again.
I would like to identify if one sub halo is going to merge at the next snapshot. I tried to load the DescendantID list of this subhalo but I get more than one tree while I just need the ID of the next one to see if the galaxies are merging.
I use this line to obtain my merger tree:
I get something like:
array([ -1, 40000000600000000, 40000000600000001, ...,
I would like to know which one I should rely on in order to check any other subhaloes that have the same ID on the next snap.
This is because (from the documentation):
"If onlyMDB, then only the 'main descendant branch' is loaded, which is a single
tree branch if and only if this subhalo lies on the MPB of its z=0 descendant, while if not,
then the return is the full descendant merger tree which contains as its first entry the z=0
descendant of this subhalo."
Looking at the picture:
Perhaps you can think of a condition, using the various links, to identify the case you are interested in.