Closed yonatank93 closed 2 years ago
@mjwen Can you take a look at this? And do we want to add a documentation in "How To: Run in parallel mode" about possible parallelization when running MCMC sampling? For example, by showing what user can do to use multithreading in loss evaluation and MPI in sampling, and point out that currently we don't support MPI in loss evaluation when running MCMC sampling.
Thank you @yonatank93 for the PR! I will take a look at this soon. In the meantime, can you fix to let the linting and test pass? For the test, it seems ptemcee
is needed, but not installed in the GH actions. You may want to install it, like, below this line.
I have updated so that the linting and test pass. And coming back to my question, do we want to provide an example/discussion about how to run multiprocessing for UQ?
I have updated so that the linting and test pass. And coming back to my question, do we want to provide an example/discussion about how to run multiprocessing for UQ?
Yes, I think this would be great! This would be as similar as the existing UQ example with changes only reflecting the part.
@yonatank93 You probably did not see my previous reply. The PR is ready to be merged, any last changes you want to make?
@mjwen Currently, I only mention it briefly about parallelization for the MCMC sampling in the example. Do we want to add a more detail documentation about it?
I also haven't figured out how to avoid using global variable. I want to work on this, but it can be for another PR.
@mjwen I just added a more thorough documentation about parallelization in MCMC. Do you have any comments on that? Otherwise, I don't have any other changes for this PR.
Summary
Update the
uq
module to behave better when we run the sampling in parallel, especially when we use hybrid parallelization using multithreading in loss evaluation and MPI in sampling.This is related to Issue #62 .
Known Issue
kliff.uq.MCMC().__init__()
, which I think is the reason why we would get an error if we declare the pool before instantiatingkliff.uq.MCMC
.schwimmbad.MPIPool
, the performance was similar to if we use serial calculation in the sampling process (at least this was my experience).Fix
kliff.uq.MCMC
.kliff.uq.PtemceeSampler
inherits fromptemcee.Sampler
(also applies with the emcee counterpart), then this parallel computing performance issue seemed to disappear. I am not sure why this is the case, but at least it kind of fix the issue.