Skip to content

Always set npool if request-cpus>1

Michael Williams requested to merge michael.williams/bilby_pipe:request-cpus-npool into master

Now that the samplers have been refactored bilby (bilby!1043 (merged)), npool is keyword argument for all of the samplers. This means we no longer need the logic in Input.update_sampler_kwargs_conditional_on_request_cpus that sets npool (or equivalent) based on the sampler being used.

bilby version

This change requires bilby>=1.2.0 but this was already pinned in !472 (merged)

Unit tests

I've added a simple unit test to make sure the logic is correct.

End-to-end tests

I've run tests with dynesty, bilby_mcmc, nessai and pymultinest. The first three should all use npool whereas multinest should ignore it. The output directory is here: https://ldas-jobs.ligo.caltech.edu/~michael.williams/bilby-dev/bilby-pipe/request-cpus-npool/

  • dynesty & bilby_mcmc: the logs show the multiprocessing pool starting with the correct number of cores (4)
  • nessai: npool is correctly translated to n_pool and the log shows the multiprocessing pool starting
  • multinest: no pool is started but sampling runs to completion

Merge request reports