Functions to run the Management Strategy Evaluation (closed-loop simulation) for a specified operating model
Usage
Simulate(OM = MSEtool::testOM, parallel = FALSE, silent = FALSE, nsim = NULL)
Project(
Hist = NULL,
MPs = NA,
parallel = FALSE,
silent = FALSE,
extended = FALSE,
checkMPs = FALSE
)
runMSE(
OM = MSEtool::testOM,
MPs = NA,
Hist = FALSE,
silent = FALSE,
parallel = FALSE,
extended = FALSE,
checkMPs = FALSE
)
Arguments
- OM
An operating model object (class OM or class
Hist
). Also works forMOM
objects, as a wrapper forProjectMOM
- parallel
Logical or a named list. Should MPs be run using parallel processing? For
runMSE
, can also be"sac"
to run the entire MSE in parallel using the split-apply-combine technique. See Details for more information.- silent
Should messages be printed out to the console?
- nsim
Optional. numeric value to override
OM@nsim
.- Hist
Should model stop after historical simulations? Returns an object of class 'Hist' containing all historical data
- MPs
A vector of methods (character string) of class MP
- extended
Logical. Return extended projection results? if TRUE,
MSE@Misc$extended
is a named list with extended data (including historical and projection by area), and extended version ofMSE@Hist
is returned.- checkMPs
Logical. Check if the specified MPs exist and can be run on
SimulatedData
?
Details
Running MPs in parallel
For most MPs, running in parallel can actually lead to an increase in computation time, due to the overhead in sending the
information over to the cores. Consequently, by default the MPs will not be run in parallel if parallel=TRUE
(although other internal code will be run in parallel mode).
To run MPs in parallel, specify a named list with the name of the MP(s) assigned as TRUE. For example,parallel=list(AvC=TRUE
)
will run the AvC
MP in parallel mode.
Split-apply-combine MSE in parallel
Additional savings in computation time can be achieved by running the entire simulation in batches. Individual simulations of the operating model
are divided into separate cores using SubCpars, Simulate
and Project
are applied independently for each core via snowfall::sfClusterApplyLB
, and the
output (a list of MSE objects) is stitched back together into a single MSE object using joinMSE.
The ideal number of cores will be determined based on the number of simulations and available cores.
There are several issues to look out for when using this split-apply-combine technique:
Numerical optimization for depletion may fail in individual cores when
OM@cpars$qs
is not specified.Length bins should be specified in the operating model in
OM@cpars$CAL_bins
. Otherwise, length bins can vary by core and create problems when combining into a single object.Compared to non-parallel runs, sampled parameters in the operating model will vary despite the same value in
OM@seed
.If there is an error in individual cores or while combining the parallel output into a single Hist or MSE object, the list of output (from the cores) will be returned.