-
Notifications
You must be signed in to change notification settings - Fork 2
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
Parallelization support #3
Comments
parallel random sampling might be tricky but eventually there might be something in |
Five years gone and not much happened. In the meantime, fixing issue #22 splits the whole simulation into small chunks of short simulations. This would theoretically be a possibility to add parallelization. OTH, this type of running threads in parallel is not appreciated by queuing systems like SLURM, as you gain an advantage over other by using multiple cores. Unless SLURM is informed about this, it will kill the job assuming excess CPU usage. |
parallel processing with SLURM works like a marvel with: ncores <- as.integer(Sys.getenv("SLURM_JOB_CPUS_PER_NODE", 7)) - 1L
register(MulticoreParam(ncores)) any subsequent call to |
Looks very simple, and it also looks like one has to supply the number of CPUs (cores/threads) used by a single process when submitting a job to SLURM via |
yep exactly, |
Support for parallel simulation computation on a multiprocessor/multicore machine would be great. Limiting the number of cores used should be an optional parameter when running simulations, ideally defaulting to a single job, as many queuing systems have their own load balancing and discourage use of multiple cores for a single job.
The text was updated successfully, but these errors were encountered: