Missing MG particle speed getter and delayed fission neutron emission

[ilhamv]

Bug Description

• Particle.speed() has not been implemented for MG mode.
• Delayed neutrons are emitted at t = 0 and promptly in MG and CE modes, respectively.

Steps to Reproduce

These bugs particularly affect simulations with TimeFilter tallies in fissionable systems running sufficiently long in the order of delayed neutron precursor mean decay times.

Attempt to Fix the Bug

I attempted to fix them here and ran verification tests of neutron pulse simulations:

MG test

Here is the result of a pulsed infinite homogeneous 361-group problem, where the MGXS is generated from the pincell example:

The "analytical" reference solution is also shown for verification. The simulation was run in 10 batches with 100k particles per batch.

CE test

Here is the result of the jezebel example pulsed with 2 MeV isotropic point source at the origin:

The simulation was run in 10 batches with 100k particles per batch.

Estimates of neutron inverse period, or time constant $\alpha$, can be naively calculated from two consecutive data points:

Experimental value for the prompt neutron time constant ($\alpha_p$ = -640 +- 10 /ms) is also shown above for verification.

Note: In running this Jezebel problem, I had to increase the secondary bank size limit from the default value 10k to 100k.

[gridley]

Whoa, very cool! Do you want to fix this, or were you hoping that someone else would? I may take this one on, as I do hope to have Sjenitzer's method implemented in OpenMC some day (which is a bit different from the type of transient methods you all run!)

[ilhamv]

@gridley I would be happy to take this on! Should I make a PR for it?

Sjenitzer's "Dynamic MC" can be seen as an orchestra of several methods, and those methods can be implemented piece by piece, each with its own parameters (e.g., different time grids for population combing, forced precursor decay, nonlinear feedbacks, etc.). This gives users flexibility on choosing which methods to turn on and how they are set up, so that they can achieve optimum customized run (which can be very problem dependent).

One low hanging fruit, but is particularly useful for a range of problems, I think, is the forced precursor decay. Users would just need to set a time mesh for the method and then some additional work would be done in the creation of the fission sites.

[gridley]

Please do, I think it won't be a lot of code to fix.

As for forced decay: my current thinking was that we need a mechanism for time boundaries first. So we'd stop all the histories at that boundary, then yield back to let modifications be made to material densities, etc. I guess we should discuss this on another GH issue though!

[gridley]

I did open #2897 to discuss further.