-
Notifications
You must be signed in to change notification settings - Fork 649
Add section in depletion user's guide about comparing to other codes #3955
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
base: develop
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -449,3 +449,34 @@ to transfer xenon from one material to another, you'd use:: | |
| ... | ||
|
|
||
| integrator.add_transfer_rate(mat1, ['Xe'], 0.1, destination_material=mat2) | ||
|
|
||
| Comparing to Other Codes | ||
| ======================== | ||
|
|
||
| Comparing depletion results from OpenMC with those from another code, such as | ||
| MCNP or Serpent, requires more than constructing equivalent transport models. | ||
| At each depletion step, differences in the transport solution, nuclear data, | ||
| reaction rate normalization, and numerical integration can all affect the | ||
| result. Small differences can also accumulate over successive depletion steps. | ||
|
|
||
| For a meaningful comparison, align as many of the following inputs and methods | ||
| as possible: | ||
|
|
||
| - Geometry and material definitions | ||
| - Neutron cross section library (e.g., ENDF/B-VIII.0) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. is it worth mentioning the MCNP distributed endf conversion script on the data repo here |
||
| - Treatment of thermal scattering and unresolved resonance probability tables | ||
| - Neutron reactions accounted for in the depletion chain | ||
| - Decay data in the depletion chain | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We may want to call out isomeric branching ratios here specifically as well -- this was an entry that required manual adjustment in @OHTAESUK's work as well. |
||
| - Fission product yields in the depletion chain | ||
| - Fission product yield interpolation method | ||
| (``CoupledOperator(fission_yield_mode=...)``) | ||
| - Reaction rate normalization, including fission Q values | ||
| (``CoupledOperator(fission_q=...)``) | ||
| - Depletion integration method (``PredictorIntegrator``, ``CECMIntegrator``, | ||
| etc.) and time-step sizes | ||
|
|
||
| Even after these choices have been aligned, exact agreement should not be | ||
| expected. Codes may use different approximations or numerical methods that | ||
| cannot be configured identically. When investigating a discrepancy, first | ||
| compare transport results and one-group reaction rates at the initial time, then | ||
| compare changes over subsequent timesteps. | ||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps worth emphasizing that geometry and materials can both have temperature definitions, both implicitly via defaults or explicitly by setting them on cells/materials. Discrepancies would be expected from different temp assignments.