bilby issueshttps://git.ligo.org/lscsoft/bilby/-/issues2023-11-13T03:51:23Zhttps://git.ligo.org/lscsoft/bilby/-/issues/683RelativeBinning optimisation doesn't account for Constraint priors2023-11-13T03:51:23ZCarl-Johan HasterRelativeBinning optimisation doesn't account for Constraint priorsWhen using the `RelativeBinningGravitationalWaveTransient` I've specified the fiducial waveform in terms of `{"chirp_mass": 3.163, "mass_ratio": 0.383, etc}`. This is a NSBH injection, that I want to analyse using the `SEOBNRv4_ROM_NRTid...When using the `RelativeBinningGravitationalWaveTransient` I've specified the fiducial waveform in terms of `{"chirp_mass": 3.163, "mass_ratio": 0.383, etc}`. This is a NSBH injection, that I want to analyse using the `SEOBNRv4_ROM_NRTidalv2_NSBH` waveform.
When the likelihood is initialised, it by default does the [update_fiducal_parameters](https://git.ligo.org/lscsoft/bilby/-/blob/master/bilby/gw/likelihood/relative.py#L155) step, and with the setup I used (optimising over the prior, since I hadn't specified any dedicated `parameter_bounds`) it "only" looks to optimise over `chirp_mass` and `mass_ratio`.
The problem is that the `SEOBNRv4_ROM_NRTidalv2_NSBH` model is only supported for `1 < mass_2 < 3`. I account for this in the actual Bilby configuration by having a `mass_2 = Constraint(name='mass_2', minimum=1.0, maximum=3.0)` in my prior, but since `mass_2` isn't in the `self.parameters_to_be_updated` list (see [here](https://git.ligo.org/lscsoft/bilby/-/blob/master/bilby/gw/likelihood/relative.py#L155)) that Constraint will not be accounted for, and the optimisation will fail since it'll try to evaluate `SEOBNRv4_ROM_NRTidalv2_NSBH` at a point that's nominally inside the `chirp_mass` and `mass_ratio` priors, but has a too-high NS mass.https://git.ligo.org/lscsoft/bilby/-/issues/680Interaction between relative binning initial search and calibration parameter...2023-11-13T03:53:29ZAaron ZimmermanInteraction between relative binning initial search and calibration parameter samplingWhen I run `bilby_pipe` with dynesty with both `calibration-model = CubicSpline` (using a standard calibration envelope) and `likelihood-type=bilby.gw.likelihood.relative.RelativeBinningGravitationalWaveTransient` the run fails when atte...When I run `bilby_pipe` with dynesty with both `calibration-model = CubicSpline` (using a standard calibration envelope) and `likelihood-type=bilby.gw.likelihood.relative.RelativeBinningGravitationalWaveTransient` the run fails when attempting to use the optimizer to find a fiducial point. @colm.talbot points out this is because the optimizer does not support domains with infinite prior support. I will check if specifying a fiducial point can allow for sampling to begin and update this issue.
My environment info is:
```
bilby_pipe version: 1.0.8
Running bilby version: 2.0.1
```
The traceback of the failed run is in the .err file in `log_data_generation`, and is
```
Traceback (most recent call last):
File "/home/sylvia.biscoveanu/.conda/envs/bilby_o4review_230314/bin/bilby_pipe_generation", line 10, in <module>
sys.exit(main())
File "/home/sylvia.biscoveanu/.conda/envs/bilby_o4review_230314/lib/python3.9/site-packages/bilby_pipe/data_generation.py", line 1357, in main
data.save_data_dump()
File "/home/sylvia.biscoveanu/.conda/envs/bilby_o4review_230314/lib/python3.9/site-packages/bilby_pipe/data_generation.py", line 1193, in save_data_dump
likelihood = self.likelihood
File "/home/sylvia.biscoveanu/.conda/envs/bilby_o4review_230314/lib/python3.9/site-packages/bilby_pipe/input.py", line 1197, in likelihood
likelihood = Likelihood(**likelihood_kwargs)
File "/home/sylvia.biscoveanu/.conda/envs/bilby_o4review_230314/lib/python3.9/site-packages/bilby/gw/likelihood/relative.py", line 166, in __init__
self.fiducial_parameters = self.find_maximum_likelihood_parameters(
File "/home/sylvia.biscoveanu/.conda/envs/bilby_o4review_230314/lib/python3.9/site-packages/bilby/gw/likelihood/relative.py", line 270, in find_maximum_likelihood_parameters
output = differential_evolution(
File "/home/sylvia.biscoveanu/.conda/envs/bilby_o4review_230314/lib/python3.9/site-packages/scipy/optimize/_differentialevolution.py", line 377, in differential_evolution
with DifferentialEvolutionSolver(func, bounds, args=args,
File "/home/sylvia.biscoveanu/.conda/envs/bilby_o4review_230314/lib/python3.9/site-packages/scipy/optimize/_differentialevolution.py", line 689, in __init__
raise ValueError('bounds should be a sequence containing '
ValueError: bounds should be a sequence containing real valued (min, max) pairs for each value in x
```https://git.ligo.org/lscsoft/bilby/-/issues/608Systematic errors of sidereal time in time marginalization2023-05-23T17:37:42ZSoichiro MorisakiSystematic errors of sidereal time in time marginalizationFor a PE run with time marginalization, `geocent_time` is fixed to the start time of data (See [this line](https://git.ligo.org/lscsoft/bilby/-/blob/master/bilby/gw/likelihood.py#L162)). This means the sidereal time is calculated at that...For a PE run with time marginalization, `geocent_time` is fixed to the start time of data (See [this line](https://git.ligo.org/lscsoft/bilby/-/blob/master/bilby/gw/likelihood.py#L162)). This means the sidereal time is calculated at that time rather than the coalescence time of signal. It leads to systematic errors of `~2pi * duration / (24 * 60 * 60)` in right ascension.
This could be an issue for BNS, whose duration is long. Below is the p-p plot for BNS signals, which are observed by `[H1, L1, V1]`, whose maximum luminosity distance is 100Mpc, and whose median SNR is ~25.
![p-p-plot](/uploads/e7652d7f2d87a9670a9b8fca6018c4ec/p-p-plot.jpeg)
The bad p-p plot for right ascension is fixed after the right ascension is incremented by the expected systematic error as follows:
```
correction = 2. * np.pi * duration / (24. * 60. * 60.)
samples["ra"] = np.fmod(samples["ra"] + correction, 2. * np.pi)
```
The plot attached below compares the p-p plots of right ascension before and after this correction.
![ra_corrected](/uploads/a63b2b52a4154b0b1ab95fccb170513f/ra_corrected.jpeg)
I should also note that the p-p runs were done with the ROQ likelihood in my local environment, into which I have implemented time marginalization. Since its implementation is almost same as that for `GravitationalWaveTransient`, I think the same thing happens for `GravitationalWaveTransient`.https://git.ligo.org/lscsoft/bilby/-/issues/531Add PSD marginalised GWT likelihoods2020-09-30T05:26:10ZColm Talbotcolm.talbot@ligo.orgAdd PSD marginalised GWT likelihoodsIf there is interest, I would like to add the likelihoods which marginalise over the uncertainty in averaged PSDs to the codebase. See [https://arxiv.org/abs/2006.05292](this paper) for details and [https://github.com/ColmTalbot/median-m...If there is interest, I would like to add the likelihoods which marginalise over the uncertainty in averaged PSDs to the codebase. See [https://arxiv.org/abs/2006.05292](this paper) for details and [https://github.com/ColmTalbot/median-marginalised-distributions/blob/master/src/likelihood.py](the implementation).
I know @gregory.ashton and @avi.vajpeyi have worked with similar likelihoods in the past.