bilby issueshttps://git.ligo.org/lscsoft/bilby/-/issues2018-05-15T02:50:36Zhttps://git.ligo.org/lscsoft/bilby/-/issues/66Clean up detector.py2018-05-15T02:50:36ZColm Talbotcolm.talbot@ligo.orgClean up detector.pyThere are a few functions that I think are not used any more:
- `fix`
- `parse_floats_to_fixed_priors`
- `parse_keys_to_parameters`
Can we just remove these?There are a few functions that I think are not used any more:
- `fix`
- `parse_floats_to_fixed_priors`
- `parse_keys_to_parameters`
Can we just remove these?FutureMoritz HuebnerMoritz Huebnerhttps://git.ligo.org/lscsoft/bilby/-/issues/71caching issue in GW150914 example2018-05-16T04:04:29ZPaul Laskycaching issue in GW150914 exampleAs previously discussed, getting open data on the cluster doesn't work properly when submitting a job through slurm. The temporary work-around (which is okay for 0.1, but should ultimately be fixed) is to run the code first from the com...As previously discussed, getting open data on the cluster doesn't work properly when submitting a job through slurm. The temporary work-around (which is okay for 0.1, but should ultimately be fixed) is to run the code first from the command line so that the data gets downloaded, and then submit a job through slurm which uses the cached data. There is a problem with this now that there is no V1 data, but when the code is submitted through slurm, it uses the cached data for L1 and H1, then tries to search for V1 data which returns an error.
Not sure of the fix, but is it worth just saying that, if one set of data is cached, then don't look for any more data?FutureGregory Ashtongregory.ashton@ligo.orgGregory Ashtongregory.ashton@ligo.orghttps://git.ligo.org/lscsoft/bilby/-/issues/46Make plots of inclination posteriors return cos(iota) by default2018-05-25T12:53:47ZMarcus Edward Lower BScMake plots of inclination posteriors return cos(iota) by defaultPlots of inclination angle posteriors should give plots of cos(iota) rather than just iota. As iota is sampled from arcos(-1) to arcos(1) the resulting posterior distributions end up looking somewhat dubious.
For example, here's a plot ...Plots of inclination angle posteriors should give plots of cos(iota) rather than just iota. As iota is sampled from arcos(-1) to arcos(1) the resulting posterior distributions end up looking somewhat dubious.
For example, here's a plot of the posteriors as they would appear at the moment:
![bad](/uploads/171f4392f1d19a49c9506bc0b6f55e87/bad.png)
And here's the same posteriors after taking cos(iota):
![good](/uploads/29518adbde875ba2b5f5a055ee76e284/good.png)Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/65Add profiling scripts2018-05-28T03:04:15ZGregory Ashtongregory.ashton@ligo.orgAdd profiling scriptsAdd scripts to profile the code and figure out the bottle necks.Add scripts to profile the code and figure out the bottle necks.FutureGregory Ashtongregory.ashton@ligo.orgGregory Ashtongregory.ashton@ligo.orghttps://git.ligo.org/lscsoft/bilby/-/issues/101Check Windows compatibility2018-06-19T07:36:33ZGregory Ashtongregory.ashton@ligo.orgCheck Windows compatibilityIf easily fixed, fix it. Otherwise suggest a guide on setting up a VMIf easily fixed, fix it. Otherwise suggest a guide on setting up a VMFutureGregory Ashtongregory.ashton@ligo.orgGregory Ashtongregory.ashton@ligo.orghttps://git.ligo.org/lscsoft/bilby/-/issues/20Use gwpy for all handling of time and frequency series2018-06-19T10:43:03ZGregory Ashtongregory.ashton@ligo.orgUse gwpy for all handling of time and frequency seriesCould we change all frequency_array and time_array handling to use `gwpy.TimeSeries`
This would simply a lot of the code. As an example, this piece of code downloads the open data into a time series and takes an FFT turning it into a `F...Could we change all frequency_array and time_array handling to use `gwpy.TimeSeries`
This would simply a lot of the code. As an example, this piece of code downloads the open data into a time series and takes an FFT turning it into a `FrequencySeries` object.
```python
ldata = TimeSeries.fetch_open_data('L1', 1126259446, 1126259478)
ldata_FFT = ldata.fft()
```
The `TimeSeries` and `FrequencySeries` object contain information about the sampling frequency and more. Realistically, we could replace much of `nfft` and other things that are being passed around and we get all the filtering magic which comes for free. Is there any reason not to do this?Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/22Allow for different sampling parameters to prior2018-06-19T10:44:57ZGregory Ashtongregory.ashton@ligo.orgAllow for different sampling parameters to prior@eric.thrane suggested people may want to have a prior on chirp mass and mass ratio instead of mass 1 and mass 2. Is there a nice way to make this a general way to implement this within the current framework?@eric.thrane suggested people may want to have a prior on chirp mass and mass ratio instead of mass 1 and mass 2. Is there a nice way to make this a general way to implement this within the current framework?Futurehttps://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/83Create html/pdf documentation2018-06-20T00:00:39ZGregory Ashtongregory.ashton@ligo.orgCreate html/pdf documentationFutureGregory Ashtongregory.ashton@ligo.orgGregory Ashtongregory.ashton@ligo.orghttps://git.ligo.org/lscsoft/bilby/-/issues/44Gaussian noise returns garbage below PSD fmin2018-06-20T12:56:29ZSylvia BiscoveanuGaussian noise returns garbage below PSD fmin@nikhil.sarin and I discovered that below the minimum frequency in the PSD file passed to `gaussian_noise`, the function returns garbage. The safest fix is to just cut these extra frequencies so that the minimum frequency returned corres...@nikhil.sarin and I discovered that below the minimum frequency in the PSD file passed to `gaussian_noise`, the function returns garbage. The safest fix is to just cut these extra frequencies so that the minimum frequency returned corresponds to the PSD fmin.FutureSylvia BiscoveanuSylvia Biscoveanuhttps://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/19Create testsuite for the project2018-06-21T00:47:07ZMoritz HuebnerCreate testsuite for the projectAs the project is maturing, it will eventually be necessary to write more and more tests. The purpose of unit tests is to assure that every part of the software works as it is designed. Writing unit tests helps you to make sure that you ...As the project is maturing, it will eventually be necessary to write more and more tests. The purpose of unit tests is to assure that every part of the software works as it is designed. Writing unit tests helps you to make sure that you have not implemented buggy code, and assures that you will get notified if you change code that breaks a test.
Unit tests should fail if **either** you have introduced buggy code, in which case you should rewrite your code, or if there have been changes in the code requirements, i.e. the code is now *supposed* to do something different compared to what it did before. In the latter case the tests should be rewritten to reflect the new code requirements.
It is pretty clear that writing tests right at the start is hard because we are still changing the API all the time.
If you haven't written unit tests before, it isinstructive to look up some short guides into unit testing in general(e.g. https://esj.com/Articles/2012/09/24/Better-Unit-Testing.aspx?Page=1 or https://fullstack.industries/blog/five-principles-of-unit-testing/).
Unit tests should *ideally* test the entire functionality of the programme. However, it may be hard to cover everything, especially within the scientific context some things just end up being hard to test. If you want to have a look at what simple tests should look like in our case, then you can have a look at `parameter_tests.py`, which currently runs 16 different tests on the Parameter class.
@colm.talbot @paul-lasky @gregory.ashton @sylvia.biscoveanuFuturehttps://git.ligo.org/lscsoft/bilby/-/issues/125Add `start_time` for the `time_array` in `WaveformGenerator`2018-06-27T04:43:28ZMoritz HuebnerAdd `start_time` for the `time_array` in `WaveformGenerator`Currently this is 0 by default. I ran into some issues with `NRSur7dq2` because it uses a different convention.Currently this is 0 by default. I ran into some issues with `NRSur7dq2` because it uses a different convention.FutureMoritz HuebnerMoritz Huebnerhttps://git.ligo.org/lscsoft/bilby/-/issues/112Turn the 'real data processing' steps into methods of InterferometerStrainDat...2018-07-03T02:50:24ZGregory Ashtongregory.ashton@ligo.orgTurn the 'real data processing' steps into methods of InterferometerStrainData (e.g. download_open_data(), filter_data(), etc)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/32Implement ra, dec, geocent_time, and psi by default in the waveform generator2018-07-04T01:49:44ZMoritz HuebnerImplement ra, dec, geocent_time, and psi by default in the waveform generatorra, dec, geocent_time, and psi should appear in any case in the waveform generator because every signal is supposed to have these parameters.ra, dec, geocent_time, and psi should appear in any case in the waveform generator because every signal is supposed to have these parameters.FutureMoritz HuebnerMoritz Huebnerhttps://git.ligo.org/lscsoft/bilby/-/issues/69hyper-parameter estimation likelihood2018-07-06T05:33:55ZEric Thranehyper-parameter estimation likelihoodSeveral people (@colm.talbot, @gregory.ashton, @grant.meadors) have urgent need to do hyper-parameter estimation with tupak. There are multiple applications, but we should create a single function that can be adapted to all of these appl...Several people (@colm.talbot, @gregory.ashton, @grant.meadors) have urgent need to do hyper-parameter estimation with tupak. There are multiple applications, but we should create a single function that can be adapted to all of these applications.
I recommend that we create a python function to do this. The inputs should include
* The number of events.
* Lists of posterior samples.
* List of parameters described by hyper-parameters.
* List of hyper-parameters.
* The prior that was used to generate the posterior samples.
* The conditional prior.
* [x] Create general tupak.hyper-pe function.
@sylvia.biscoveanu FutureGregory Ashtongregory.ashton@ligo.orgGregory Ashtongregory.ashton@ligo.orghttps://git.ligo.org/lscsoft/bilby/-/issues/124Allow user specified frequency cutoffs to allow for unbiased inspiral-only PE2018-07-17T14:56:57ZMarcus Edward Lower BScAllow user specified frequency cutoffs to allow for unbiased inspiral-only PENot sure if there this is already a feature, or something that is already being thought about.
Using inspiral-only waveforms for binary black hole PE can induce a bias in the recovered parameters due to the unphysical cutoff in the GW ...Not sure if there this is already a feature, or something that is already being thought about.
Using inspiral-only waveforms for binary black hole PE can induce a bias in the recovered parameters due to the unphysical cutoff in the GW signal (as per Mandel et al. (2014): https://arxiv.org/abs/1404.2382).
This bias can be avoided by introducing a cutoff in the data and templates at some frequency below the ISCO of the event being analysed.
i.e:
![ASD_1](/uploads/a4e324d5ebca352462098af97eddec0c/ASD_1.png)Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/48Include eccentricity as a searchable parameter (but defaults to zero) + log-u...2018-08-02T08:59:26ZMarcus Edward Lower BScInclude eccentricity as a searchable parameter (but defaults to zero) + log-uniform priorsEccentricity should be a parameter that is allowed to be searched over, with the default value being zero unless otherwise specified. Values of eccentricity should also be sampled in log-space.Eccentricity should be a parameter that is allowed to be searched over, with the default value being zero unless otherwise specified. Values of eccentricity should also be sampled in log-space.FutureMarcus Edward Lower BScMarcus Edward Lower BSchttps://git.ligo.org/lscsoft/bilby/-/issues/90mimic LALInference's proposal distribution2018-09-14T02:54:14ZPaul Laskymimic LALInference's proposal distributionFrom @rory\-smith: '... off-the-shelf samplers aren't well tuned to GW problems'.
* [ ] implement proposal distributions similar to LALInferenceFrom @rory\-smith: '... off-the-shelf samplers aren't well tuned to GW problems'.
* [ ] implement proposal distributions similar to LALInferenceFutureRory SmithRory Smith