You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The fact that CPNest currently tries to handle parallel processing on its own presents it from being able to use MPI (as noted in Issue #33), and also makes it a pain to work with. Most (all?) other samplers that I've countered allow a preallocated pool of processes to be passed to them, which gives the user greater freedom to control the parallel environment in the manner that best fits their environment. For example, in PyCBC Inference, we create a pool of processes ourselves (which allows us to side step pickling issues when using python's multiprocessing), then give that pool to the sampler. As a result, we immediately can use either multiprocessing or MPI for parallelization for all other samplers.
If CPNest used a pool instead of trying to manage parallelization on its own, then it would make it easier both on our end to use it, and on the CPNest developers' end to support parallelization, since now you would not need to add code to deal with different types of communication schemes, negating issues like #33.
The text was updated successfully, but these errors were encountered:
Any suggestion/code snippet would be greatly appreciated. I personally have little experience with parallelisation and the current way cpnest works is the result of a lot of trial and error.
The fact that CPNest currently tries to handle parallel processing on its own presents it from being able to use MPI (as noted in Issue #33), and also makes it a pain to work with. Most (all?) other samplers that I've countered allow a preallocated pool of processes to be passed to them, which gives the user greater freedom to control the parallel environment in the manner that best fits their environment. For example, in PyCBC Inference, we create a pool of processes ourselves (which allows us to side step pickling issues when using python's multiprocessing), then give that pool to the sampler. As a result, we immediately can use either multiprocessing or MPI for parallelization for all other samplers.
If CPNest used a pool instead of trying to manage parallelization on its own, then it would make it easier both on our end to use it, and on the CPNest developers' end to support parallelization, since now you would not need to add code to deal with different types of communication schemes, negating issues like #33.
The text was updated successfully, but these errors were encountered: