Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

interoperability with PyCBC #22

Closed
ahnitz opened this issue Jun 30, 2021 · 3 comments
Closed

interoperability with PyCBC #22

ahnitz opened this issue Jun 30, 2021 · 3 comments
Labels
enhancement New feature or request

Comments

@ahnitz
Copy link
Contributor

ahnitz commented Jun 30, 2021

I'm interested in adding support so that gwsurrogate has better interoperability with the PyCBC gw data analysis package. The primary case here would be that gwsurrogate is able to act as a source of waveform models for our generic python GW waveform interface, and by doing so, be available for use as templates or injections for both parameter estimation and searches (or just make use in notebooks easier with a common interface).

A while back we added a plugin interface which should allow gwsurrogate to advertise what waveforms it can provide and harmonize the interface. For an example of what interface code is needed, see the reference example plugin.
https://github.com/gwastro/example-waveform-plugin

To be clear, this requires no explicit dependency on PyCBC, but would mean that if you have both packages installed ala

pip install gwsurrogate pycbc

that PyCBC programs and functions would immediately be aware of the waveforms from gwsurrogate and be able to use them.

I am willing to put together a PR. The changes would be limited a new module that contains the interface functions and small additions to setup.py so that gwsurrogate advertises globally its capabilities.

What do gwsurrogate developers think?

@duetosymmetry
Copy link
Member

duetosymmetry commented Jul 1, 2021

The main question I think of here is: Should gwsurrogate advertise only one entry_point, with a parameter that specifies which surrogate model is used; or if there should be one entry_point for each model? Does this depend on the API that pycbc expects of a plugin?

@ahnitz
Copy link
Contributor Author

ahnitz commented Jul 1, 2021

@duetosymmetry In principle it can be done either way with no loss in functionality. My preference would have been however to advertise each model separately as that is more similar to how it is done for other waveform sources. (each entry point corresponds to the 'approximant' keyword for our waveform generation).

@duetosymmetry
Copy link
Member

Closed by #29

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants