bilby issueshttps://git.ligo.org/lscsoft/bilby/-/issues2019-02-25T23:23:29Zhttps://git.ligo.org/lscsoft/bilby/-/issues/257Check for duplicate parameters2019-02-25T23:23:29ZGregory Ashtongregory.ashton@ligo.orgCheck for duplicate parametersCurrently, if you pass in a prior on mass1, mass2, chirp_mass, and mass ratio, the sample will sample in all of these parameters (unclear which prior is actually being used). It is ugly and unlikely to be completely safe, but we need som...Currently, if you pass in a prior on mass1, mass2, chirp_mass, and mass ratio, the sample will sample in all of these parameters (unclear which prior is actually being used). It is ugly and unlikely to be completely safe, but we need some way to alert the user. At the basic level, a series of if statements will suffice. @eric.thrane had some ideas for common examples.FutureMoritz HuebnerMoritz Huebnerhttps://git.ligo.org/lscsoft/bilby/-/issues/410Discontinue Python 2.7 support?2020-01-15T05:25:11ZMatthew PitkinDiscontinue Python 2.7 support?Come the new year are we planning to continue trying to make sure bilby supports both Python 2.7 and Python 3, or will we move to a development state where we don't explicitly try and keep everything Python 2.7 compatible? I imagine that...Come the new year are we planning to continue trying to make sure bilby supports both Python 2.7 and Python 3, or will we move to a development state where we don't explicitly try and keep everything Python 2.7 compatible? I imagine that we should make sure the v1.0 release works for Python 2.7, but maybe after that we could move to Python 3-only support?Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/396Issue when sampling using BasicGravitationalWaveTransient2019-08-20T00:56:27ZJonathan DaviesIssue when sampling using BasicGravitationalWaveTransientI've been trying to modify the bilby code so that uncertainty in the form of the PSD can be folded into the analysis i.e. multiple PSD files are loaded in and the indices of these are implemented as parameters to be fitted. The error sho...I've been trying to modify the bilby code so that uncertainty in the form of the PSD can be folded into the analysis i.e. multiple PSD files are loaded in and the indices of these are implemented as parameters to be fitted. The error shown below got thrown up in run_sampler, as I am using BasicGravitationalWaveTransient rather than GravitationalWaveTransient in bilby/bilby/gw/likelihood.py. It gets called like this:
result = bilby.run_sampler(
likelihood, prior, outdir=outdir, label=label,
sampler=sampler, npoints=npoints, use_ratio=False,
injection_parameters=None,
conversion_function=bilby.gw.conversion.generate_all_bbh_parameters, resume=False, n_check_point=5000)
It seems that the issue is that the generate_all_bbh_parameters function is expecting the likelihood to have the various marginalization flags as attributes, and it fails for the Basic version which doesn't have those options.
Traceback (most recent call last):
File "GW150914_advanced.py", line 130, in <module>
conversion_function=bilby.gw.conversion.generate_all_bbh_parameters, resume=True, n_check_point=5000)
File "/home/jonathan.davies/bilby/bilby/core/sampler/__init__.py", line 203, in run_sampler
conversion_function=conversion_function)
File "/home/jonathan.davies/bilby/bilby/core/result.py", line 1072, in samples_to_posterior
data_frame = conversion_function(data_frame, likelihood, priors)
File "/home/jonathan.davies/bilby/bilby/gw/conversion.py", line 703, in generate_all_bbh_parameters
likelihood=likelihood, priors=priors)
File "/home/jonathan.davies/bilby/bilby/gw/conversion.py", line 667, in _generate_all_cbc_parameters
samples=output_sample, likelihood=likelihood)
File "/home/jonathan.davies/bilby/bilby/gw/conversion.py", line 1015, in generate_posterior_samples_from_marginalized_likelihood
if not any([likelihood.phase_marginalization,
AttributeError: 'BasicGravitationalWaveTransient' object has no attribute 'phase_marginalization'FutureSylvia BiscoveanuSylvia Biscoveanuhttps://git.ligo.org/lscsoft/bilby/-/issues/365Define credible interval object2019-05-07T00:50:56ZGregory Ashtongregory.ashton@ligo.orgDefine credible interval objectIn !446 @sylvia.biscoveanu added a `confidence_interval` method. This is super useful and I can see lots of people making use of it. Before it becomes widely used (and hence we can't monkey around with it), it would be good to generalise...In !446 @sylvia.biscoveanu added a `confidence_interval` method. This is super useful and I can see lots of people making use of it. Before it becomes widely used (and hence we can't monkey around with it), it would be good to generalise it.
Ideally, we should have a `CredibelInterval` object which behaves as such
```python
>>> ci = CredibleInterval(data, level)
>>> print(ci.lower_absolute, ci.upper_absolute, ci.median, ci.lower_relative, ci.upper_relative)
```
such that `ci.lower_absolute` is the value of the lower C.I while `ci_lower_relative` would be the relative offset (not sure that naming convention is the best, but you get the idea hopefully).
It could also do neat things like
```python
>>> str(ci)
"10.2^{+0.2}_{-0.3}"
```Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/304Organise the examples2019-08-20T00:56:44ZGregory Ashtongregory.ashton@ligo.orgOrganise the examplesWe need to organize the examples directory to
* Clearly indicate gw and non-gw examples
* Create a set of "core" examples differentiated from, perhaps, more specific examples
* Provide clear documentation (both a README in the directory...We need to organize the examples directory to
* Clearly indicate gw and non-gw examples
* Create a set of "core" examples differentiated from, perhaps, more specific examples
* Provide clear documentation (both a README in the directory and well described links from the docs)
* Take into consideration files that are referred to in the Bilby paper.FuturePaul EasterPaul Easterhttps://git.ligo.org/lscsoft/bilby/-/issues/293Nice skyLoc priors2019-10-21T17:38:30ZCarl-Johan HasterNice skyLoc priorsWhen doing followup of externally triggered events (cf. GRBs) their sky locations are often specified as a `RA-dec` point with an error radius. It'd be good to be able to specify this as a prior on the sky, either as a simple unimodal Ga...When doing followup of externally triggered events (cf. GRBs) their sky locations are often specified as a `RA-dec` point with an error radius. It'd be good to be able to specify this as a prior on the sky, either as a simple unimodal Gaussian where the error radius is interpreted as the Gaussian's standard deviation, or as a correlated Gaussian (but that's probably overkill for this simple model). Care would have to be taken about the general cyclic nature of the `RA-dec` parameters such that the `RA = 0 = 2pi` or `dec = |pi/2|` points doesn't mess things up.
It'd also be good, ie even better!, to be able to read in a FITS file directly as the sky prior.Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/291Make a detector response function for time domain response2019-09-27T04:43:30ZIsobel Marguarethe Romero-ShawMake a detector response function for time domain responseThe initial calculations for getting the detector antennae response are generic between *t* and *f* domains, so this can be pulled out into a sub-function. There should then either be seperate *t* and *f* domain detector response functio...The initial calculations for getting the detector antennae response are generic between *t* and *f* domains, so this can be pulled out into a sub-function. There should then either be seperate *t* and *f* domain detector response functions, or an argument determining which format to return the response in.Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/280Vectorise likelihood function to accept arrays of parameters2019-06-25T03:45:55ZEric ThraneVectorise likelihood function to accept arrays of parameters@ethan.payne and I are working to make some post-processing code. In order to do this quickly, we need to evaluate the likelihood function for different points in parameter space as parallel operations. Ethan looked into doing this with ...@ethan.payne and I are working to make some post-processing code. In order to do this quickly, we need to evaluate the likelihood function for different points in parameter space as parallel operations. Ethan looked into doing this with bilby, but he determined that it's coded in such a way that the user is forced to pass single parameter values, meaning that multiple likelihood evaluations have to go in a (very slow) for loop.
Ethan ended up writing some stand-alone code to handle the particular problem we are working on. However, I wanted to ask if it would be possible to modify bilby to allow for parallel likelihood evaluations using arrays of parameter values. I think our application is just one example of a class of problems (for example, hierarchical inference and selection effects) where this feature will be very helpful. I can imagine that there are samplers that could take advantage of this parallel structure as well.
Would this be hard to implement?Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/251GW-specific result object2019-01-24T05:36:40ZGregory Ashtongregory.ashton@ligo.orgGW-specific result objectIn #230, @charlie.hoy suggested adding the approximant to the result object and that is a good idea. More generally, I can imagine there being a number of CBC-specific information we'd like to include and also GW-specific methods we'd li...In #230, @charlie.hoy suggested adding the approximant to the result object and that is a good idea. More generally, I can imagine there being a number of CBC-specific information we'd like to include and also GW-specific methods we'd like the result object to have (for example, a `plot_skymap` method).
Keeping with the 1st amendment, separation of core and gw, this will require a special "bilby.gw.GWResult" object to be created which inherits from `bilby.core.Result`, but adds the additional data to store and new methods.
This would make a good issue for someone to pursue if you want to get to grips with the internals of the bilby results classes.Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/244import bilby fails out-of-the-box due to matplotlib backend issues2019-04-23T06:24:21ZDuncan Macleodduncan.macleod@ligo.orgimport bilby fails out-of-the-box due to matplotlib backend issuesTo reproduce (on macOS):
```shell
python -m virtualenv bilbyenv
./bilbyenv/bin/python -m pip install bilby
./bilbyenv/bin/python -c "import bilby"
```
The error presents as
```pytb
/Users/duncan/tmp/./bilbyenv/bin/../lib/python3.6/sit...To reproduce (on macOS):
```shell
python -m virtualenv bilbyenv
./bilbyenv/bin/python -m pip install bilby
./bilbyenv/bin/python -c "import bilby"
```
The error presents as
```pytb
/Users/duncan/tmp/./bilbyenv/bin/../lib/python3.6/site.py:165: DeprecationWarning: 'U' mode is deprecated
f = open(fullname, "rU")
13:10 bilby INFO : Running bilby version: 0.3.3:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/Users/duncan/tmp/bilbyenv/lib/python3.6/site-packages/bilby/__init__.py", line 21, in <module>
from . import core, gw, hyper
File "/Users/duncan/tmp/bilbyenv/lib/python3.6/site-packages/bilby/core/__init__.py", line 2, in <module>
from . import likelihood, prior, result, sampler, utils
File "/Users/duncan/tmp/bilbyenv/lib/python3.6/site-packages/bilby/core/result.py", line 6, in <module>
import corner
File "/Users/duncan/tmp/bilbyenv/lib/python3.6/site-packages/corner/__init__.py", line 37, in <module>
from .corner import corner, hist2d, quantile
File "/Users/duncan/tmp/bilbyenv/lib/python3.6/site-packages/corner/corner.py", line 7, in <module>
import matplotlib.pyplot as pl
File "/Users/duncan/tmp/bilbyenv/lib/python3.6/site-packages/matplotlib/pyplot.py", line 2374, in <module>
switch_backend(rcParams["backend"])
...
File "/Users/duncan/tmp/bilbyenv/lib/python3.6/site-packages/matplotlib/backends/qt_compat.py", line 165, in <module>
raise ImportError("Failed to import any qt binding")
ImportError: Failed to import any qt binding
```
I think the fix is to update `bilby.core.results` to either call `matplotlib.use('agg')` _before_ `import matplotlib.pyplot`:
```diff
diff --git a/bilby/core/result.py b/bilby/core/result.py
index df4374b..ac55d84 100644
--- a/bilby/core/result.py
+++ b/bilby/core/result.py
@@ -1,12 +1,16 @@
import os
from distutils.version import LooseVersion
+from collections import OrderedDict, namedtuple
+
import numpy as np
import deepdish
import pandas as pd
-import corner
+
import matplotlib
+matplotlib.use('agg')
+
+import corner
import matplotlib.pyplot as plt
-from collections import OrderedDict, namedtuple
from . import utils
from .utils import logger, infer_parameters_from_function
```
I can happily post this patch as a merge request.Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/239Vary the cosmology used2019-02-20T04:57:44ZCarl-Johan HasterVary the cosmology usedAt the moment, all the cosmological conversions in `bilby/gw/conversion.py` default to using the `astropy.cosmology.Planck15` cosmological parameters. There should be an option to choose a different cosmology, either from the ones avalia...At the moment, all the cosmological conversions in `bilby/gw/conversion.py` default to using the `astropy.cosmology.Planck15` cosmological parameters. There should be an option to choose a different cosmology, either from the ones avaliable through Astropy or by defining your own (I'd suggest using the infrastructure from Astropy's [FlatLambdaCDM](http://docs.astropy.org/en/stable/api/astropy.cosmology.FlatLambdaCDM.html#astropy.cosmology.FlatLambdaCDM), or a more general [Cosmology classes avaliable](http://docs.astropy.org/en/stable/cosmology/index.html#classes))Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/142Add Multivariate Gaussian Mixture Model as prior2019-04-24T08:20:55ZMatthew PitkinAdd Multivariate Gaussian Mixture Model as priorIt _may_ be useful to have a multivariate Gaussian Mixture Model as a prior option (this would encompass just having a multivariate Gaussian prior with just one mode).It _may_ be useful to have a multivariate Gaussian Mixture Model as a prior option (this would encompass just having a multivariate Gaussian prior with just one mode).Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/104`InterferometerData` proposal2018-06-20T22:51:08ZGregory Ashtongregory.ashton@ligo.org`InterferometerData` proposal@paul\-lasky @colm.talbot @moritz.huebner
In the spirit of working next week on cleaning up our open data handling and also detectors.py to see where the bugs live I have a suggestion I'd like to run past you all (I was just thinking a...@paul\-lasky @colm.talbot @moritz.huebner
In the spirit of working next week on cleaning up our open data handling and also detectors.py to see where the bugs live I have a suggestion I'd like to run past you all (I was just thinking about it over coffee and wanted to get it on paper before I forgot - we can discuss it in person next week).
Could we add a `InterferomerStrainData` class with something like the following attributes:
* frequency_domain_strain
* time_domain_strain
* frequencies
* times
* epoch (may be better named - segment_start_time)
* duration (or segment_duration)
* detector name
And something like the following methods
* set_from_psd
* set_from_frame_file
The basic idea is take what is currently done in `Interferometer.set_data` and make it a class.
At the same time, it would be good to rename `Interferometer.data` to ` Interferometer.strain_data`, which would be an instance of the above class. This would (a) make it clear that `data` is the `strain_data` and (b) mean that references to the `frequencies` etc would be `Interferometer.strain_data.frequencies` which identifies them as the 'frequencies of the strain data' and not, say, of the PSD or anything else. Similarly, it should simplify cases when you have time-series and frequency series as you can just call which ever you want and `InterferometerStrainData` will have both.
A second reason to do this is that one could imagine (in the future) having `InterferometerAuxillaryData` also be fed into the likelihood (or just for some other use).
Here are what I think are the basic steps to do this
* [x] Write the class and methods - move logic from `set_data` to the new class
* [x] Rewrite set_data to just pass the information into InterferometerStrainData
* [ ] ~~Turn the 'real data processing' steps into methods of `InterferometerStrainData` (e.g. `download_open_data(), filter_data()`, etc~~
* [x] Rewrite the likelihood to not call `interferometer.data`, but `interferometer.strain_data`
* [x] Move plotting tools to a method of this new class and remove duplicated plotting code
* [x] Check through the `get_interferometer_with...` functions to move logic which belongs in the new class into the new class.
This would then supersede #20 as it would do that and more.
What do people think? Ideas/suggestions welcome.FutureGregory Ashtongregory.ashton@ligo.orgGregory Ashtongregory.ashton@ligo.orghttps://git.ligo.org/lscsoft/bilby/-/issues/93Add Occam factor calculation2018-07-03T03:51:12ZGregory Ashtongregory.ashton@ligo.orgAdd Occam factor calculationAdd a function to estimate the Occam factor for a given fit.Add a function to estimate the Occam factor for a given fit.FutureGregory Ashtongregory.ashton@ligo.orgGregory Ashtongregory.ashton@ligo.orghttps://git.ligo.org/lscsoft/bilby/-/issues/61Priors class2018-06-19T10:46:34ZColm Talbotcolm.talbot@ligo.orgPriors classIf we have a `Priors` class that has attributes which are `Prior` objects it will allow us to naturally create predefined sets of priors.
I also think this will make it much more convenient to define correlated priors in the future whic...If we have a `Priors` class that has attributes which are `Prior` objects it will allow us to naturally create predefined sets of priors.
I also think this will make it much more convenient to define correlated priors in the future which we may want for e.g., masses.
I see this as allowing the user to type
```python
priors = tupak.prior.BBHPriors(trigger_time=trigger_time)
```
There would be a bunch of natural keyword arguments to define specific priors to use for specific parameters.
Thoughts?FutureMoritz HuebnerMoritz Huebnerhttps://git.ligo.org/lscsoft/bilby/-/issues/536plot_waveform_posterior uses non representative samples2020-12-23T06:17:41ZMoritz Huebnerplot_waveform_posterior uses non representative samplesThe following discussion from !817 should be addressed:
- [x] @avi.vajpeyi started a [discussion](https://git.ligo.org/lscsoft/bilby/-/merge_requests/817#note_185464): (+3 comments)
> While working on this, I noticed that if `n_sa...The following discussion from !817 should be addressed:
- [x] @avi.vajpeyi started a [discussion](https://git.ligo.org/lscsoft/bilby/-/merge_requests/817#note_185464): (+3 comments)
> While working on this, I noticed that if `n_samples` is passed to `plot_waveform_posterior` then n samples from the top of the posterior data frame are used (the samples with the lowest LogL).
>
> Would it be better to use the n samples from the bottom of the data frame (the samples with the highest LogL)?
>
> Should I make an issue about this, or am I understanding something wrong?
I think it should take random samples. In any case, we should aim to fix this soon.Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/522Sanity_check_labels returns error when NoneType is in label keys2020-09-10T02:51:44ZSamson LeongSanity_check_labels returns error when NoneType is in label keysWhen a dictionary of parameters is passed to `result.plot_corner()`, if the dictionary contains a key that does not have a latex label (time_jitter in my case), sanity_check would raise `TypeError: argument of type 'NoneType' is not iter...When a dictionary of parameters is passed to `result.plot_corner()`, if the dictionary contains a key that does not have a latex label (time_jitter in my case), sanity_check would raise `TypeError: argument of type 'NoneType' is not iterable` because the latex label is a NoneType.
My current fix is to add a line in `get_latex_labels_from_parameter_keys` to swap all NoneType to 'None', like this:
> `latex_labels = ['None' if label is None else label for label in latex_labels]`Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/479Double check `theta_jn` and `iota` consistency in the docs2020-05-01T17:07:53ZGregory Ashtongregory.ashton@ligo.orgDouble check `theta_jn` and `iota` consistency in the docsIssue to resolve left over from !648Issue to resolve left over from !648Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/438CPNest resuming on HTCondor2020-05-14T12:53:24ZGregory Ashtongregory.ashton@ligo.orgCPNest resuming on HTCondorFutureColm Talbotcolm.talbot@ligo.orgColm Talbotcolm.talbot@ligo.orghttps://git.ligo.org/lscsoft/bilby/-/issues/424Make sure all conditional priors can draw multiple samples at once2019-10-24T01:06:23ZMoritz HuebnerMake sure all conditional priors can draw multiple samples at onceThis involves a possible issue when you create a `ConditionalPriorDict` and use the `sample` method to draw multiple samples at once. This involves a possible issue when you create a `ConditionalPriorDict` and use the `sample` method to draw multiple samples at once. FutureMoritz HuebnerMoritz Huebner