crp/OpenMC
1
0
Fork 0
mirror of https://github.com/openmc-dev/openmc.git synced 2026-07-28 14:15:42 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 5

Updated docs to reflect MG usage, though I still have to add the MGXS data format somewhere. Corrected ace.F90 typo pointed out by @samuelshaner

Browse source
This commit is contained in:
Adam Nelson 2015-11-10 04:54:35 -05:00
parent 4561edfac7
commit 6ca9949a91
8 changed files with 131 additions and 33 deletions
Download patch file Download diff file Expand all files Collapse all files

7
docs/source/index.rst
View file

@ -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

2
docs/source/usersguide/beginners.rst
View file

@ -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

112
docs/source/usersguide/input.rst
View file

@ -114,7 +114,8 @@ The ``<cross_sections>`` 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.
``<cutoff>`` 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:
``<energy_mode>`` Element
-------------------------
The ``<energy_mode>`` 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
``<entropy>`` 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`.
``<max_order>`` Element
---------------------------
The ``<max_order>`` 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 ``<max_order>`` 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:
``<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`.
``<resonance_scattering>`` 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`.
``<run_cmfd>`` 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
<macroscopic name="UO2" xs="71c" />
.. 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 ``<tally>`` 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 ``<tally>`` 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
<filter type="energy" />
: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
<filter type="energyout" bins="0.0 1.0 20.0" />
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
<filter type="energyout" />
:mu:
A monotonically increasing list of bounding **post-collision** cosines
@ -1361,6 +1442,8 @@ The ``<tally>`` element accepts the following sub-elements:
<filter type="delayedgroup" bins="1 2 3 4 5 6" />
.. 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 ``<tally>`` 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 ``<tally>`` 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.

26
docs/source/usersguide/install.rst
View file

@ -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

11
examples/xml/c5g7/2d/cmfd.xml
View file

@ -1,21 +1,12 @@
<?xml version="1.0"?>
<cmfd>
<begin>2</begin>
<begin>10</begin>
<feedback>true</feedback>
<mesh>
<lower_left> 0.0 0.0 -100.0</lower_left>
<upper_right> 64.26 64.26 100.0</upper_right>
<dimension>6 6 1</dimension>
<!-- <energy>1.0E-11 0.0635E-6 10.0E-6 1.0E-4 1.0E-3 0.5 1.0 20.0</energy> -->
<map>
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
</map>
<albedo>1 0 0 1 1 1</albedo>
</mesh>
</cmfd>

2
examples/xml/c5g7/2d/settings.xml
View file

@ -8,7 +8,7 @@
<eigenvalue>
<batches>2000</batches>
<inactive>500</inactive>
<particles>1000</particles>
<particles>10000</particles>
</eigenvalue>
<!--

2
src/ace.F90
View file

@ -28,7 +28,7 @@ module ace
contains
!===============================================================================
! READ_CE_XS reads all the cross sections for the problem and stores them in
! READ_ACE_XS reads all the cross sections for the problem and stores them in
! nuclides and sab_tables arrays
!===============================================================================

2
src/input_xml.F90
View file

@ -1976,7 +1976,7 @@ contains
! Get pointer list of XML <nuclide>
call get_node_list(node_mat, "macroscopic", node_macro_list)
if (get_list_size(node_macro_list) > 1) then
call fatal_error("Only one macroscopic data permitted per material, " &
call fatal_error("Only one macroscopic object permitted per material, " &
&// trim(to_str(mat % id)))
else if (get_list_size(node_macro_list) == 1) then