bilby issueshttps://git.ligo.org/lscsoft/bilby/-/issues2020-09-28T15:14:12Zhttps://git.ligo.org/lscsoft/bilby/-/issues/505Use NS weights for posterior plots and quantiles2020-09-28T15:14:12ZMatthew PitkinUse NS weights for posterior plots and quantilesIf working with the outputs of nested sampling code and we have the weights stored in the `Result` object we should allow the `plot_corner` function to use all the nested samples, but with weights applied (as is done in [dynesty](https:/...If working with the outputs of nested sampling code and we have the weights stored in the `Result` object we should allow the `plot_corner` function to use all the nested samples, but with weights applied (as is done in [dynesty](https://github.com/joshspeagle/dynesty/blob/master/dynesty/plotting.py#L968) and ultranest). This will reduce the sampling noise especially in the wings of the posteriors. We should also look at the dynesty [quantile](https://github.com/joshspeagle/dynesty/blob/master/dynesty/utils.py#L184) function, which will use the weights to work out quantiles, which again should reduce the random noise on the values.Futurehttps://git.ligo.org/lscsoft/bilby/-/issues/737Transitioning to sampler plugins2024-03-25T15:30:48ZMichael Williamsmichael.williams@ligo.orgTransitioning to sampler pluginsI've opened this issue to track changes that should be made as we migrate samplers out of the main code and into their own packages. Hopefully others can edit this as they identify things.
**Samplers**
We haven't agreed a policy for mo...I've opened this issue to track changes that should be made as we migrate samplers out of the main code and into their own packages. Hopefully others can edit this as they identify things.
**Samplers**
We haven't agreed a policy for moving the samplers, but I believe nessai will be the first, followed by pypolychord. As we decided on more samplers, we can add them here.
In order of decreasing priority:
- [ ] nessai
- [ ] pypolychord
**Examples**
Some examples may need updating because of the changes
- [ ] `examples/core_examples/alternative_samplers/linear_regression_pymc_custom_likelihood.py` (should be made if/when moving pymc)https://git.ligo.org/lscsoft/bilby/-/issues/730Follow-up from "Draft: Add support for sampler plugins"2024-02-23T15:30:45ZMichael Williamsmichael.williams@ligo.orgFollow-up from "Draft: Add support for sampler plugins"The following discussion from !1299 should be addressed:
- [x] @michael.williams started a [discussion](https://git.ligo.org/lscsoft/bilby/-/merge_requests/1299#note_928209): (+1 comment)
> Thinking about this in connection with b...The following discussion from !1299 should be addressed:
- [x] @michael.williams started a [discussion](https://git.ligo.org/lscsoft/bilby/-/merge_requests/1299#note_928209): (+1 comment)
> Thinking about this in connection with bilby_pipe, specifically the logic here: https://git.ligo.org/lscsoft/bilby_pipe/-/blob/master/bilby_pipe/job_creation/nodes/analysis_node.py#L125. As it stands, this can prevent samplers from being used out-of-the-box with bilby pipe unless you set `transfer-files=False`.
>
> What would folks think about adding one or two attributes to the sampler classes that specify the files and/or directories the sampler will create? Something like:
>
> ```
> expected_output_files = []
> expected_output_directories = []
> ```
> or a function that returns them based on the labels.
>
> bilby_pipe could then use these attributes to create the directories and placeholder files, rather than having to hard code things. It would then fall on the sampler plugins to maintain this rather than the bilby_pipe maintainers
>
> I'm happy to implement something like this in a separate MR if there's interest.Michael Williamsmichael.williams@ligo.orgMichael Williamsmichael.williams@ligo.orghttps://git.ligo.org/lscsoft/bilby/-/issues/722ptemcee parallelisation issue2024-01-29T05:15:48ZColm Talbotcolm.talbot@ligo.orgptemcee parallelisation issueA downstream user reported an issue with ptemcee on MacOS with parallelization.
I found that it works with the multiprocessing start method set to `fork`, which is a temporary workaround.
As a fix, we need to make sure the [`_sampling_...A downstream user reported an issue with ptemcee on MacOS with parallelization.
I found that it works with the multiprocessing start method set to `fork`, which is a temporary workaround.
As a fix, we need to make sure the [`_sampling_convenience_dump`](https://git.ligo.org/lscsoft/bilby/-/blob/master/bilby/core/sampler/base_sampler.py#L47) works with the [`LikePriorEvaluator`](https://git.ligo.org/lscsoft/bilby/-/blob/master/bilby/core/sampler/ptemcee.py#L1406).
An initial solution that seemed to work was to update the `LikePriorEvaluator` as
```python
def __init__(self):
from .base_sampler import _sampling_convenience_dump
self.periodic_set = False
self.dump = _sampling_convenience_dump
```
and then using `self.dump` rather than `_sampling_convenience_dump` throughout.
This might cause issues if `emcee/kombine/zeus` pass the `LikePriorEvaluator` through the multiprocessing pool.
See https://github.com/bandframework/Taweret/issues/53https://git.ligo.org/lscsoft/bilby/-/issues/716Time to remove polychord?2023-11-10T16:01:57ZColm Talbotcolm.talbot@ligo.orgTime to remove polychord?After reworking the test suite, we're still having [issues](https://git.ligo.org/lscsoft/bilby/-/jobs/3025662) with installing polychord because it has to be built from source.
I suggest that we begin the process of removing polychord a...After reworking the test suite, we're still having [issues](https://git.ligo.org/lscsoft/bilby/-/jobs/3025662) with installing polychord because it has to be built from source.
I suggest that we begin the process of removing polychord as a supported sampler. With the following process:
- remove it from the test suite ASAP.
- remove it from the package at the next major/minor release (presumably 2.3).
This would be the first time we've dropped support for a sampler, but I think it would be good to formalize that any supported sampler should be available from conda-forge.
Thoughts @gregory.ashton @michael.williams @sylvia.biscoveanu?https://git.ligo.org/lscsoft/bilby/-/issues/710Dynesty sampler unexpectedly closing all plots2023-11-09T21:08:29ZGitLab Support BotDynesty sampler unexpectedly closing all plotsI've noticed when I run bilby with either the dynesty or dynamic dynesty samplers, any plots I had open before calling run_sampler are closed. I think this may be caused by a few calls to matplotlib closing all figures (plt.close('all'))...I've noticed when I run bilby with either the dynesty or dynamic dynesty samplers, any plots I had open before calling run_sampler are closed. I think this may be caused by a few calls to matplotlib closing all figures (plt.close('all')) in the plot_current_state() function of the dynesty sampler. Would it be possible to change these so that they only close the figures created by running bilby, and not any other plots opened by other parts of a script?
Thanks!https://git.ligo.org/lscsoft/bilby/-/issues/537Bugs in reweighing samples2022-09-09T09:01:03ZKa-Lok LoBugs in reweighing samplesHi,
While trying to reweigh samples using the routine `bilby.core.result.reweight`, I encountered two bugs (in `bilby-v1.0.2`)
1. In `bilby.core.result.get_weights_for_reweighting`, it assumed that the label for each row in `result.pos...Hi,
While trying to reweigh samples using the routine `bilby.core.result.reweight`, I encountered two bugs (in `bilby-v1.0.2`)
1. In `bilby.core.result.get_weights_for_reweighting`, it assumed that the label for each row in `result.posterior` ranges from [0, len(result.posterior)-1] which is _not necessarily the case_ especially rejection sampling was used prior to calling this `get_weights_for_reweighting` function. This will cause index-out-of-bound error. The simplest fix would be to change in [L123 of bilby/core/result.py](https://git.ligo.org/lscsoft/bilby/-/blob/1.0.2/bilby/core/result.py#L123) from
```
for ii, sample in result.posterior.iterrows():
```
to
```
for ii, (_, sample) in enumerate(result.posterior.iterrows()):
```
and also changing [L174 of bilby/core/result.py](https://git.ligo.org/lscsoft/bilby/-/blob/1.0.2/bilby/core/result.py#L174)
from
```
return posterior[keep]
```
to
```
return posterior[keep].reset_index(drop=True)
```
2. It seems that the action of doing `convert_to_flat_in_component_mass_prior` does not commute with doing `bilby.core.result.get_weights_for_reweighting`. Doing reweighing before converting to flat in component mass prior yields no error but doing in the reverse order will yield an error saying that the key 'mass_1' is missing when the column actually exists. This is not desirable since `convert_to_flat_in_component_mass_prior` can be configured to run right after sampling, thus prohibiting reweighing of the samples in the future. This can be solved by properly assigning the component masses as one of the searched parameters and chirp mass and mass ratio being constrained in the result.search_parameter_keys and result.constraint_parameter_keys respectively. For example [starting from L67 of bilby/gw/prior.py](https://git.ligo.org/lscsoft/bilby/-/blob/1.0.2/bilby/gw/prior.py#L67) can be changed from
```
for key in ['chirp_mass', 'mass_ratio']:
priors[key] = Constraint(priors[key].minimum, priors[key].maximum, key, latex_label=priors[key].latex_label)
for key in ['mass_1', 'mass_2']:
priors[key] = Uniform(priors[key].minimum, priors[key].maximum, key, latex_label=priors[key].latex_label,
unit="$M_{\odot}$")
```
to
```
for key in ['chirp_mass', 'mass_ratio']:
priors[key] = Constraint(priors[key].minimum, priors[key].maximum, key, latex_label=priors[key].latex_label)
result.constraint_parameter_keys.append(key)
result.search_parameter_keys.remove(key)
for key in ['mass_1', 'mass_2']:
priors[key] = Uniform(priors[key].minimum, priors[key].maximum, key, latex_label=priors[key].latex_label,
unit="$M_{\odot}$")
result.search_parameter_keys.append(key)
result.constraint_parameter_keys.remove(key)
```
3.(?) Probably the function should be called `reweigh` instead of `reweight` but whatever
If people prefer, I can submit a merge request fixing issue 1 and 2 or it would be faster if the developers simply affect these simple changes.https://git.ligo.org/lscsoft/bilby/-/issues/517Improve signal handling2020-08-19T08:04:41ZColm Talbotcolm.talbot@ligo.orgImprove signal handlingCurrently, we set the signal handler in the `__init__` methods for the samplers, e.g., https://git.ligo.org/lscsoft/bilby/-/blob/master/bilby/core/sampler/dynesty.py#L176-178.
These typically lead to calling a checkpoint function which ...Currently, we set the signal handler in the `__init__` methods for the samplers, e.g., https://git.ligo.org/lscsoft/bilby/-/blob/master/bilby/core/sampler/dynesty.py#L176-178.
These typically lead to calling a checkpoint function which only really makes sense during sampling.
This leads to some weird behaviour if the signals come after the sampler finishes or before the setup is complete. I've noticed this when jobs are interrupted during parameter reconstruction.
I suggest that instead we should set up the handler immediately before launching the sampler and change them back after the sampling is done.
We may also want to look at having a specific handler for the parameter reconstruction in the GW case.https://git.ligo.org/lscsoft/bilby/-/issues/484sys.exit in jupyter2022-09-29T09:53:31ZColm Talbotcolm.talbot@ligo.orgsys.exit in jupyterI'm running into issues stopping jobs in Jupiter. When I interrupt `dynesty` it triggers a call to `sys.exit` which kills the kernel.
Maybe we should avoid calling `sys.exit` and instead raise a custom error that can be caught and then ...I'm running into issues stopping jobs in Jupiter. When I interrupt `dynesty` it triggers a call to `sys.exit` which kills the kernel.
Maybe we should avoid calling `sys.exit` and instead raise a custom error that can be caught and then the exit can be called by downstream users.