[Feature Req.] Move away from CosmoHammer

[steven-murray]

Is your feature request related to a problem? Please describe.

21CMMC currently uses CosmoHammer as its mcmc framework (which wraps emcee). However, CosmoHammer is no longer developed, and doesn't support emcee 3. We get around some of these issues by heavily subclassing/overwriting CosmoHammer, but this is a lot of hacking.

Describe the solution you'd like

A couple of things we could do:

1. Use a different framework that supports emcee 3 and is actively developed (and will be into the future). I have not researched which frameworks would do this, though I myself have created one (https://github.com/steven-murray/yabf) which may or may not fit the bill.
2. Not use a framework at all, and just support emcee 3 (which can be used through MPI now by using this replacement for the mpi Pool: https://github.com/sibirrer/lenstronomy/blob/master/lenstronomy/Sampling/Pool/multiprocessing.py)
3. Write our own mini framework within 21CMMC, replicating some of the interface of CosmoHammer.

I'm not sure which one would be best, but I'd like to move towards something that could support different samplers (which, to be fair, CosmoHammer does to some extent). The framework should ideally be easily extensible, and importantly, actively developed (either by ourselves or others), so that we can make/suggest changes.

[BradGreig]

Given that you want to move away from CosmoHammer and have it be easily extendable to other samplers, to me it makes the most sense to write your own. That way it can be easily controlled to behave as needed and should be the easiest to maintain and develop.

[andreimesinger]

I am not sure how this was handled with the new MultiNest sampler as well, but I agree it should be generic. Perhaps it will help to touch base first with Tom about how his PMC ABC sampler works, and see if there is an way to incorporate it all.