It is too easy to forget what parameters were used in creating mpiMcmc runs. Because these runs can take a substantial amount of computer time, it would be inconvenient to rerun just because the parameters were uncertain.
I suggest that mpiMcmc write headers into the user-specified output file as follows:
% mpiMcmc and its version number
% start data and time
% user and machine name (if known)
% full pathname and file name for datafile
% parameters mpiMcmc was run with in the same order as the YAML file
logAge FeH modulus absorption logPost
9.843688 -0.287278 3.529341 0.000000 0.514280
9.701107 -0.346934 4.696330 0.000000 2.732268
etc.
The "%" sign could instead be a "#" or whatever is easiest in delineating a header.
sampleWDMass would have to know how to read past this header and would generate
a similar header of its own. (sampleWDMass is quicker to rerun, but for consistency
it would be nice for it to generate a header.)
It is too easy to forget what parameters were used in creating mpiMcmc runs. Because these runs can take a substantial amount of computer time, it would be inconvenient to rerun just because the parameters were uncertain.
I suggest that mpiMcmc write headers into the user-specified output file as follows: % mpiMcmc and its version number % start data and time % user and machine name (if known) % full pathname and file name for datafile % parameters mpiMcmc was run with in the same order as the YAML file logAge FeH modulus absorption logPost 9.843688 -0.287278 3.529341 0.000000 0.514280 9.701107 -0.346934 4.696330 0.000000 2.732268 etc.
The "%" sign could instead be a "#" or whatever is easiest in delineating a header.
sampleWDMass would have to know how to read past this header and would generate a similar header of its own. (sampleWDMass is quicker to rerun, but for consistency it would be nice for it to generate a header.)