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:

- w_vela_out: with Vela, full output
- w_vela_out_nofail: with Vela, full output without points which failed
- w_vela_emu: with vela, emulator output
- wo_vela_out: without Vela, full output
- wo_vela_out_nofail: without Vela, full output without points which failed
- wo_vela_emu: without Vela, emulator output

Back to Andrew W. Steiner at the University of Tennessee.