diff --git a/docs/source/usersguide/depletion.rst b/docs/source/usersguide/depletion.rst index 3d5517416d..ad1ba779e6 100644 --- a/docs/source/usersguide/depletion.rst +++ b/docs/source/usersguide/depletion.rst @@ -1,8 +1,8 @@ .. _usersguide_depletion: -========= -Depletion -========= +=========================== +Depletion and Transmutation +=========================== OpenMC supports coupled depletion, or burnup, calculations through the :mod:`openmc.deplete` Python module. OpenMC solves the transport equation to @@ -51,6 +51,32 @@ time:: Note that the coupling between the transport solver and the transmutation solver happens in-memory rather than by reading/writing files on disk. +Fixed-Source Transmutation +========================== + +When the ``power`` or ``power_density`` argument is used for one of the +Integrator classes, it is assumed that OpenMC is running in k-eigenvalue mode, +and normalization of tally results is performed based on energy deposition. It +is also possible to run a fixed-source simulation and perform normalization +based on a known source rate. First, as with all fixed-source calculations, we +need to set the run mode:: + + settings.run_mode = 'fixed source' + +When constructing the :class:`~openmc.deplete.Operator`, you should indicate +that normalization of tally results will be done based on the source rate rather +than a power or power density:: + + op = openmc.deplete.Operator(geometry, settings, normalization_mode='source-rate') + +Finally, when creating a depletion integrator, use the ``source_rates`` argument:: + + integrator = openmc.deplete.PredictorIntegrator(op, timesteps, sources_rates=...) + +As with the ``power`` argument, you can provide a different source rate for each +timestep in the calculation. A zero source rate for a given timestep will result +in a decay-only step, where all reaction rates are zero. + Caveats ======= @@ -61,14 +87,14 @@ 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, -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. +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. 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:: +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": 202e+6} # energy in eV @@ -83,39 +109,39 @@ be, including indirect components. Some examples are provided below:: 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:: +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", normalization_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. +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. +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. +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:: @@ -123,12 +149,13 @@ 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. The volume of the original ``fuel_3`` material must represent -the volume of **all** the ``fuel_3`` in the problem. When creating the unique -materials, this volume will be equally distributed across all material instances. +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. The volume of the original ``fuel_3`` +material must represent the volume of **all** the ``fuel_3`` in the problem. +When creating the unique materials, this volume will be equally distributed +across all material instances. .. note::