Add support for OpenMC MGXS delayed neutron data.#1027
Add support for OpenMC MGXS delayed neutron data.#1027wdhawkins wants to merge 1 commit intoOpen-Sn:mainfrom
Conversation
ae85618 to
9c057c5
Compare
9c057c5 to
c2141d7
Compare
c2141d7 to
5751176
Compare
| When delayed-neutron data is present, OpenSn also imports precursor-group | ||
| information, prompt and delayed fission production, precursor decay | ||
| constants, and delayed emission spectra. If ``chi-prompt`` is not present, | ||
| OpenSn falls back to the steady fission spectrum ``chi`` as the prompt | ||
| spectrum. |
There was a problem hiding this comment.
how do we ensure that we have a null transient when going from steady state to time-dependent? i think my comment has a lot of ramification that should be best discussed in person
There was a problem hiding this comment.
Yes, we should probably discuss this in person. But, if I understand your question correctly, using initial_state=existing with the transient solver should prevent any artificial transient jump from the mode transition itself. So, the workflow would be:
- Solve the steady-state problem to convergence.
- Switch to time-dependent mode.
- Initialize
TransientSolverwithinitial_state=existing.
There was a problem hiding this comment.
for a null transient test to pass, nu prompt + nu delayed must be = to nu tot. furthermore, chi is not easily deduced from chi prompt and chi delayed (there is an approximation that happens to yield chi used in steady-state, so consistency is also an issue). finally, when coming from MC, there is always statistical noise in the values. So, all in all, it is not obvious to how a null transient will happen. but we definitely need to add some consistency checks between steady-state data and transient data and report back to the user what those are, so that they are informed.
There was a problem hiding this comment.
I see. We should talk more about this.
5751176 to
232c16b
Compare
232c16b to
8ca4bea
Compare
PR Checklist