The files are stored in HDF5 format. The main table is stored in a group named "markov_chain0" or "mcmc". The table contains a group "col_names" which gives all the column names stored as two arrays. An integer array contains the number of characters in each column, and a character array contains the characters in the column names with no space between them. If you use "h5dump -r" to look at the column names you will be able to see them.
Each MCMC iteration occupies a different row of the table. The MCMC output rejects some (or sometimes many) steps, and the proper way to construct the chain is to repeat the previous entry for a failed step. In lieu of repeating rows, the data files use the mult as the row "multiplicity" (the number of rejected steps plus one) and then the next acceptance is stored as a new row. Rows with 0 multiplicity are to be ignored.
The "_out" and "_out_nofail" files contain Markov chains that have not yet equilibrated and thus do not reflect the correct probability distribution. In addition, they have strong autocorrelations which have not been removed. The emulator was created to simulate the correct probability distribution much faster, and the output of the emulator is stored in files with a "_emu" suffix. The emulator output should be fully equilibrated and thus there should be no need to remove any iterations for "burn in". However, the emulator output does not fully remove the autocorrelations, thus the user must account for these, either by thinning or block averaging.
The column log_wgt contains the natural log of the "weight", i.e. the likelihood function. The "*_log_eta" colums refer to the log (base 10) of the amount light elements in the envelope. The "eta_*" columns refer to the atmosphere (H or He) for the QLMXBs.
The columns which have a numerical suffix, i.e. R_55, refer to vector quantities. An entire vector is created for each point in the Markov chain and thus the entire vector is stored in one row of the table. The numerical suffix ("55" in the example) refers to a fixed grid. In the case of the radii, they are stored on a fixed gravitational mass grid (the mass-radius curve). The gravitational mass grid begins at \( 0.08~\mathrm{M}_{\odot} \), has 100 entries, and ends at \( 2.456~\mathrm{M}_{\odot} \). (Thus R_55 stores the radius of a 1.4 solar mass neutron star.) Some neutron stars have maximum masses smaller than \( 2.456~\mathrm{M}_{\odot} \), thus radii for masses above the maximum mass are just given as zero. For example, the column R_90 (the radius of a 2.24 solar mass neutron star) in the "_out" and "_out_nofail" files is mostly filled with zeros. The emulator, however, does not understand the limitation of the maximum mass, and naively interpolates radii beyond the maximum mass, thus the user must examine the "M_max" column to see which radii are physical and which are unphysical.
The cooling curves (both temperature and luminosity) are stored for three different values of eta (1.0e-17, 1.0e-12, and 1.0e-7), for 6 different values of the gravitational mass (1.0, 1.2, 1.4, 1.6, 1.8, and 2.0), and over a logarithmic time grid of 100 points from 1.0e2 years to 1.0e7 years. They are thus rank 3 tensor quantities and that tensor is stored in every row of the output table.
Files:
Back to Andrew W. Steiner at the University of Tennessee.