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.

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

Metropolis chain tuning is differs between single- and multiprocessing #3733

Closed
michaelosthege opened this issue Dec 15, 2019 · 3 comments
Closed

Comments

@michaelosthege
Copy link
Member

michaelosthege commented Dec 15, 2019

(split from #3731)

Observations

When Metropolis is used with cores > 1 and chains > 1, all chains are independently tuned.

With cores=1 however, Metropolis initializes the 2nd chain with the scaling from the first. It is still tuned, but in the end it's a different between sequential single-process and parallelized multiprocess sampling.

Cause

For Metropolis, the stepper is re-used and re-tuned, but no reset happens.

https://github.com/pymc-devs/pymc3/blob/dc9fd7251b34e9851308e91d622513ebe648f49e/pymc3/sampling.py#L711-L716

Possible Solutions

  • re-setting the tuning parameter before continuing with the next chain
  • ...other ideas?
@ColCarroll
Copy link
Member

Wow, this is interesting.

  1. This is definitely a bug, in that it is different behavior due to settings that have nothing to do with tuning. I think we should reset the tuning parameter (or just initialize a new stepper?) before continuing.
  2. More generally, sharing tuning data between chains does not seem like a bad idea to me, either as an early diagnostic (if you just compare them), or to speed up tuning (like here, we have a "good initialization" for scaling).

@michaelosthege
Copy link
Member Author

Over in #3784 I fixed it for the DEMetropolisZ. Shall I include a fix for Metropolis in the same PR ?

@junpenglao
Copy link
Member

I think it is better sending a separate PR.

michaelosthege added a commit to michaelosthege/pymc that referenced this issue Feb 5, 2020
michaelosthege added a commit to michaelosthege/pymc that referenced this issue Feb 5, 2020
michaelosthege added a commit to michaelosthege/pymc that referenced this issue Feb 6, 2020
@twiecki twiecki closed this as completed in 812e60e Feb 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants