Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

No bounds update and fixed number of calls each iteration #431

Closed
ajw278 opened this issue Mar 15, 2023 · 12 comments
Closed

No bounds update and fixed number of calls each iteration #431

ajw278 opened this issue Mar 15, 2023 · 12 comments
Labels
bug this shouldn't be happening

Comments

@ajw278
Copy link

ajw278 commented Mar 15, 2023

** Dynesty version **
Installed the latest version of dynesty via pip for python 3.

Describe the bug
When running dynesty (either dynamic or static) the bounds only update once regardless of the update_interval, and the number of calls becomes fixed. This happens with a variety of different setups. I am working with very messy, multi-modal log-likelihood distribution which can be very negative (log L = -1 * several thousand in some cases).

Setup
I have run both dynamic and static version of dynesty, and tried different update_intervals etc. However, the bounds do not update, and the number of calls remains fixed for each iteration. The update interval is set to 500, and the bounds call is for 'multi' (I have also had problems with 'cube', but that's a separate issue).

I am running the following with:

nprocs=16 (but have tried other)
ndim = 16 (but have tried other)
dynamic = True (but have tried static)

`
pool=multiprocessing.Pool(processes=nprocs, initializer=set_globals, initargs=(dmc_, rstart, rend, distance_, res_cont_, priors, Ngauss))
pool.size = nprocs

if not os.path.isdir('dmaps'):
	os.makedirs('dmaps')


resume=False
if not load or not os.path.isfile('dmaps/'+filename+'.save'):
	print("Initiating new dynesty run...")
	if not dynamic:
		sampler = dnst.NestedSampler(log_prob, prior_transform, ndim,  nlive=nlive,  bound='multi',\
		update_interval=500,first_update={'min_ncall': 5000, 'min_eff': 25.}, pool=pool)
	else:
		sampler = dnst.DynamicNestedSampler(log_prob, prior_transform, ndim,  bound='multi',\
		update_interval=500,first_update={'min_ncall': 5000, 'min_eff': 25.}, pool=pool)
else:	

	print("Loading previous dynesty exploration...")

	sampler = dnst.NestedSampler.restore('dmaps/'+filename+'.save', pool=pool)
	resume=True

if run:
	print('Running dynesty...')
	if not dynamic:
		sampler.run_nested(maxiter=max_n,dlogz=0.1, checkpoint_file='dmaps/'+filename+'.save', resume=resume, maxcall=1000000)
	else:
		sampler.run_nested(maxiter=max_n,dlogz_init=0.1, nlive_init=nlive, nlive_batch=100,checkpoint_file='dmaps/'+filename+'.save',\
		 resume=resume,  maxiter_init=10000, maxiter_batch=1000, maxbatch=10,  use_stop=True,wt_kwargs={'pfrac': 0.0}, maxcall=1000000)

`

** Dynesty output **
It isn't crashing, but here is an example (in this case, nc is 36 for every iteration, but have seen other numbers).

This is what happens when eff < 25 % (the threshold I set):
iter: 2157 | batch: 0 | bound: 0 | nc: 7 | ncall: 7641 | eff(%): 24.962 | loglstar: -inf < -988.284 < inf | logz: -995.568 +/- nan | dlogz: 883.928 > 0.100
iter: 2158 | batch: 0 | bound: 1 | nc: 43 | ncall: 7684 | eff(%): 24.850 | loglstar: -inf < -987.709 < inf | logz: -995.358 +/- nan | dlogz: 883.761 > 0.100
iter: 2159 | batch: 0 | bound: 1 | nc: 36 | ncall: 7720 | eff(%): 24.759 | loglstar: -inf < -987.666 < inf | logz: -995.137 +/- nan | dlogz: 883.550 > 0.100
iter: 2160 | batch: 0 | bound: 1 | nc: 36 | ncall: 7756 | eff(%): 24.669 | loglstar: -inf < -987.448 < inf | logz: -994.932 +/- nan | dlogz: 883.327 > 0.100

Then this stays like this forever:

iter: 6554 | batch: 0 | bound: 1 | nc: 36 | ncall: 168020 | eff(%): 3.901 | loglstar: -inf < -287.810 < inf | logz: -298.154 +/- nan | dlogz: 225.024 > 0.100
iter: 6555 | batch: 0 | bound: 1 | nc: 36 | ncall: 168056 | eff(%): 3.900 | loglstar: -inf < -287.781 < inf | logz: -298.110 +/- nan | dlogz: 224.978 > 0.100
iter: 6556 | batch: 0 | bound: 1 | nc: 36 | ncall: 168092 | eff(%): 3.900 | loglstar: -inf < -287.743 < inf | logz: -298.066 +/- nan | dlogz: 224.933 > 0.100

Bug
There is no error, but convergence will take forever and I am confused about why this would happen given that the bounds do not update leading to the slow efficiency.

The behaviour I expected was updated bounds and a varying efficiency over time (i.e. nc changes stochastically).

I have not provided the full code/data, but can provide it privately if necessary.
@ajw278 ajw278 added the bug this shouldn't be happening label Mar 15, 2023
@segasai
Copy link
Collaborator

segasai commented Mar 16, 2023

Hi,

Thanks for the report. I'm currently trying to refactor/streamline/fix the bounding update code in #427 #425 #428.

I think there is certainly an issue there, I'm just trying to nail the proper fix.
If you can send me privately the code I could run myself, that'd be helpful.

Thanks

@ajw278
Copy link
Author

ajw278 commented Mar 16, 2023 via email

@segasai segasai mentioned this issue Mar 16, 2023
Closed
@segasai
Copy link
Collaborator

segasai commented Mar 16, 2023

I don't think I received the attach. Presumably github strips them.
But in the meantime, could you try this branch https://github.com/joshspeagle/dynesty/tree/ellipsoid_fix
I'm wondering if that fixes your problem

@ajw278
Copy link
Author

ajw278 commented Mar 17, 2023 via email

@ajw278
Copy link
Author

ajw278 commented Mar 17, 2023 via email

@segasai
Copy link
Collaborator

segasai commented Mar 18, 2023

Thanks for the code and the test, now https://github.com/joshspeagle/dynesty/tree/ellipsoid_fix branch should fix it.
There was definitely a bug when update_interval was incorrectly set for the dynamic sampling.
As the branch contains some refactoring as well, it's not yet final.

@ajw278
Copy link
Author

ajw278 commented Mar 18, 2023 via email

@segasai
Copy link
Collaborator

segasai commented Mar 18, 2023

It is not surprising that as you progress in the posterior, the efficiency goes down as the ellipsoidal approximation becomes less accurate. Keep in mind that the efficiency is a 'cumulative' efficiency. I.e. from the very start.
So I'm not seeing evidence of an issue here.
Regarding same nc, It is not obvious why it is the case, but not impossible, so again, unless there is evidence of an issue, I'm not sure there is much to do.

@ajw278
Copy link
Author

ajw278 commented Mar 18, 2023 via email

@segasai
Copy link
Collaborator

segasai commented Mar 19, 2023

Okay, I was confused - I thought you're using the uniform sampler, but you actually use the automatic sampler which means for this number of dimensions it'll be rwalk . The way rwalk is implemented is that it walks for a fixed number of steps. By default that number is determined by the dimension 20 + ndim. Hence 36.

@ajw278
Copy link
Author

ajw278 commented Mar 19, 2023 via email

@segasai
Copy link
Collaborator

segasai commented Mar 19, 2023

Thanks for the original report Andrew, I will close the issue in the meantime.

@segasai segasai closed this as completed Mar 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug this shouldn't be happening
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@segasai @ajw278