diff --git a/docs/source/index.rst b/docs/source/index.rst index 8dba920161..54ba825e58 100644 --- a/docs/source/index.rst +++ b/docs/source/index.rst @@ -4,9 +4,10 @@ The OpenMC Monte Carlo Code OpenMC is a Monte Carlo particle transport simulation code focused on neutron criticality calculations. It is capable of simulating 3D models based on -constructive solid geometry with second-order surfaces. The particle interaction -data is based on ACE format cross sections, also used in the MCNP and Serpent -Monte Carlo codes. +constructive solid geometry with second-order surfaces. OpenMC supports either +continuous-energy or multi-group transport. The continuous-energy +particle interaction data is based on ACE format cross sections, also used +in the MCNP and Serpent Monte Carlo codes. OpenMC was originally developed by members of the `Computational Reactor Physics Group`_ at the `Massachusetts Institute of Technology`_ starting diff --git a/docs/source/usersguide/beginners.rst b/docs/source/usersguide/beginners.rst index d65ee1f831..9ecffe3f67 100644 --- a/docs/source/usersguide/beginners.rst +++ b/docs/source/usersguide/beginners.rst @@ -12,7 +12,7 @@ In a nutshell, OpenMC simulates neutrons moving around randomly in a `nuclear reactor`_ (or other fissile system). This is what's known as `Monte Carlo`_ simulation. Neutrons are important in nuclear reactors because they are the particles that induce `fission`_ in uranium and other nuclides. Knowing the -behavior of neutrons allows you to figure out how often and where fission +behavior of neutrons allows you to determine how often and where fission occurs. The amount of energy released is then directly proportional to the fission reaction rate since most heat is produced by fission. By simulating many neutrons (millions or billions), it is possible to determine the average diff --git a/docs/source/usersguide/input.rst b/docs/source/usersguide/input.rst index d05dcdf71b..3e7a6ec174 100644 --- a/docs/source/usersguide/input.rst +++ b/docs/source/usersguide/input.rst @@ -114,7 +114,8 @@ The ```` element has no attributes and simply indicates the path to an XML cross section listing file (usually named cross_sections.xml). If this element is absent from the settings.xml file, the :envvar:`CROSS_SECTIONS` environment variable will be used to find the path to the XML cross section -listing. +listing when in continuous-energy mode, and the :envvar:`MG_CROSS_SECTIONS` +environment variable will be used in multi-group mode. ```` Element -------------------- @@ -212,8 +213,21 @@ cross section values between. *Default*: logarithm + .. note:: This element is not used in the multi-group :ref:`energy_mode`. + .. _LA-UR-14-24530: https://laws.lanl.gov/vhosts/mcnp.lanl.gov/pdf_files/la-ur-14-24530.pdf +.. _energy_mode: + +```` Element +------------------------- + +The ```` element tells OpenMC if the run-mode should be +continuous-energy or multi-group. Options for entry are: ``continuous-energy`` +or ``multi-group``. + + *Default*: continuous-energy + ```` Element --------------------- @@ -264,6 +278,20 @@ based on the recommended value in LA-UR-14-24530_. *Default*: 8000 + .. note:: This element is not used in the multi-group :ref:`energy_mode`. + +```` Element +--------------------------- + +The ```` element allows the user to set a maximum scattering order +to apply to every nuclide/material in the problem. That is, if the data +library has :math:`P_3` data available, but ```` was set to ``1``, +then, OpenMC will only use up to the :math:`P_1` data. + + *Default*: Use the maximum order in the data library + + .. note:: This element is not used in the continuous-energy :ref:`energy_mode`. + .. _natural_elements: ```` Element @@ -343,6 +371,8 @@ or sub-elements and can be set to either "false" or "true". *Default*: true + .. note:: This element is not used in the multi-group :ref:`energy_mode`. + ```` Element ---------------------------------- @@ -402,6 +432,8 @@ attributes or sub-elements: *Defaults*: None (scatterer), ARES (method), 0.01 eV (E_min), 1.0 keV (E_max) + .. note:: This element is not used in the multi-group :ref:`energy_mode`. + ```` Element ---------------------- @@ -514,6 +546,8 @@ attributes/sub-elements: *Default*: 0.988 2.249 + .. note:: The above format should be used even when using the multi-group :ref:`energy_mode`. + :write_initial: An element specifying whether to write out the initial source bank used at the beginning of the first batch. The output file is named @@ -1113,10 +1147,15 @@ Each ``material`` element can have the following attributes or sub-elements: :density: An element with attributes/sub-elements called ``value`` and ``units``. The ``value`` attribute is the numeric value of the density while the ``units`` - can be "g/cm3", "kg/m3", "atom/b-cm", "atom/cm3", or "sum". The "sum" unit - indicates that the density should be calculated as the sum of the atom - fractions for each nuclide in the material. This should not be used in - conjunction with weight percents. + can be "g/cm3", "kg/m3", "atom/b-cm", "atom/cm3", "sum", or "macro". + The "sum" unit indicates that the density should be calculated as the sum + of the atom fractions for each nuclide in the material. This should not be + used in conjunction with weight percents. The "macro" unit is used with + a ``macroscopic`` to indicate that the density is already included in the + library and thus not needed here. However, if a value is provided for the + ``value``, then this is treated as a number density multiplier on the + macroscopic cross sections in the multi-group data. This can be used, + for example, when perturbing the density slightly. *Default*: None @@ -1171,6 +1210,24 @@ Each ``material`` element can have the following attributes or sub-elements: *Default*: None + :macroscopic: + The ``macroscopic`` element is similar to the ``nuclide`` element, but, + recognizes that some multi-group libraries may be providing material + specific macroscopic cross sections instead of always providing nuclide + specific data like in the continuous-energy case. To that end, the + macroscopic element has attributes/sub-elements called ``name``, and ``xs``. + The ``name`` attribute is the name of the cross-section for a + desired nuclide while the ``xs`` attribute is the cross-section + identifier. One example would be as follows: + + .. code-block:: xml + + + + .. note:: This element is not used in the multi-group :ref:`energy_mode`. + + *Default*: None + .. _IUPAC Isotopic Compositions of the Elements 2009: http://pac.iupac.org/publications/pac/pdf/2011/pdf/8302x0397.pdf @@ -1257,7 +1314,8 @@ The ```` element accepts the following sub-elements: A list of universes for which the tally should be accumulated. :energy: - A monotonically increasing list of bounding **pre-collision** energies + In continuous-energy mode, this filter should be provided as a + monotonically increasing list of bounding **pre-collision** energies for a number of groups. For example, if this filter is specified as .. code-block:: xml @@ -1267,17 +1325,40 @@ The ```` element accepts the following sub-elements: then two energy bins will be created, one with energies between 0 and 1 MeV and the other with energies between 1 and 20 MeV. + In multi-group mode, however, the bounds of the filter are already + implied as being the same as the group boundaries of the problem. + Therefore no bins would be needed as they are implicitly applied by + the code. For example, the above filter example for continuous-energy + mode would look like the following for multi-group mode, but the + resultant tallies would still be done for every group in the library: + + .. code-block:: xml + + + :energyout: - A monotonically increasing list of bounding **post-collision** - energies for a number of groups. For example, if this filter is - specified as + In continuous-energy mode, this filter should be provided as a + monotonically increasing list of bounding **post-collision** energies + for a number of groups. For example, if this filter is specified as .. code-block:: xml - then two post-collision energy bins will be created, one with energies - between 0 and 1 MeV and the other with energies between 1 and 20 MeV. + then two post-collision energy bins will be created, one with + energies between 0 and 1 MeV and the other with energies between + 1 and 20 MeV. + + In multi-group mode, however, the bounds of the filter are already + implied as being the same as the group boundaries of the problem. + Therefore no bins would be needed as they are implicitly applied by + the code. For example, the above filter example for continuous-energy + mode would look like the following for multi-group mode, but the + resultant tallies would still be done for every group in the library: + + .. code-block:: xml + + :mu: A monotonically increasing list of bounding **post-collision** cosines @@ -1361,6 +1442,8 @@ The ```` element accepts the following sub-elements: + .. note:: This filter type is not used in the multi-group :ref:`energy_mode`. + :nuclides: If specified, the scores listed will be for particular nuclides, not the summation of reactions from all nuclides. The format for nuclides should be @@ -1424,6 +1507,8 @@ The ```` element accepts the following sub-elements: Total production of delayed neutrons due to fission. Units are neutrons produced per source neutron. + .. note:: This score type is not used in the multi-group :ref:`energy_mode`. + :kappa-fission: The recoverable energy production rate due to fission. The recoverable energy is defined as the fission product kinetic energy, prompt and @@ -1494,6 +1579,8 @@ The ```` element accepts the following sub-elements: The ``analog`` estimator is actually identical to the ``collision`` estimator for the inverse-velocity score. + .. note:: This score type is not used in the multi-group :ref:`energy_mode`. + :events: Number of scoring events. Units are events per source particle. @@ -1871,6 +1958,9 @@ attributes/sub-elements: automatically assumes a one energy group calculation over the entire energy range. + .. note:: When running in the multi-group :ref:`energy_mode`, these + energy bins must match the data library's group boundaries. + :albedo: Surface ratio of incoming to outgoing partial currents on global boundary conditions. They are listed in the following order: -x +x -y +y -z +z. diff --git a/docs/source/usersguide/install.rst b/docs/source/usersguide/install.rst index dcf990bdad..246e343c1e 100644 --- a/docs/source/usersguide/install.rst +++ b/docs/source/usersguide/install.rst @@ -366,11 +366,17 @@ Cross Section Configuration --------------------------- In order to run a simulation with OpenMC, you will need cross section data for -each nuclide in your problem. Since OpenMC uses ACE format cross sections, you -can use nuclear data that was processed with NJOY_, such as that distributed -with MCNP_ or Serpent_. Several sources provide free processed ACE data as -described below. The TALYS-based evaluated nuclear data library, TENDL_, is also -openly available in ACE format. +each nuclide or material in your problem. OpenMC can be run in +continuous-energy or multi-group mode. + +In continuous-energy mode OpenMC uses ACE format cross sections; in this case +you can use nuclear data that was processed with NJOY_, such as that +distributed with MCNP_ or Serpent_. Several sources provide free processed +ACE data as described below. The TALYS-based evaluated nuclear data library, +TENDL_, is also openly available in ACE format. + +In multi-group mode, OpenMC utilizes an XML-based library format which can be +used to describe nuclidic- or material-specific quantities. Using ENDF/B-VII.1 Cross Sections from NNDC ------------------------------------------- @@ -435,6 +441,16 @@ distribution to the location of the Serpent cross sections. Then, either set the environment variable to the absolute path of the ``cross_sections_serpent.xml`` file. +Using Multi-Group Cross Sections +-------------------------------- + +Multi-group cross section libraries are generally tailored to the specific +calculation to be performed. Therefore, at this point in time, OpenMC is not +distributed with any pre-existing multi-group cross section libraries. +However, if the user has obtained or generated their own library, the user +should set the :envvar:`MG_CROSS_SECTIONS` environment variable +to the absolute path of the file library expected to used most frequently. + .. _NJOY: http://t2.lanl.gov/nis/codes.shtml .. _NNDC: http://www.nndc.bnl.gov/endf/b7.1/acefiles.html .. _NEA: http://www.oecd-nea.org diff --git a/examples/xml/c5g7/2d/cmfd.xml b/examples/xml/c5g7/2d/cmfd.xml index aa3deb4b67..8e8d77490c 100644 --- a/examples/xml/c5g7/2d/cmfd.xml +++ b/examples/xml/c5g7/2d/cmfd.xml @@ -1,21 +1,12 @@ - 2 + 10 true 0.0 0.0 -100.0 64.26 64.26 100.0 6 6 1 - - - 2 2 2 2 1 1 - 2 2 2 2 1 1 - 2 2 2 2 1 1 - 2 2 2 2 1 1 - 1 1 1 1 1 1 - 1 1 1 1 1 1 - 1 0 0 1 1 1 diff --git a/examples/xml/c5g7/2d/settings.xml b/examples/xml/c5g7/2d/settings.xml index 2ad738704a..038c80c303 100644 --- a/examples/xml/c5g7/2d/settings.xml +++ b/examples/xml/c5g7/2d/settings.xml @@ -8,7 +8,7 @@ 2000 500 - 1000 + 10000