bilby issueshttps://git.ligo.org/lscsoft/bilby/-/issues2020-06-30T23:02:20Zhttps://git.ligo.org/lscsoft/bilby/-/issues/496Bug in the evidence from merged runs2020-06-30T23:02:20ZGregory Ashtongregory.ashton@ligo.orgBug in the evidence from merged runsThe evidence from merged runs is being over estimated due to [this line](https://git.ligo.org/lscsoft/bilby/-/blob/master/bilby/core/result.py#L1653).
To verify this, here is some example code:
```python
In [19]: from scipy.special imp...The evidence from merged runs is being over estimated due to [this line](https://git.ligo.org/lscsoft/bilby/-/blob/master/bilby/core/result.py#L1653).
To verify this, here is some example code:
```python
In [19]: from scipy.special import logsumexp
In [20]: a = np.array([11, 12, 13]) # Create fake Z's
In [21]: np.sqrt(np.mean(a**2)) # Actual RMS value calculated directly
Out[21]: 12.027745701779143
In [22]: lna = np.log(a) # Take the natural log
In [23]: np.exp(0.5 * logsumexp(2 * lna, b=1. / len(a))) # This is how the RMS should be calculated
Out[23]: 12.027745701779143
In [24]: np.exp(logsumexp(2 * lna, b=1. / len(a))) # This is how we do it currently
Out[24]: 144.66666666666666
```1.0.0Gregory Ashtongregory.ashton@ligo.orgGregory Ashtongregory.ashton@ligo.orghttps://git.ligo.org/lscsoft/bilby/-/issues/439Conditional Priors not working reliably with Nested conditions2019-12-10T00:14:47ZMoritz HuebnerConditional Priors not working reliably with Nested conditionsConditional prior dicts are currently not working if there are multiple conditional priors which partly depend on each other.
I thought I tested this, but I must have missed it.Conditional prior dicts are currently not working if there are multiple conditional priors which partly depend on each other.
I thought I tested this, but I must have missed it.1.0.0Moritz HuebnerMoritz Huebnerhttps://git.ligo.org/lscsoft/bilby/-/issues/331Save correct luminosity distance when distance marginalizing2019-03-05T10:47:42ZMoritz HuebnerSave correct luminosity distance when distance marginalizingCurrently, when we marginalize over distance only the reference distance of 10 Mpc is saved into the result file. Working with result files than might require you to manually dig through the log to figure out the true luminosity distance.Currently, when we marginalize over distance only the reference distance of 10 Mpc is saved into the result file. Working with result files than might require you to manually dig through the log to figure out the true luminosity distance.1.0.0https://git.ligo.org/lscsoft/bilby/-/issues/320Add checking to the ROQ usage2019-11-21T03:21:03ZGregory Ashtongregory.ashton@ligo.orgAdd checking to the ROQ usageThe ROQ-basis comes with a `params.dat` file specifying things like the minimum and maximum chirp mass and sampling frequency. We should add a check to the `ROQLikelihood` that makes sure the given prior/sampling frequency is suitable.
...The ROQ-basis comes with a `params.dat` file specifying things like the minimum and maximum chirp mass and sampling frequency. We should add a check to the `ROQLikelihood` that makes sure the given prior/sampling frequency is suitable.
Chatting with @eric.thrane and @cjhaster it seems to me to make sense that, if the user-specific-prior is narrower then we should print a statement saying "prior okay" and continue, if the prior is not given, we should set the bounds correctly, and if the user-specified-prior is larger than the allowed range, `bilby` should raise an Error.1.0.0Carl-Johan HasterMichael PuerrerCarl-Johan Hasterhttps://git.ligo.org/lscsoft/bilby/-/issues/319Make bilby (or bilby_pipe) default PSD creation equivalent to LALInference2019-03-05T11:37:13ZGregory Ashtongregory.ashton@ligo.orgMake bilby (or bilby_pipe) default PSD creation equivalent to LALInferenceWe want to (by default) recreate what happens in LALInference for the PSD creation. This might need a combination of changes between `bilby` and `bilby_pipe`.
### Notes
In !366 we allowed the PSD to overlap the analysis segment. This t...We want to (by default) recreate what happens in LALInference for the PSD creation. This might need a combination of changes between `bilby` and `bilby_pipe`.
### Notes
In !366 we allowed the PSD to overlap the analysis segment. This takes the PSD duration of data, cuts out the analysis segment, then creates a PSD from the remaining data. As such, if one requests 100s of data for the PSD, one actually gets to use 100 - segment_length s of data.
We could add a catch to actually calc psd_duration + segment_length amount of data which then gets reduced to the proper amount.
1.0.0Vivien RaymondRhys GreenCharlie HoyVivien Raymondhttps://git.ligo.org/lscsoft/bilby/-/issues/317ROQ Likelihood does not permit the calculation of SNRs (which breaks conversi...2019-03-11T01:20:04ZEthan PayneROQ Likelihood does not permit the calculation of SNRs (which breaks conversion functions)When trying to use `gw.conversion._generate_all_cbc_parameters`, using the ROQ likelihood will break the post-processing stage, when the SNR cannot be calculated. The traceback is:
```
21:29 bilby WARNING : linear not a polarization mod...When trying to use `gw.conversion._generate_all_cbc_parameters`, using the ROQ likelihood will break the post-processing stage, when the SNR cannot be calculated. The traceback is:
```
21:29 bilby WARNING : linear not a polarization mode!
Traceback (most recent call last):
...
File "bilby/gw/conversion.py", line 966, in compute_snrs
signal_polarizations, sample.iloc[ii])
File "bilby/gw/detector.py", line 1281, in get_detector_response
parameters['psi'], mode)
File "bilby/gw/detector.py", line 1259, in antenna_response
return np.einsum('ij,ij->', self.detector_tensor, polarization_tensor)
```
@colm.talbot @gregory.ashton1.0.0Nikhil SarinNikhil Sarinhttps://git.ligo.org/lscsoft/bilby/-/issues/314ROQ doesn't convert arguments to float2019-02-20T00:29:22ZColm Talbotcolm.talbot@ligo.orgROQ doesn't convert arguments to float`lalsimulation` functions require all arguments to be floats, otherwise you get errors like `Argument 8 of type REAL8`.
This was done previously, e.g., https://git.ligo.org/lscsoft/bilby/blob/master/bilby/gw/utils.py#L744. I didn't also...`lalsimulation` functions require all arguments to be floats, otherwise you get errors like `Argument 8 of type REAL8`.
This was done previously, e.g., https://git.ligo.org/lscsoft/bilby/blob/master/bilby/gw/utils.py#L744. I didn't also do this for the ROQ. We should...
@ethan.payne1.0.0https://git.ligo.org/lscsoft/bilby/-/issues/305Waveforms don't match LALInference2019-02-20T05:08:11ZSylvia BiscoveanuWaveforms don't match LALInferenceI've compared waveforms generated directly in LALInference versus using Bilby's waveform generator. I'm using TaylorF2 and have made sure the srate, min frequency, seglen, etc. are the same between the two. In the frequency domain the sp...I've compared waveforms generated directly in LALInference versus using Bilby's waveform generator. I'm using TaylorF2 and have made sure the srate, min frequency, seglen, etc. are the same between the two. In the frequency domain the spectral shape is quite different, which is weird to me if it's the same approximant, but they seem to converge at the min and max frequencies. The four injections I've plotted are all 1.4 Msun equal mass, non-spinning binaries, so only the extrinsic parameters are different. In the time domain they line up and have the same overall amplitude, but the behavior at early times is a bit different. Any ideas what's going on? It's definitely not an issue of the antenna patterns since the amplitudes line up (and I've checked that the LAL and Bilby versions return the same values for the same extrinsic parameters).
![compare_lal_bilby_freq](/uploads/6cef78c33b7f2e4c8679d170ea7675db/compare_lal_bilby_freq.png)
![compare_lal_bilby_time](/uploads/84c65845456a8513c7bc0f7d35e02ac8/compare_lal_bilby_time.png)1.0.0https://git.ligo.org/lscsoft/bilby/-/issues/272Unexpected behaviour when converting to all BBH parameters with phase margina...2019-05-09T00:46:36ZEthan PayneUnexpected behaviour when converting to all BBH parameters with phase marginalization turned onWhen undertaking a run, sampling in the LALInference spin parameters (a_1, a_2, tilt_1, etc) with phase marginalization, and then converting to a x,y,z spin vector, a phase of zero is used for the conversion function, as this is the defa...When undertaking a run, sampling in the LALInference spin parameters (a_1, a_2, tilt_1, etc) with phase marginalization, and then converting to a x,y,z spin vector, a phase of zero is used for the conversion function, as this is the default output from the sampler when running PE with phase marginalization.
This not correct, as the phase should be determined from the analytic marginalization. My key issue with this is that the code will gladly do this without warning, such that I can get spin*_x,y,z which are not computed correctly. Not sure what the best way to fix this is, but it shouldn't be silent...
Tagged: @eric.thrane @moritz.huebner1.0.0Colm Talbotcolm.talbot@ligo.orgColm Talbotcolm.talbot@ligo.org