Functions to run the Management Strategy Evaluation (closed-loop simulation) for a specified operating model

Simulate(OM = MSEtool::testOM, parallel = FALSE, silent = FALSE)

  Hist = NULL,
  MPs = NA,
  parallel = FALSE,
  silent = FALSE,
  extended = FALSE,
  checkMPs = TRUE

  OM = MSEtool::testOM,
  MPs = NA,
  Hist = FALSE,
  silent = FALSE,
  parallel = FALSE,
  extended = FALSE,
  checkMPs = TRUE



An operating model object (class OM or class Hist)


Logical. 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.


Should messages be printed out to the console?


Should model stop after historical simulations? Returns an object of class 'Hist' containing all historical data


A vector of methods (character string) of class MP


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 of MSE@Hist is returned.


Logical. Check if the specified MPs exist and can be run on SimulatedData?


Functions return objects of class Hist or MSE

  • Simulate - An object of class Hist

  • Project - An object of class MSE

  • runMSE - An object of class MSE if Hist = TRUE otherwise a class Hist object


Running MPs in parallel

For simple 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, the data-limited MPs in DLMtool and the reference MPs in MSEtool are not run using parallel processing. All other MPs, including custom MPs, will be run if parallel = TRUE.

To individually control which MPs run in parallel, parallel can be a named list of logical values, e.g., parallel=list(AvC=TRUE).

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.


  • Simulate: Run the Historical Simulations from an object of class OM

  • Project: Run the Forward Projections

  • runMSE: Run the Historical Simulations and Forward Projections from an object of class `OM