[AstroPy] [ANN] Nestle: Nested sampling
Wolfgang Kerzendorf
wkerzendorf at gmail.com
Sat Oct 10 11:12:33 EDT 2015
Hi Anne,
We are facing a similar problem of having a likelihood with 15 dimensions
(in the simplest form) with an evaluation time of 60 - 100 seconds.
MultiNest can be run in parallel via MPI and we did this - however to no
avail as of yet. For now we employ different maximum likelihood methods
with some success.
Cheers,
Wolfgang
--
Dr. Wolfgang E Kerzendorf
ESO Fellow
European Southern Observatory
Karl-Schwarzschild Str. 2, 85748
Garching bei Muenchen, Germany
On Fri, Oct 9, 2015 at 6:26 PM Anne Archibald <archibald at astron.nl> wrote:
> Hi Scott,
>
> In fact I had parallel tempering working for a while, as a help to the
> minimization. In one sense it's relatively cheap: since the
> different-temperature chains are run in parallel, you can throw more
> walkers and hence more cores at the problem. But it suffers from something
> of the same problem as nested sampling: if you want to explore the whole
> space, you need much higher temperatures than the base one, and the
> temperature spacing can't be more than about 2^(1/n_parameters). So you
> need a bazillion chains. That said, I don't know how much actual
> probability the far-away parts of the space contribute to the integral, or
> how to evaluate how well parallel tempering is working. For context,
> though, the problem as implemented has two identical optima: a cos i and -a
> cos i are equivalent until I put in the full astrometry. But parallel
> tempering didn't find the other optimum.
>
> For the problem of testing GR versus not-GR specifically, we might be able
> to get away with using priors based on the Newtonian fit - it's the same
> data, so that's maybe not quite kosher, but it does very dramatically
> reduce the prior volume, maybe to a manageable level.
>
> How is the PINT BTX model? I have a test problem - 30000 data points, two
> sinusoids - that should produce similar prior/posterior constraints, but it
> doesn't have that many parameters. If PINT BTX could be used, that would
> give me a slightly more realistic problem. I could use the
> two-noninteracting-Keplerian model I have but it's actually even slower to
> evaluate than the integrator (don't ask). Anyway, the way to answer these
> questions about what parallel tempering and nested sampling can do is to
> run some tests with a much cheaper log-likelihood.
>
> Anne
>
> On Fri, Oct 9, 2015 at 5:59 PM Scott Ransom <sransom at nrao.edu> wrote:
>
>> Hey Anne,
>>
>> Can you use parallel tempering MCMC to estimate the evidence for
>> hypothesis testing? Or will that work terribly badly for us given the
>> dynamic range between prior to posterior?
>>
>> e.g. http://dan.iel.fm/emcee/current/user/pt/
>>
>> Scott
>>
>> On 10/08/2015 05:05 PM, Anne Archibald wrote:
>> > Hi Kyle,
>> >
>> > I am very interested in nestle as an alternative MCMC method for a
>> > project I'm working on (testing general relativity with pulsar timing
>> > observations of a triple system; see
>> > http://adsabs.harvard.edu/abs/2014Natur.505..520R for more). I was
>> > considering multinest but the ability to get "under the hood" is really
>> > valuable. I have several concerns with using the code; maybe you have
>> > the experience to point me in the right direction.
>> >
>> > The first concern is that my likelihood function is really slow
>> > (seconds). I have access to many cores, but each evaluation can only use
>> > one. So I'd like to enlist some parallelism in the MCMC algorithm. As
>> > written, nestle is purely sequential, but I can see several places
>> > parallelism is available. The first and easiest is when picking a new
>> > point to replace the worst: if this takes many tries, you could
>> > speculatively evaluate the function at many new candidate points and
>> > take the first acceptable one. Multinest is able to do this, and I can
>> > see how one might add it to the code here. The second possibility is
>> > suggested by your "update_interval" parameter. Until the family of
>> > ellipsoids is updated, all new points are being generated from the same
>> > distribution, so the evaluation of their likelihoods can be carried out
>> > in parallel. This guarantees at least a factor update_interval worth of
>> > parallelism, which might be worth it even for expensive likelihood
>> > evaluations. Implementation would maintain a list of N (~ number of
>> > cores) Futures representing evaluations drawn from the current set of
>> > ellipsoids; every time the code needs a new point it waits for the first
>> > Future to finish and gets the coordinates and log-likelihood from that,
>> > then creates another Future for later. When the ellipsoids need to be
>> > changed, all unused Futures can be cancelled. The result should be
>> > statistically identical to the current algorithm, though it sometimes
>> > uses extra RNG calls, so the actual call sequence won't be the same (and
>> > will depend on N but nothing else).
>> >
>> > The second concern is that I'm worried my problem is going to take
>> > forever with nested sampling. It's a somewhat high-dimensional problem -
>> > 20-30 parameters - and the change in parameter volume from prior to
>> > posterior is staggering: while the prior is a bit fuzzy, our knowledge
>> > of (say) the inner orbital period goes from "about 1.6 days" to
>> > "1.629401788(5) days"; many other parameters are similarly constrained.
>> > Since nested sampling relies on gradually shrinking ellipses from the
>> > entire space down to the target region, I worry that it will take a very
>> > large number of steps (if the ellipse's volume shrinks by a factor 1.2
>> > each time, that's ~3000 steps). This appears worryingly supported by a
>> > numerical experiment I am running with a fast likelihood function that
>> > nevertheless puts very tight constraints on the result.
>> >
>> > The third concern is about covariances. Of course ellipses are intended
>> > to enclose potentially very skinny error regions, but I ran into
>> > problems where my error region was so narrow that representing it with a
>> > covariance matrix ran into matrix numerical headaches. I have
>> > analytically marginalized out the worst offenders, but even the simple
>> > problem that my parameters can be constrained on very different scales -
>> > a sin i is known about a thousand times better than a cos i - can wreck
>> > matrix algorithms. I guess I have to try this and see whether problems
>> > arise.
>> >
>> > Currently I am working with emcee, which has its drawbacks, but can use
>> > parallelism (to evaluate likelihoods for many walkers at once) and is
>> > fairly robust against covariances (the point coordinates themselves are
>> > used to generate candidates as linear combinations). But since I'm
>> > trying to test a hypothesis - GR is better than not-GR - it sure would
>> > be nice to use a tool that supports hypothesis testing!
>> >
>> > Thanks,
>> > Anne
>> >
>> > On Tue, Sep 29, 2015 at 8:10 PM Kyle Barbary <kylebarbary at gmail.com
>> > <mailto:kylebarbary at gmail.com>> wrote:
>> >
>> > Yes, possibly! Nestle currently implements the basic MultiNest
>> > method, but doesn't implement later improvements such as importance
>> > reweighting or polychord. I'm open to contributions and
>> > improvements. (But be mindful of reading the MultiNest source code
>> > due to licensing issues!)
>> >
>> > Best,
>> > -- Kyle
>> >
>> > On Tue, Sep 29, 2015 at 1:03 PM, Johann Cohen-Tanugi
>> > <johann.cohentanugi at gmail.com <mailto:johann.cohentanugi at gmail.com
>> >>
>> > wrote:
>> >
>> > likewise!
>> > Any prospect toward the polychord extension? See
>> > http://arxiv.org/abs/1506.00171v1
>> > cheers,
>> > Johann
>> >
>> >
>> > On 09/29/2015 10:30 AM, Wolfgang Kerzendorf wrote:
>> >> HI Kyle,
>> >>
>> >> Very nice. I'll definitely have a look at that.
>> >>
>> >> Cheers,
>> >> Wolfgang
>> >> --
>> >> Dr. Wolfgang E Kerzendorf
>> >> ESO Fellow
>> >> European Southern Observatory
>> >> Karl-Schwarzschild Str. 2, 85748
>> >> Garching bei Muenchen, Germany
>> >>
>> >> On Tue, Sep 29, 2015 at 6:09 AM Kyle Barbary
>> >> <<mailto:kylebarbary at gmail.com>kylebarbary at gmail.com
>> >> <mailto:kylebarbary at gmail.com>> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I'm pleased to announce the initial release of Nestle, a
>> >> small Python package for nested sampling. ("Nestle" rhymes
>> >> with "wrestle".) Nested sampling is a statistical
>> >> technique for parameter estimation and model comparison,
>> >> commonly used in cosmology. We've been using it in the
>> >> sncosmo package and have found it to be a robust global
>> >> optimizer in addition to its more typically cited benefits.
>> >>
>> >> Nestle implements an algorithm similar to that used in the
>> >> MultiNest software, but in an open-source (MIT) licensed
>> >> and easy-to-install (pure Python) package. (It was written
>> >> based only on the literature, not the MultiNest source
>> >> code.) In addition to this algorithm, Nestle also
>> >> implements the "classic" nested sampling algorithm and the
>> >> "single ellipsoid" algorithm.
>> >>
>> >> Nestle depends on only numpy and (optionally) scipy and
>> >> supports both Python 3 and Legacy Python (formerly known
>> >> as Python 2).
>> >>
>> >> docs:
>> >> <http://kbarbary.github.io/nestle>
>> http://kbarbary.github.io/nestle
>> >> source:
>> >> <http://github.com/kbarbary/nestle>
>> http://github.com/kbarbary/nestle
>> >>
>> >> I'd appreciate any feedback on this initial release,
>> >> particularly about application to real-world problems and
>> >> comparisons with results from MultiNest. Thanks!
>> >>
>> >> - Kyle
>> >> _______________________________________________
>> >> AstroPy mailing list
>> >> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> >> https://mail.scipy.org/mailman/listinfo/astropy
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> AstroPy mailing list
>> >> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> >> https://mail.scipy.org/mailman/listinfo/astropy
>> >
>> >
>> > _______________________________________________
>> > AstroPy mailing list
>> > AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> > https://mail.scipy.org/mailman/listinfo/astropy
>> >
>> >
>> > _______________________________________________
>> > AstroPy mailing list
>> > AstroPy at scipy.org <mailto:AstroPy at scipy.org>
>> > https://mail.scipy.org/mailman/listinfo/astropy
>> >
>> >
>> >
>> > _______________________________________________
>> > AstroPy mailing list
>> > AstroPy at scipy.org
>> > https://mail.scipy.org/mailman/listinfo/astropy
>> >
>>
>> --
>> Scott M. Ransom Address: NRAO
>> Phone: (434) 296-0320 520 Edgemont Rd.
>> email: sransom at nrao.edu Charlottesville, VA 22903 USA
>> GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151010/335b9841/attachment.html>
More information about the AstroPy
mailing list