Since Illustris is, in many aspects, a descendant of the Millenium simulations, much of that excellent documentation may be useful, particularly with respect to the merger tree structure. Since the Arepo owes much of its heritage to Gadget-2, there are many similarities at the particle level.
There are currently two distinct types of objects, for which group catalogs exist (once the Rockstar groups are released, there will be three). We presented the following naming definitions in the data release paper:
For a given subhalo, the catalog field SubhaloGrNr gives its "group number",
i.e. the index (or ID) of its parent halo (or "group").
Note that this index (or ID) refers to the Group* datasets in the catalog, not the Subhalo*
datasets. For example, to obtain the halo mass of subhalo i, you could access
Group_M_Crit200[SubhaloGrNr[i]].
For a given halo, the catalog field GroupFirstSub gives the index (or ID)
of its "first" (i.e. primary, or "central") subhalo. This value is invalid (equal to -1)
unless GroupNsubs >= 1. As above, this index (or ID) refers to the Subhalo*
datasets in the catalog. To access the stellar mass of the central subhalo of group j,
you could take SubhaloMassInRadType[GroupFirstSub[j],4].
If a halo has more than one subhalo (GroupNsubs > 1), then all subhalos after
the first are satellites. The indices (or IDs) of these satellite subhalos are given by
{GroupFirstSub+1, GroupFirstSub+2, ..., GroupFirstSub+GroupNsubs-1},
or in python, range(GroupFirstSub+1, GroupFirstSub+GroupNsubs).
These are all different names for the same value, and are used interchangeably in this documentation and most papers. They all refer to the "ID" (or "index") of a subhalo in the group catalogs, as determined by the Subfind substructure algorithm, i.e. the index of any dataset within the Subhalo group of the HDF5 file.
For instance, when loading a single object from the catalog with the
groupcat.loadSingle() function, or when loading particles belonging to a given
object from the snapshot with the snapshot.loadSubhalo() function, or when using
the SubLink merger trees to find the SubfindID of a progenitor or descendant subhalo at
different snapshots.
Small, low-mass halos near the minimum particle count threshold of 32 may not contain any bound
subhalo. In particular, the central subhalo may fall below the required 20 particle minimum for a
Subfind object during the iterative unbinding procedure. In this case, GroupFirstSub == -1
and spherical overdensity (SO) quantities such as the virial radius (Group_R_Crit200)
are not calculated and may appear as zero.
The gas temperature must be derived from the internal energy $u$ and the electron abundance $x_e$ ($=n_e/n_H$)
which are PartType0 snapshot fields InternalEnergy
and ElectronAbundance, respectively. First, the mean molecular weight can be calculated as
$$\mu = \frac{4}{ 1 + 3 X_H + 4 X_H x_e } * m_p.$$
Then, the temperature in Kelvin is given by
$$T = (\gamma - 1) * u / k_B * \frac{\rm{UnitEnergy}}{\rm{UnitMass}} * \mu.$$
Here, $\gamma = 5/3$ is the adiabatic index,
$k_B$ is the Boltzmann constant in CGS units, and
$X_H = 0.76$ is the hydrogen mass fraction.
Finally, UnitMass and UnitEnergy are those code units in CGS units.
Specifically, UnitEnergy = UnitMass * UnitLength^2 / UnitTime^2 (UnitLength is
1 kpc, UnitTime is 1 Gyr), so their ratio is $10^{10}$.
They are same, meaning that they started in the same locations in the initial conditions.
Not necessarily. In particular, at z=0 in Illustris-1 there are a handful of black hole
particles which are outside of all FoF halos. This number is very small, and may occur if e.g. a BH
is seeded in a low mass halo which is then stripped or disrupted, falling below the minimum mass
threshold for subhalos. In this case, a BH may reside outside of a group until it falls into the
potential center of a new halo.
No. While the final, z=0 snapshot of Illustris is number 135, the z=0 snapshot of TNG is number 99. All higher redshifts will also be saved at different snapshot numbers, and there may not be an exact correspondence between a snapshot of Illustris and of TNG. This will also be true for other simulations. In general, to make a comparison between any two simulations, the closest snapshots to a given redshift should be found in each.
Keep in mind the 'mini' snapshots! You may be trying to load e.g. NeutralHydrogenAbundance
or MagneticField for one of the 80 mini snapshots, while this field is only available in the
20 full snapshots.
This can occur for PartType4 (stars) in some, extremely rare cases. For example, ID 116384809780 in TNG100-1 snapshot 14. This may only affect TNG100-1. Typically zero or at most a few such duplicates exist, and are only an issue for algorithms sensitive to perfect ID uniqueness.
For Illustris-1, snapshots 53 and 55 were corrupted and cannot be used.
Although the group catalogs exist, the merger trees skip over these snapshots, as if they are not present.
In general, for most analysis tasks, the best approach is to simply pretend that these two snapshots
do not exist.
Prior to snapshot 72, the Coordinates field of all particle types was written in single
precision floating point (32-bits). This was changed to double (64-bit) precision at snapshots 72
through 135.
The dark matter particle IDs encode their starting positions in the initial conditions, using a Peano-Hilbert key with 21 bits per dimension (in order to fit into a 64-bit ID). If you would like to make use of this information, get in touch for more details. (Note: DM IDs are sequential, and small, in TNG).
In original Illustris, this field is present for stars and gas in the original snapshot files, but should not be used. In particular, the values are incorrect, and do not contain valid information. (These are available and valid in TNG).
The vast majority of subhalos (at every snapshot) are in both the SubLink and LHaloTree merger trees, but not all. If a subhalo does not have an established progenitor/descendant history, then it will not be included, and this will be most common for the smallest subhalos, near the resolution limit of 20 particles, and at high redshift.
FoF halos are not tracked in the merger trees, which are based solely on subhalos.
The 'next progenitor' for a subhalo ID N points to: the "next subhalo" which shares the same descendant as
subhalo N. Therefore be careful: it is not a pointer from a given subhalo to a progenitor of that
subhalo. By "next subhalo" we mean the next most massive (for LHaloTree), or the one with the next most massive
history (for SubLink).
Sometimes a subhalo briefly changes its central/satellite status according to SUBFIND. Since centrals are generally more massive than satellites in SUBFIND, the change results in a visible spike in the MAH of the subhalo.
Yes. But, this feature is relatively immature in most languages and HDF5 wrappers. For doing this in Python, see h5py issue #552 or the PyTables 'in-memory' page. With the HDF5 library (in C), this requires HDF5 v1.8.9+, and you should look at HDF5 File Image Operations [PDF].
The --content-disposition option is how wget knows what filename to save the download as.
This was added to wget v1.11 in Jan 2008, if you're using any software this old you are going to have
many problems! Please upgrade.
In order to use wget to download data files, including snapshots, catalogs, supplementary
catalogs, and so on, you need to pass your API key with the request, by adding it to the commandline.
You can find your API key at the top of the Data Access page.
It can be included with the following syntax:
wget --header="API-Key: KEY_HERE" "https://www.tng-project.org/api/path/to/file.hdf5".