Likelihood values do not match due to imprecise strain data duration

[SSL32081]

When gwpy fetches open data, it does not necessarily return strain data with the exact same start_time as requested, and the difference is typically of order 0.001 s.

In the current implementation, when shifting waveforms to the right geocentric time to compute fd_response, it defines the time shift as follows (src/jimgw/single_event/likelihood.py#L155):

(self.epoch + params["t_c”])

# and self.epoch is:
self.duration - self.post_trigger_duration

With a 4 s data segment, this epoch typically equals 2.00 s exactly, but this may not be the case in the strain data itself.

There are several ways out:

1. Similar to Bilby, store the actual start_time of the strain data and compute the shift as params[‘geocent_time’] - strain_data.start_time (see e.g. here)
2. Use the precise duration when initialising the likelihood object.
3. Something else

To illustrate the impact of this subtle difference, the two plots show the difference between the log-likelihood computed with Jim and with Bilby, using the IMRPhenomPv2 waveform model. Both of them are initialised with the exact same data and psd. On the right, the likelihood is initialised as usual, using the input duration, whereas on the left, the exact duration of the strain data is used instead.

The difference in logL on the left using the imprecise duration can go up to 12 log units, and it is reduced down to order 0.04 by simply using the exact duration.

The likelihood are evaluated on 100 samples that are randomly drawn from the posterior of an example PE run of GW150914.

There are a couple more things to check:

• Whether this is an issue using other means of loading data, e.g. reading frame files directly
• The time delay from geo-centre and antenna patterns also have subtle differences, which could potentially lead to different logL values in some corner cases.