bfarr / kombine Goto Github PK

View Code? Open in Web Editor NEW

34.0 34.0 25.0 11.28 MB

A kernel-density-based, embarrassingly parallel ensemble sampler

Home Page: http://pages.uoregon.edu/bfarr/kombine

License: MIT License

Python 100.00%

kombine's People

Contributors

Stargazers

Watchers

kombine's Issues

windowed_acceptance_rate() throws numpy error

If no window size is passed to sampler.windowed_acceptance_rate(), then np.empty() raises an error at L703.

TypeError: 'numpy.float64' object cannot be interpreted as an integer

The problem is caused at L701, because the integer division returns a float, e.g. 20.0, not an int. The right-hand-side of the integer division is a float, so the whole expression returns a float.

window = 20 * 1//np.mean(self.acceptance[-1])

In my python shell I see:

>>> import numpy as np
>>> type(1//np.mean(1))
<class 'numpy.float64'>
>>> type(1//0.1)
<class 'float'>

versions

Python 3.6.7 :: Anaconda, Inc.
numpy 1.16.2

Bug in burn-in

There seems to be a bug in the burn-in phase that we've found when testing an example with CosmoSIS:

If the acceptance rate during burn-in is zero an exception is raised:

File "/Users/jaz/src/cosmosis/bin/cosmosis", line 168, in <module>
  main(args)
File "/Users/jaz/src/cosmosis/bin/cosmosis", line 113, in main
  sampler.execute()
File "/Users/jaz/src/cosmosis/cosmosis/samplers/kombine/kombine_sampler.py", line 70, in execute
  results = self.ensemble.burnin(self.p0, update_interval=self.update_interval)
File "/Users/jaz/src/cosmosis/conda/lib/python2.7/site-packages/kombine/sampler.py", line 175, in burnin
  test_interval = int(step_size*1./last_acc_rate)
OverflowError: cannot convert float infinity to integer

The first three levels are all in CosmoSIS - only the last is from Kombine.

MPI failures using mpipool.MPIPool

I've been comparing emcee and kombine on a cluster using MPI to distribute the sampling and have been running into some issues with kombine that don't happen with emcee (purely related to parallelization and not the algorithms themselves!).

I'm using the master branch of mpipool for MPI and running on Stampede (one of the NSF xsede machines). I'm using loadbalance=True because I'm using more walkers than compute cores (typically 512 walkers and 128 cores). With emcee, this works fine. With kombine, I get the following traceback:

Traceback (most recent call last):
  File "mcmc-troup.py", line 383, in <module>
    overwrite=args.overwrite)
  File "mcmc-troup.py", line 176, in main
    pool = get_pool(mpi=mpi, loadbalance=True)
  File "/work/03470/tg827691/anaconda/envs/ebak/lib/python3.5/site-packages/gala/util.py", line 59, in get_pool
    pool.wait()
  File "/work/03470/tg827691/projects/mpipool/mpipool/core.py", line 73, in wait
    task = self.comm.recv(source=0, tag=MPI.ANY_TAG, status=status)
  File "MPI/Comm.pyx", line 1192, in mpi4py.MPI.Comm.recv (src/mpi4py.MPI.c:106889)
  File "MPI/msgpickle.pxi", line 292, in mpi4py.MPI.PyMPI_recv (src/mpi4py.MPI.c:43053)
  File "MPI/msgpickle.pxi", line 143, in mpi4py.MPI.Pickle.load (src/mpi4py.MPI.c:41248)
_pickle.UnpicklingError

If I reduce the number of walkers (to ~200), the UnpicklingError goes away, which leads me to also suspect that it is somehow related to MPI buffer size or message size limits. I'll take a look at the kombine source again to see if there is any obvious issue, but I'm an MPI novice so any support would be appreciated!

This seems to be related to @dfm's gist -- wondering if he ever found a solution? Also pinging @juliohm.

update PyPI release

Current verison on PyPI does not have the small fix for scipy>=1.0 changing the location of logsumexp function

How to cite this

How to reproduce:

Use this package. Create good results. Write them down. When trying to cite the paper, the process fails.

Is there an academic reference?

Thanks for this!

Add documentation

Having thrown kombine to the wolves by presenting it's impressive capabilities at the #LGAstat conference, it would be fantastic if kombine had some (sphinx?) documentation describing basic use, background, and API. (Perhaps the astropy affiliated package template can be of use here?)

cc @bfarr @adrn

Expose proposal density

Let the user provide a KDE, or anything any object with a draw method that returns a log-proposal-density when called.

Kombine version of pypi out of order

On pypi there is still a 1.0 version that is older than those in the 0.8 series. Could this be deactivated or the current released version advance to beyond 1.0? For the time being it is not possible to depend on the latest version in a normal way (by specifying a minimum version).

Conflict with latest release of scipy

Hi @bfarr, our bilby CI tests have picked up a conflict between kombine and the latest scipy (v1.7.0) release. The test works under scipy v1.5.0 (I haven't tested releases in between).

Here is the traceback for debugging. It looks like it is the automatic burn-in process causing the issue.

Traceback (most recent call last):
  File "test/integration/sampler_run_test.py", line 94, in test_run_kombine
    _ = bilby.run_sampler(
  File "/home/greg/bilby/bilby/core/sampler/__init__.py", line 186, in run_sampler
    result = sampler.run_sampler()
  File "/home/greg/bilby/bilby/core/sampler/kombine.py", line 138, in run_sampler
    self.sampler.burnin(**self.sampler_burnin_kwargs)
  File "/home/greg/software/anaconda3/envs/bilby/lib/python3.8/site-packages/kombine/sampler.py", line 262, in burnin
    if self.consistent_acceptance_rate(window_size=step_size*act, critical_pval=critical_pval):
  File "/home/greg/software/anaconda3/envs/bilby/lib/python3.8/site-packages/kombine/sampler.py", line 743, in consistent_acceptance_rate
    _, p_val = chisquare(nacc, expected_freqs)
  File "/home/greg/software/anaconda3/envs/bilby/lib/python3.8/site-packages/scipy/stats/stats.py", line 6852, in chisquare
    return power_divergence(f_obs, f_exp=f_exp, ddof=ddof, axis=axis,
  File "/home/greg/software/anaconda3/envs/bilby/lib/python3.8/site-packages/scipy/stats/stats.py", line 6694, in power_divergence
    raise ValueError(msg)
ValueError: For each axis slice, the sum of the observed frequencies must agree with the sum of the expected frequencies to a relative tolerance of 1e-08, but the percent differences are:
0.14893617021276595

bfarr / kombine Goto Github PK

kombine's People

Contributors

Stargazers

Watchers

Forkers

kombine's Issues

versions

How to reproduce:

Recommend Projects

Recommend Topics

Recommend Org

Jobs