bilby issueshttps://git.ligo.org/lscsoft/bilby/-/issues2024-03-15T22:02:25Zhttps://git.ligo.org/lscsoft/bilby/-/issues/724Missing import in bilby.gw.detector.load_data_from_cache_file2024-03-15T22:02:25ZHoward DeshongMissing import in bilby.gw.detector.load_data_from_cache_file`bilby.gw.detector.load_data_from_cache_file` fails since it appears to be missing an `import lal`:
```
python bilby_run.py
Traceback (most recent call last):
File "/Users/howard/Desktop/output/2024-02-12/g...`bilby.gw.detector.load_data_from_cache_file` fails since it appears to be missing an `import lal`:
```
python bilby_run.py
Traceback (most recent call last):
File "/Users/howard/Desktop/output/2024-02-12/gw150914_bilby/bilby_run.py", line 49, in <module>
interferometer = bilby.gw.detector.load_data_from_cache_file(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/homebrew/Caskroom/miniconda/base/envs/bilby/lib/python3.11/site-packages/bilby/gw/detector/__init__.py", line 254, in load_data_from_cache_file
cache = lal.utils.cache.CacheEntry(line)
^^^
NameError: name 'lal' is not defined
```
The line mentioned in the traceback is here: https://git.ligo.org/lscsoft/bilby/-/blob/f8b004a80fa2f735b171b144154d5563f569abdf/bilby/gw/detector/__init__.py#L254
Sure enough, that file does not `import lal`, so I believe adding it would fix this issue.Sama Al-ShammariSama Al-Shammarihttps://git.ligo.org/lscsoft/bilby/-/issues/726Linestyle bug in bilby.core.result.plot_multiple2024-03-15T22:00:00ZMichael Williamsmichael.williams@ligo.orgLinestyle bug in bilby.core.result.plot_multipleWhen calling `bilby.core.result.plot_multiple` with multiple results, the following warning is printed:
```
/mnt/lustre/shared_conda/envs/mjwill/bilby/lib/python3.10/site-packages/corner/core.py:795: UserWarning: The following kwargs we...When calling `bilby.core.result.plot_multiple` with multiple results, the following warning is printed:
```
/mnt/lustre/shared_conda/envs/mjwill/bilby/lib/python3.10/site-packages/corner/core.py:795: UserWarning: The following kwargs were not used by contour: 'linestyle'
ax.contour(X2, Y2, H2.T, V, **contour_kwargs)
```
This appears to happen because of the `linestyle` keyword argument that is added [on this line](https://git.ligo.org/lscsoft/bilby/-/blob/master/bilby/core/result.py?ref_type=heads#L2060).
Based on the [corner documentation](https://corner.readthedocs.io/en/latest/api/#corner.hist2d), `contour_kwargs` is passed to the `contour` method, which I think refers to `matplotlib.pyplot.contour`. Looking at the [documentation for that function](https://matplotlib.org/stable/api/_as_gen/matplotlib.pyplot.contour.html), I think it should be `linestyles` instead of `linestyle` but I have not tested this.Ben PattersonBen Pattersonhttps://git.ligo.org/lscsoft/bilby/-/issues/690AttributeError when calling bilby.run_sampler with Dynesty sampler2024-03-15T21:54:34ZBrian HealyAttributeError when calling bilby.run_sampler with Dynesty samplerHello, I'm trying to run this code (https://github.com/nuclear-multimessenger-astronomy/nmma/blob/main/nmma/em/analysis.py) that uses bilby. When the code calls `bilby.run_sampler`, I get the following error having to do with the `Dynest...Hello, I'm trying to run this code (https://github.com/nuclear-multimessenger-astronomy/nmma/blob/main/nmma/em/analysis.py) that uses bilby. When the code calls `bilby.run_sampler`, I get the following error having to do with the `Dynesty` object that bilby creates:
```
Traceback (most recent call last):
File "/Users/bhealy/miniforge3/envs/nmma_api2/bin/light_curve_analysis", line 33, in <module>
sys.exit(load_entry_point('nmma==0.0.8', 'console_scripts', 'light_curve_analysis')())
File "/Users/bhealy/nmma/nmma/em/analysis.py", line 608, in main
result = bilby.run_sampler(
File "/Users/bhealy/miniforge3/envs/nmma_api2/lib/python3.9/site-packages/bilby/core/sampler/__init__.py", line 190, in run_sampler
sampler = sampler_class(
File "/Users/bhealy/miniforge3/envs/nmma_api2/lib/python3.9/site-packages/bilby/core/sampler/dynesty.py", line 234, in __init__
int(check_point_delta_t / self._log_likelihood_eval_time / 10), 10
AttributeError: 'Dynesty' object has no attribute '_log_likelihood_eval_time'
```
I'm happy to provide more details as needed. Thank you!Alexandre GoettelAlexandre Goettelhttps://git.ligo.org/lscsoft/bilby/-/issues/725Replace calls to numpy.product with numpy.prod2024-02-26T18:37:37ZMichael Williamsmichael.williams@ligo.orgReplace calls to numpy.product with numpy.prodAs of numpy 1.25.0, `numpy.product` is deprecated in favour of `numpy.prod`, see the [release notes](https://numpy.org/devdocs/release/1.25.0-notes.html#deprecations). It will be removed entirely in 2.0.0. Using it returns the following ...As of numpy 1.25.0, `numpy.product` is deprecated in favour of `numpy.prod`, see the [release notes](https://numpy.org/devdocs/release/1.25.0-notes.html#deprecations). It will be removed entirely in 2.0.0. Using it returns the following warning:
```
DeprecationWarning: `product` is deprecated as of NumPy 1.25.0, and will be removed in NumPy 2.0. Please use `prod` instead.
```
It is used in at least one place and referenced in some doc-strings. These should be updated to use `prod`.Gregory Ashtongregory.ashton@ligo.orgGregory Ashtongregory.ashton@ligo.orghttps://git.ligo.org/lscsoft/bilby/-/issues/723typo in 3 lines2024-02-26T17:25:53ZManuel Piarullitypo in 3 linesHi, I found a typo in 3 lines:
https://git.ligo.org/lscsoft/bilby/-/blame/master/bilby/gw/source.py#L208
https://git.ligo.org/lscsoft/bilby/-/blame/master/bilby/gw/source.py#L617
https://git.ligo.org/lscsoft/bilby/-/blame/master/bilby/g...Hi, I found a typo in 3 lines:
https://git.ligo.org/lscsoft/bilby/-/blame/master/bilby/gw/source.py#L208
https://git.ligo.org/lscsoft/bilby/-/blame/master/bilby/gw/source.py#L617
https://git.ligo.org/lscsoft/bilby/-/blame/master/bilby/gw/source.py?page=2#L1127
it's not something dangerous, since all of them are just 'print' in case of some errors.
typo:` spin_1=(spin_1x, spin_**2**y, spin_1z)`--> spin_1=(spin_1x, spin_**1**y, spin_1z)`
Best,
Manuel PiarulliAlexandre GoettelAlexandre Goettelhttps://git.ligo.org/lscsoft/bilby/-/issues/646FEATURE: Compute the per-detector likelihoods as part of post-processing2022-12-06T00:08:19ZColm Talbotcolm.talbot@ligo.orgFEATURE: Compute the per-detector likelihoods as part of post-processingCurrently, in post-processing we compute a lot of additional quantities (see [this function](https://git.ligo.org/lscsoft/bilby/-/blob/master/bilby/gw/conversion.py#L816) and within). It would be great if these could also include the per...Currently, in post-processing we compute a lot of additional quantities (see [this function](https://git.ligo.org/lscsoft/bilby/-/blob/master/bilby/gw/conversion.py#L816) and within). It would be great if these could also include the per-detector likelihoods.
This should include the same extrinsic marginalizations as the full likelihood so it would probably need to be done before reconstructing the marginalized parameters.https://git.ligo.org/lscsoft/bilby/-/issues/644Bilby MCMC: Sampler gets stuck when checkpoint fails2022-09-29T09:48:18ZColm Talbotcolm.talbot@ligo.orgBilby MCMC: Sampler gets stuck when checkpoint failsI noticed that one of my jobs that was failing to checkpoint and it got stuck in a loop where it tried to write the checkpoint at every iteration. I think the issue is that if the checkpoint this line always fails.
I think the fix will ...I noticed that one of my jobs that was failing to checkpoint and it got stuck in a loop where it tried to write the checkpoint at every iteration. I think the issue is that if the checkpoint this line always fails.
I think the fix will be to set `self.check_point_delta_t = np.inf` in [this clause](https://git.ligo.org/lscsoft/bilby/-/blob/master/bilby/bilby_mcmc/sampler.py#L388).https://git.ligo.org/lscsoft/bilby/-/issues/53Check the template fits in the segment2021-09-03T14:43:07ZColm Talbotcolm.talbot@ligo.orgCheck the template fits in the segmentWe should have a test that the CBC signal we're using as the template actually fits within the segment we're using.
There may be `lalsimulation` functions to test this. I'll have a look if no-one else wants to.
We could either do this...We should have a test that the CBC signal we're using as the template actually fits within the segment we're using.
There may be `lalsimulation` functions to test this. I'll have a look if no-one else wants to.
We could either do this when we start sampling by testing the prior or do it at each sample point if it isn't going to be too expensive.
@rory\-smith @paul\-lasky @gregory.ashton any thoughts?Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/545Tutorial has incorrect documentation2021-07-15T13:42:35ZAvi Vajpeyiavi.vajpeyi@ligo.orgTutorial has incorrect documentationIssue discovered by Konstantin Leyde.
[Visualising the results tut](https://git.ligo.org/lscsoft/bilby/blob/master/examples/tutorials/visualising_the_results.ipynb) has the following :
```python
# specify injection parameters
injection_...Issue discovered by Konstantin Leyde.
[Visualising the results tut](https://git.ligo.org/lscsoft/bilby/blob/master/examples/tutorials/visualising_the_results.ipynb) has the following :
```python
# specify injection parameters
injection_parameters = dict(
mass_1=36., # source frame (non-redshifted) primary mass (solar masses)
mass_2=29., # source frame (non-redshifted) secondary mass (solar masses)
a_1=0.4, # primary dimensionless spin magnitude
```
The comments for this are incorrect (the comments should say lab frame instead of source frame).
Eg When i access `result.posterior.mass_1` I get the lab frame masses, while `result.posterior.mass_1_source` provides the source frame masses.https://git.ligo.org/lscsoft/bilby/-/issues/507Store "information gain" from nested sampling routines in Result class2021-03-22T17:42:01ZMatthew PitkinStore "information gain" from nested sampling routines in Result classWe should add the ability to store the "information gain" aka, the KL divergence, that is calculated by most nested sampling routines, to the `Result` object.We should add the ability to store the "information gain" aka, the KL divergence, that is calculated by most nested sampling routines, to the `Result` object.Kaylee deSotoKaylee deSotohttps://git.ligo.org/lscsoft/bilby/-/issues/541Use tqdm.auto for better notebook performance2020-12-23T06:16:20ZColm Talbotcolm.talbot@ligo.orgUse tqdm.auto for better notebook performanceI've been doing some Bilby things in notebooks recently and the progress bars have some known issues in Jupyter notebooks.
Fortunately, it looks like there's a `tqdm.auto` module which automagically uses the best backend. I think this i...I've been doing some Bilby things in notebooks recently and the progress bars have some known issues in Jupyter notebooks.
Fortunately, it looks like there's a `tqdm.auto` module which automagically uses the best backend. I think this is worth looking into.https://git.ligo.org/lscsoft/bilby/-/issues/520EOS file names with underscores not parsed correctly2020-09-21T22:20:22ZSylvia BiscoveanuEOS file names with underscores not parsed correctlyI was trying to load the APR4_EPP EOS file, using
```
apr4_eos = bilby.gw.eos.TabularEOS('APR4_EPP')
apr4_fam = bilby.gw.eos.EOSFamily(apr4_eos)
```
but I get `OSError: APR4_EPP not found.` Upon further investigation, it turns out that t...I was trying to load the APR4_EPP EOS file, using
```
apr4_eos = bilby.gw.eos.TabularEOS('APR4_EPP')
apr4_fam = bilby.gw.eos.EOSFamily(apr4_eos)
```
but I get `OSError: APR4_EPP not found.` Upon further investigation, it turns out that the file names with underscores are not being parsed correctly by this line of code: https://git.ligo.org/lscsoft/bilby/-/blob/master/bilby/gw/eos/eos.py#L32
So, when I look at the `bilby.gw.eos.eos.valid_eos_names`, only the sequence of letters after the underscore is being stored, in this case `EPP`.https://git.ligo.org/lscsoft/bilby/-/issues/346Symmetric uniform priors2020-07-26T12:31:37ZIan JonesSymmetric uniform priorsI was wondering if it would be possible for someone to add a new sort of prior, that would allow for the relevant quantity, let's call it x, to be drawn from a uniform distribution that was symmetric with respect to x --> -x, i.e. unifor...I was wondering if it would be possible for someone to add a new sort of prior, that would allow for the relevant quantity, let's call it x, to be drawn from a uniform distribution that was symmetric with respect to x --> -x, i.e. uniform over the ranges
a < x < b and -b < x < -a
where a and b are positive constants. (This means there would be a probability of 0.5 that x is positive, and a probability of 0.5 that it is negative). This would mirror the already-implemented SymmetricLogUniform prior that Greg recently added.https://git.ligo.org/lscsoft/bilby/-/issues/406PowerLaw prior does not check if prior minimum/maximum are valid2020-04-25T01:10:32ZMoritz HuebnerPowerLaw prior does not check if prior minimum/maximum are valid```
---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call last)
<ipython-input-58-1f15b00eece0> in <module>()
1 grid = np.linspace(0.1, 5, ...```
---------------------------------------------------------------------------
ZeroDivisionError Traceback (most recent call last)
<ipython-input-58-1f15b00eece0> in <module>()
1 grid = np.linspace(0.1, 5, 100)
----> 2 plt.plot(grid, p.prob(grid))
3 plt.xlabel('value')
4 plt.ylabel('probability')
5 plt.savefig('prior_1')
/usr/local/lib/python3.6/dist-packages/bilby/core/prior.py in prob(self, val)
1016 return np.nan_to_num(val ** self.alpha * (1 + self.alpha) /
1017 (self.maximum ** (1 + self.alpha) -
-> 1018 self.minimum ** (1 + self.alpha))) * self.is_in_prior_range(val)
1019
1020 def ln_prob(self, val):
ZeroDivisionError: 0.0 cannot be raised to a negative power
```
Here my `self.minimum` was 0. We should catch this earlier.FutureMoritz HuebnerVirginia d'EmilioMoritz Huebnerhttps://git.ligo.org/lscsoft/bilby/-/issues/451Update default LIGO PSD2020-04-24T18:05:45ZColm Talbotcolm.talbot@ligo.orgUpdate default LIGO PSDThe default noise curve used is out of date and should be updated to use https://dcc.ligo.org/LIGO-T1800044/public.
This will cause quite a lot of changes to existing analyses. It will still be possible to use the current PSD, we can ju...The default noise curve used is out of date and should be updated to use https://dcc.ligo.org/LIGO-T1800044/public.
This will cause quite a lot of changes to existing analyses. It will still be possible to use the current PSD, we can just leave that in the repository.
I think the only changes that are needed are in the interferometer files.
- https://git.ligo.org/lscsoft/bilby/blob/master/bilby/gw/detector/detectors/H1.interferometer
- https://git.ligo.org/lscsoft/bilby/blob/master/bilby/gw/detector/detectors/L1.interferometerhttps://git.ligo.org/lscsoft/bilby/-/issues/470Matplotlib deprecation warning2020-04-22T04:28:41ZColm Talbotcolm.talbot@ligo.orgMatplotlib deprecation warningThis warning is happening on import. We should remove the warn.
```
bilby/core/utils.py:966: MatplotlibDeprecationWarning: The 'warn' parameter of use() is deprecated since Matplotlib 3.1 and will be removed in 3.3. If any parameter fo...This warning is happening on import. We should remove the warn.
```
bilby/core/utils.py:966: MatplotlibDeprecationWarning: The 'warn' parameter of use() is deprecated since Matplotlib 3.1 and will be removed in 3.3. If any parameter follows 'warn', they should be pass as keyword, not positionally.
matplotlib.use(backend, warn=False)
```https://git.ligo.org/lscsoft/bilby/-/issues/437Allow lal dictionary to be passed through to `_base_lal_cbc_fd_waveform`2020-04-07T13:32:06ZColm Talbotcolm.talbot@ligo.orgAllow lal dictionary to be passed through to `_base_lal_cbc_fd_waveform`If we allow `_base_lal_cbc_fd_waveform` to be passed a `lal.dict` rather than creating it itself, it will probably make it easier to include deviation parameters for tests of GR, e.g, https://git.ligo.org/lscsoft/bilby/issues/432.
I thi...If we allow `_base_lal_cbc_fd_waveform` to be passed a `lal.dict` rather than creating it itself, it will probably make it easier to include deviation parameters for tests of GR, e.g, https://git.ligo.org/lscsoft/bilby/issues/432.
I think the only change within `bilby` would be at https://git.ligo.org/lscsoft/bilby/blob/master/bilby/gw/source.py#L324 do
```python
waveform_dictionary = waveform_kwargs.get("lal_dictionary", lal.CreateDict())
```
The new syntax would be something like
```python
def non_gr_binary_black_hole(
frequency_array, mass_1, mass_2, luminosity_distance, a_1, tilt_1,
phi_12, a_2, tilt_2, phi_jl, theta_jn, phase, non_gr_parameter_1,
non_gr_parameter_2, **kwargs):
waveform_kwargs = dict(
waveform_approximant='IMRPhenomPv2', reference_frequency=50.0,
minimum_frequency=20.0, maximum_frequency=frequency_array[-1],
pn_spin_order=-1, pn_tidal_order=-1, pn_phase_order=-1, pn_amplitude_order=0)
waveform_kwargs.update(kwargs)
lal_dictionary = lal.CreateDict()
# insert non-GR parameters
waveform_kwargs["lal_dictionary"] = lal_dictionary
return _base_lal_cbc_fd_waveform(
frequency_array=frequency_array, mass_1=mass_1, mass_2=mass_2,
luminosity_distance=luminosity_distance, theta_jn=theta_jn, phase=phase,
a_1=a_1, a_2=a_2, tilt_1=tilt_1, tilt_2=tilt_2, phi_12=phi_12,
phi_jl=phi_jl, **waveform_kwargs)
```https://git.ligo.org/lscsoft/bilby/-/issues/430Add normalisation flag to constrained prior2020-04-02T03:01:59ZColm Talbotcolm.talbot@ligo.orgAdd normalisation flag to constrained priorWhen using constrained priors `ConstrainedPriorDict.prob` is not properly normalised.
In some cases, we know exactly the normalisation factor, e.g., for the following setup the appropriate normalisation factor is two.
```python
mass_1 ...When using constrained priors `ConstrainedPriorDict.prob` is not properly normalised.
In some cases, we know exactly the normalisation factor, e.g., for the following setup the appropriate normalisation factor is two.
```python
mass_1 = Uniform(5, 50)
mass_2 = Uniform(5, 50)
mass_ratio = Constraint(0, 1)
```
It would be good to enable users to specify the appropriate renormalisation in this case. I imagine the syntax being something like
```python
mass_1 = Uniform(5, 50)
mass_2 = Uniform(5, 50)
mass_ratio = Constraint(0, 1, normalization=2)
```
Any thoughts?
EDIT:
A potential extension when the normalisation is not known is to keep track of how many samples are rejected when sampling from the prior, e.g., https://git.ligo.org/lscsoft/bilby/blob/master/bilby/core/prior.py#L344. The ratio of proposed points to accepted points will be this normalisation.
I half implemented an attempt to keep track of the fraction of points accepted in https://git.ligo.org/lscsoft/bilby/merge_requests/476, https://git.ligo.org/lscsoft/bilby/blob/prior-jacobians/bilby/core/prior.py#L361.https://git.ligo.org/lscsoft/bilby/-/issues/419Healpix prior2020-02-06T03:39:24ZGregory Ashtongregory.ashton@ligo.orgHealpix priorAdd a method to read in and use a healpix prior (e.g. from Fermi/INTEGRAL). I suspect this will need some close interaction with the correlated prior.Add a method to read in and use a healpix prior (e.g. from Fermi/INTEGRAL). I suspect this will need some close interaction with the correlated prior.Zoheyr DoctorBruce EdelmanJonathan MerrittZoheyr Doctorhttps://git.ligo.org/lscsoft/bilby/-/issues/448Beta prior prob method fails on pandas objects2020-01-29T00:26:23ZColm Talbotcolm.talbot@ligo.orgBeta prior prob method fails on pandas objectsI got the following error using the `Beta` prior when evaluating the prior after the run finished.
```python
File "/Users/ctal0001/modules/bilby/bilby/core/prior.py", line 2175, in ln_prob
if np.isfinite(_ln_prob) and val >= self....I got the following error using the `Beta` prior when evaluating the prior after the run finished.
```python
File "/Users/ctal0001/modules/bilby/bilby/core/prior.py", line 2175, in ln_prob
if np.isfinite(_ln_prob) and val >= self.minimum and val <= self.maximum:
File "/Users/ctal0001/anaconda2/envs/psd_model/lib/python3.7/site-packages/pandas/core/generic.py", line 1478, in __nonzero__
.format(self.__class__.__name__))
ValueError: The truth value of a Series is ambiguous. Use a.empty, a.bool(), a.item(), a.any() or a.all().
```
I think the problem is https://git.ligo.org/lscsoft/bilby/blob/master/bilby/core/prior.py#L2127. In most other places we test whether the argument is a `float`/`int`, however, this explicitly looks for a `np.ndarray`. I would suggest that we flip the order of the `if` statement to align with the other cases.