openmc
openmc copied to clipboard
openmc-dev
Dynamic MC
Description
Implement Sjenitzer's dynamic MC. This has a few moving parts.
- Reading in neutrons in flight and precursor densities on a mesh, or weighted precursor sites. Either way, there would need to be some new type of state file for initializing transients.
- The usual eigenvalue or fixed source code would need to be able to create the aforementioned file.
- Yielding back from a C++ run when all particles hit a time boundary. My thoughts on this are to add a global variable which is just the next time boundary--no need for a mesh. When all the histories hit this or precursors are created which decay beyond that step, control should be yielded back to the python API to make adjustments to material densities, etc.
- Tallying in time can be done using the currently implementation of time filtering, yay!
It sounds like @ilhamv has some thoughts on this, too. @stchaker likely also does.
Alternatives
Quasistatic method and related are possible, but don't really fit the vibe of Monte Carlo methods. We should't rely on assumptions like a shape function--leave that stuff for deterministic codes that are meant to be speedy.
Compatibility
The C API would see a few time-related changes, but the current facilities for moving surfaces and setting material densities and temperatures should work fine for transient problems.
Also, it would be useful to store density multipliers on cells. This would allow better compatibility when converting from MCNP inputs, and also obviate storing lots of redundant nuclide data when dealing with a mesh of water cells where the density and temperature change throughout the problem, but the composition overall is the same.
The PR #2451 was written partly to ease exporting to a precursor/neutron in flight source file from a steady-state simulation. @stchaker actually has some code working that does this, pretty sure it's in some branch of his fork.
Thanks for putting this together Gavin! The transients branch on my fork has the scoring functions for the source terms of DMC, and the ability to generate a neutron source file from flight. I just need to write the routine which combines the source file of neutrons with the precursor mesh into a state which can be used to initialize the DMC run. Happy to make my fork public if anyone would like to take a look.
Cool cool @stchaker. Going public with it might be nice. I think just figuring out how to break this into a bunch of smaller pieces of work to do would be the move at this point. I'm happy to collaborate on it... Were you still planning to implement the forced decay and stuff at some point? If we can find anyone else who wants to collaborate, that would be awesome.
That's a good idea @gridley. Yeah I think the delayed neutron sampling techniques are still on my list. There are some techniques we can use that are semi-analytical or we can do forced decay with re-weighing. I'll keep you posted on this, and share that fork with you!
Thanks, @gridley.
Following from #2885: Time boundary (or "time census," which can be implemented similarly to "fission census" in k-eigenvalue mode) is not necessary for forced precursor decay. This is a good thing because there are single-physics neutronics problems that can benefit from forced decay. Once the forced decay is set up, we can add the time boundary; the interaction of the two would be very similar to the one with time_cutoff, but instead of rejecting, we bank it.
As for sampling of initial particles, I did have some thoughts on that here.
Another capability that I think would be useful is continuously moving surface, particularly planes for control rods.
When we are in the position where we need population control at time boundaries, we can reuse the bank management infrastructure of the k-eigenvalue one (particle sampling and work rebalancing). However, the sampling technique currently used cuts edges to make sure the targeted particle sample size is obtained. This seems OK for k-eigenvalue problems but may not be for the time-dependent ones where the population size does evolve. I implemented several population control techniques with an abstraction here (which is used in this paper). The branch is way behind, but I can revive the implementation if needed.
If we are changing the model over time, why would a time boundary not be required? I understand it would be an extreme minority of neutrons which actually reach it in a reactor calc, but it's still not exactly correct if you let them propagate beyond the boundary without having applied the geometric/material changes.
So, I find the idea of adding forced decay for the standard particle time tracking interesting. No need to have a special transient mode, it can just be fixed source to test it out. Here's what I'm mentally stuck on: in Sjenitzer's work you always can force decay to be in the time bin following the current time boundary. You need some time interval specified to force the decay. How do you propose defining the time interval, preliminarily, not necessarily before a production-level implementation?
I agree that continuously moving surfaces would be super nice, it just might be a little tricky to implement in the geometry system as it stands.
That's awesome that you may want to revive what you once had! Maybe you, Sebastian, and I should do a video call some time to figure who is responsible for what. It seems possible to break this into cleanly divided individual PRs that we can make to a branch separate from the main develop branch.
Cool cool @stchaker. Going public with it might be nice. I think just figuring out how to break this into a bunch of smaller pieces of work to do would be the move at this point. I'm happy to collaborate on it... Were you still planning to implement the forced decay and stuff at some point? If we can find anyone else who wants to collaborate, that would be awesome.
I'd be down to collaborate on this issue. I've been doing some work related to dynamic MC for my thesis and was planning to do some kind of implementation with it in OpenMC, nice to see the ball on that is already rolling.
