Is your feature request related to a problem? Please describe.
If we are to implement other samplers (for example the multinest sampler) then the output of derived data is not possible under the current framework, because the call to get the extra data is done within emcee, and not by cosmoHammer itself. Other samplers that don't have that call and don't provide a hook to do so are not able to save the data.
Describe the solution you'd like
The solution that would be best long-term would be able to be agnostic to the sampler code itself, be saved into an intuitive backend, and be able to store relatively arbitrary data. It would be best if the format is already recognized by some popular MCMC analysis package(s) like getdist or arviz.
Probably the only way to really achieve these ends would be to move the call to get the derived quantities into the cosmoHammer framework or directly into the likelihood call (and then ignore emcee's call to save the derived parameters). The potential pitfall with the first is that we may someday want to move away from cosmoHammer. The latter sounds a bit kludgy to me.
Describe alternatives you've considered
I can't think of any viable alternatives right now -- other than perhaps researching other MCMC frameworks that already do this for us. Many exist, eg. cobaya, yabf, pymc3, edward...
Is your feature request related to a problem? Please describe.
If we are to implement other samplers (for example the multinest sampler) then the output of derived data is not possible under the current framework, because the call to get the extra data is done within
emcee, and not bycosmoHammeritself. Other samplers that don't have that call and don't provide a hook to do so are not able to save the data.Describe the solution you'd like
The solution that would be best long-term would be able to be agnostic to the sampler code itself, be saved into an intuitive backend, and be able to store relatively arbitrary data. It would be best if the format is already recognized by some popular MCMC analysis package(s) like
getdistorarviz.Probably the only way to really achieve these ends would be to move the call to get the derived quantities into the
cosmoHammerframework or directly into the likelihood call (and then ignoreemcee's call to save the derived parameters). The potential pitfall with the first is that we may someday want to move away fromcosmoHammer. The latter sounds a bit kludgy to me.Describe alternatives you've considered
I can't think of any viable alternatives right now -- other than perhaps researching other MCMC frameworks that already do this for us. Many exist, eg.
cobaya,yabf,pymc3,edward...