Skip to content
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

Allow fission source to be re-used from last Picard iteration #11

Open
paulromano opened this issue May 15, 2019 · 2 comments
Open

Allow fission source to be re-used from last Picard iteration #11

paulromano opened this issue May 15, 2019 · 2 comments

Comments

@paulromano
Copy link
Member

paulromano commented May 15, 2019

Moving issue 24 from gitlab originally submitted by @aprilnovak:

Convergence can be improved if the fission source in iteration i+1 is taken from iteration i. The CoupledDriver currently calls the following OpenMC functions, in this order:

  1. openmc_simulation_init: initialization stuff to be performed once per multiphysics solve; openmc_reset(); initialize_source()
  2. openmc_run: loop over batches
  3. openmc_statepoint_write()
  4. openmc_simulation_finalize(): finalization stuff to be performed once per multiphysics solve; write tally results.

From my understanding, this means that we're doing a lot of duplicate work for each Picard iteration that we could reduce by dividing openmc_simulation_init and openmc_simulation_finalize into smaller functions that perform tasks needed once per multiphysics solve (like initializing the source, if we want to re-use it between Picard iterations) and once per iteration (like resetting tallies).

@paulromano
Copy link
Member Author

Comment by @aprilnovak:

@paulromano, what do you think about adding a new method to OpenMC, called something like openmc_simulation_reset() that performs actions needed at the start of each Picard iteration? OpenmcDriver::init_step() would call openmc_simulation_reset() instead of openmc_simulation_init(), which would be moved to the constructor.

Then, openmc_simulation_finalize() would be moved from OpenmcDriver::finalize_step() to the destructor?

Or, because openmc_simulation_init() and openmc_simulation_finalize() are only called from openmc_run(), we can move some functionalities from them to openmc_init()/openmc_finalize() so that the methods with simulation in their name are interpreted as actions to do once per Picard iteration, while those without simulation are interpreted as actions to do once per coupled physics solve.

@paulromano
Copy link
Member Author

There is meaning attached to the simulation functions right now -- generally speaking they allocate / reset / deallocate global variables that are only using during the simulation. We denote these variables by the openmc::simulation:: namespace in OpenMC, which includes things like:

  • Global tallies (k-eigenvalue and leakage)
  • Previous k-eigenvalue and entropy by batch/generation
  • Source bank and fission bank
  • How many particles each thread/rank should be simulating

So, I don't think moving anything there to openmc_init or openmc_finalize is the right solution, but I like the idea of something a little finer-grained that gives the user explicitly control over what they want to happen between iterations. Right now, there's actually very little we'd need to change to use the source distribution from the previous iteration because openmc_simulation_finalize doesn't actually get rid of it right now. The only problem is that openmc_simulation_init always resamples a source. I think introducing openmc_simulation_reset is probably what we want, but we should spec this out to make sure we're covering all use cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant