pycbc
pycbc copied to clipboard
gwastro
Disentangle 'core' inference functionalities (distributions, samplers, ...) from lal/cbc context?
I was wondering: would it be possible to disentangle some pycbc-inference 'core' functionalities such as probability distribution/prior handling and MCMC samplers from the more specific CBC application context, and from lalsuite/lalsimulation in particular, similar to bilby's 'core' sub-package: https://lscsoft.docs.ligo.org/bilby/code-overview.html
To illustrate the current problem I see when trying to use the distributions subpackage:
> import pycbc.distributions
ModuleNotFoundError: No module named 'lalsimulation'
From looking at the code, this is not going to be totally trivial to separate out, even for just the 'distributions' subpackage, as there seem to be various entanglings with lalsimulation and CBC-context specific parts on various levels. Certainly not something I could just provide a simple patch for.
I think providing a context-agnostic 'core' package for pycbc-inference could increase its wider appeal and usability beyond the CBC context, but I don't know if this is something the core developers are interested in. So putting this here as a suggestion / discussion-point.
@ahnitz @cdcapano
FWIW, this is a quick hack that allows me to import pycbc.distributions without lalsimulation, without any concern for breaking other stuff (might be helpful to see already where the deps get pulled in):
https://gist.github.com/ReinhardPrix/f4ef021f433b1716629239e9482e4ab9
Ok, so here a small ping to try and revive this idea: what I would be interested in using is probability distributions/priors and the wrapper to samplers, but I do not want to pull in lalsuite or lalsimulation, and otherwise would prefer to be able to import pycbc with as few dependencies as possible, ie basically only what's required to get distributions and sampling-wrapper.
Following the bilby model, which has worked very successfully for me, it would be nice to isolate such core functionalities into a 'core' sub-package, ideally one might even be able to install this separately? [just an idea]
The main deal-breaker for me is pulling in lalsuite/lalsimulation, which breaks my installation, and the relevant pycbc code would also have to be disentangled from this dependency so it works without lalsimulation.
/cc @ahnitz
@ReinhardPrix Thanks for bringing this back to the foreground. I'll take a look at this this week and see what best path forward is on this.
@ReinhardPrix Just for order of operations, if we can more quickly remove the dependency on lalsimulation, but temporarily may need lal itself, does this work for you? Presumably you bring in your own version of lal, but beyond not pre-empting that, is this OK?
@ahnitz thanks for looking into this!
Yes, importing lal is perfectly fine, as that is available in my environment as well.
@ReinhardPrix Ok, thanks, I should be able to do that more readily. I'll try to get you something to test with before I go on vacation next week.