Add reduced order quadrature likelihoods

If someone wants to take this on (I'm guessing it's ~ one day's worth of work), I can run through the math and some standalone scripts with a simple implementation.

assigned to @nikhil.sarin

I am starting to implement this now, and just want to start the discussion on how it needs to be bilbified. @colm.talbot @moritz.huebner @gregory.ashton @paul-lasky @rory-smith

Should the ROQ waveform be its own source model, As in, should there be a frequency_domain_source_model thats the ROQ waveform which then has its own likelihood etc. Or does it need to be implemented in a different way?

Yeah; the way you call the wave form with ROQ is slightly different to how you would normally: with roq you only need to evaluate it at a small subset of frequencies.

I don't understand the ROQ things very well. But, I think a way to frame this is, "when there is an ROQ=True flag, at what level will it be implemented?"

It sounds like you are going to need to define a new likelihood (say GravitationalWaveTransientROQ, a child of GravitationalWaveTransient). Which takes in the usual interferometers, but then defines a new frequency_array (a subset of the full array) at which to evaluate the likelihood.

How does the ROQ interact with the time, distance, and phase marginalization?

Short answer is that ROQ isn't compatible with the marginalizations.

added 1 deleted label

Slight modification to @rory-smith's answer: The ROQ isn't compatible with the marginalisations as they are implemented for the "normal" likelihood function. There are however ways of modifying the ROQ likelihood function to include phase&time marginalisation (and I'd assume distance marginalisation as well, but I haven't actually coded that up anywhere yet). I would be happy to add in those marginalizations, so feel free to ping me when you've finished with the "raw" ROQ likelihood @nikhil.sarin.

Hi @cjhaster. The raw ROQ likelihood is implemented (implementing_ROQ branch) along with a script showing it working but has not been merged in as we need to clean it up a little.

@cjhaster, distance marginalisation should work in the same way, we still have terms like <d|h> and <h|h> so I can't see why it would fail.

I think it should be pretty trivial to implement since we subclass the regular likelihood. Although, it may be worth taking this opportunity to split up the regular likelihood a bit to remove some of the duplicate code.

Out of interest, how is phase marginalisation different? Can you not just use the same Bessel function for the <d|h> part? (I get that time needs more modification.)

Thanks @nikhil.sarin, I'll take a look a that!

@colm.talbot: Sounds good about the distance marginalisaton! And I think it'd be good to clean up the likelihood as much as we can, both to avoid duplication of code (and possibilities for introducing bugs in two places ) as well as keeping the general likelihood functions as nimble as we can.

The phase marginalisation is indeed the same, but in my experience phase marginalisation isn't actually worth it with a ROQ. The likelihood without the addition of the Bessel function evaluation is so much faster that in terms of absolute wall time you don't actually win by 'removing a parameter'. But since the modifications to the likelihood function isn't too severe it's nice to have in there.

With time marginalisation it is faster though!

changed milestone to %0.3.5

Closing as !247 (merged) was merged.

closed

unassigned @nikhil.sarin