Created by: aprilnovak

For multiphysics simulations with Picard-style iterations of OpenMC and a second code, it would be helpful to have finer-grained user control of OpenMC execution from within a coupled physics driver. Currently, openmc_simulation_init() and openmc_simulation_finalize() perform many actions that in Picard iterations you might not want to always perform together. For example, openmc_simulation_init() both initializes the source and resets the tallies. For Picard iterations, we will want to reset tallies for each iteration, but might only want to initialize a source at the very start of the simulation.

For Picard iterations, having the following conceptual methods would be helpful:

• Initialization at the start of the coupled simulation; this is performed only once, and is called from the constructor of the coupled physics driver [openmc_init()]

  • Initialization before entering physics iteration loops; this is performed only once and might use information from CoupledDriver not available in the constructor [openmc_simulation_init()]

    • Initialization before each Picard iteration such as resetting tallies [new method: openmc_simulation_preset() ?]
    • Run OpenMC given initialization and finalization in other methods [new method: openmc_simulation_run() ?]
    • Finalization after each Picard iteration such as writing tallies.out [new method: openmc_simulation_postset() ?]

  • Finalization after leaving physics iteration loops; this is performed only once [openmc_simulation_finalize()]

• Finalization at the end of the coupled simulation; this is performed only once, and is called from the destructor of a coupled physics driver [openmc_finalize()]

As suggested by @paulromano, adding a couple new methods would be minimally intrusive and wouldn't change the meaning behind the existing openmc_simulation_... methods.