From 12201f7361ba8f455cdd080d9561b27b71b14042 Mon Sep 17 00:00:00 2001 From: Andrew Johnson Date: Thu, 19 Sep 2019 16:37:26 -0500 Subject: [PATCH 1/2] Add discussion in user's guide on depletion caveats Potential over-depletion using the fission-q energy deposition mode and some remedies. Repeated burnable materials are depleted as a single material unless diff_burnable_mats=True is given to the Operator --- docs/source/usersguide/depletion.rst | 84 ++++++++++++++++++++++++++++ 1 file changed, 84 insertions(+) diff --git a/docs/source/usersguide/depletion.rst b/docs/source/usersguide/depletion.rst index cf8f4c209..25ada4f5d 100644 --- a/docs/source/usersguide/depletion.rst +++ b/docs/source/usersguide/depletion.rst @@ -51,3 +51,87 @@ time:: Note that the coupling between the transport solver and the transmutation solver happens in-memory rather than by reading/writing files on disk. + +Caveats +======= + +Energy Deposition +----------------- + +The default energy deposition mode, ``"fission-q"``, instructs the +:class:`openmc.deplete.Operator` to normalize reaction rates using the product +of fission reaction rates and fission Q values taken from the depletion chain. +This approach does not consider indirect contributions to energy deposition, +including neutron heating or kinetic energy of fission fragments. In doing this, +the energy deposited during a transport calculation will be lower than expected. +This causes the reaction rates to be over-adjusted to hit the user-specific power, +or power density, leading to an over-depletion of burnable materials. + +There are some remedies. First, the fission Q values can be directly set in a +variety of ways. This requires knowing what the total fission energy release should +be, including indirect components. Some examples are provided below:: + + # use a dictionary of fission_q values + fission_q = {"U235": 202} # energy in MeV + + # create a modified chain and write it to a new file + chain = openmc.deplete.Chain.from_xml("chain.xml", fission_q) + chain.export_to_xml("chain_mod_q.xml") + op = openmc.deplete.Operator(geometry, setting, "chain_mod_q.xml") + + # pass the modified fission Q directly to the operator + op = openmc.deplete.Operator(geometry, setting, "chain.xml", + fission_q=fission_q) + + +A more complete way to model the energy deposition is to use the modified heating +reactions described in :ref:`methods_heating`. These values can be used to normalize +reaction rates instead of using the fission reaction rates with:: + + op = openmc.deplete.Operator(geometry, settings, "chain.xml", + energy_mode="energy-deposition") + +These modified heating libraries can be generated by running the latest version +of :meth:`openmc.data.IncidentNeutron.from_njoy`, and will eventually be bundled into +the distributed libraries. + +Local Spectra and Repeated Materials +------------------------------------ + +It is not uncommon to explicitly create a single burnable material across many locations. +From a pure transport perspective, there is nothing wrong with creating a single +3.5 wt.% enriched fuel ``fuel_3``, and placing that fuel in every fuel pin in an assembly +or even full core problem. This certainly expedites the model making process, but can pose +issues with depletion. +Under this setup, :mod:`openmc.deplete` will deplete a single ``fuel_3`` material using +a single set of reaction rates, and produce a single new composition for the next time +step. This can be problematic if the same ``fuel_3`` is used in very different regions +of the problem. + +As an example, consider a full-scale power reactor core with vacuum boundary +conditions, and with fuel pins solely composed of the same ``fuel_3`` material. +The fuel pins towards the center of the problem will surely experience a more intense +neutron flux and greater reaction rates than those towards the edge of the domain. +This indicates that the fuel in the center should be at a more depleted state than +periphery pins, at least for the fist depletion step. +However, without any other instructions, OpenMC will deplete ``fuel_3`` as a single +material, and all of the fuel pins will have an identical composition at the next +transport step. + +This can be countered by instructing the operator to treat repeated instances +of the same material as a unique material definition with:: + + op = openmc.deplete.Operator(geometry, settings, chain_file, + diff_burnable_mats=True) + +For our example problem, this would deplete fuel on the outer region of the problem +with different reaction rates than those in the center. Materials will be depleted +corresponding to their local neutron spectra, and have unique compositions at each +transport step. + + +.. note:: + + This will increase the total memory usage and run time due to increased + tallies and material definitions. + From 1d08279c0216f4387d88841af2333f7cfe33daf0 Mon Sep 17 00:00:00 2001 From: Andrew Johnson Date: Fri, 20 Sep 2019 13:29:46 -0500 Subject: [PATCH 2/2] Respond to reviewer comments on depletion caveats --- docs/source/usersguide/depletion.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/source/usersguide/depletion.rst b/docs/source/usersguide/depletion.rst index 25ada4f5d..9e2693098 100644 --- a/docs/source/usersguide/depletion.rst +++ b/docs/source/usersguide/depletion.rst @@ -62,7 +62,7 @@ The default energy deposition mode, ``"fission-q"``, instructs the :class:`openmc.deplete.Operator` to normalize reaction rates using the product of fission reaction rates and fission Q values taken from the depletion chain. This approach does not consider indirect contributions to energy deposition, -including neutron heating or kinetic energy of fission fragments. In doing this, +such as neutron heating and energy from secondary photons. In doing this, the energy deposited during a transport calculation will be lower than expected. This causes the reaction rates to be over-adjusted to hit the user-specific power, or power density, leading to an over-depletion of burnable materials. @@ -79,7 +79,7 @@ be, including indirect components. Some examples are provided below:: chain.export_to_xml("chain_mod_q.xml") op = openmc.deplete.Operator(geometry, setting, "chain_mod_q.xml") - # pass the modified fission Q directly to the operator + # alternatively, pass the modified fission Q directly to the operator op = openmc.deplete.Operator(geometry, setting, "chain.xml", fission_q=fission_q) @@ -132,6 +132,6 @@ transport step. .. note:: - This will increase the total memory usage and run time due to increased - tallies and material definitions. + This will increase the total memory usage and run time due to an increased + number of tallies and material definitions.