mirror of
https://github.com/openmc-dev/openmc.git
synced 2026-07-28 06:05:58 -04:00
Merge branch 'develop' into iso-lab
This commit is contained in:
Will Boyd
commit
2c7e16cab2
134 changed files with 215 additions and 370 deletions
|
|
@ -55,23 +55,20 @@ files are called:
|
|||
Validating XML Files
|
||||
--------------------
|
||||
|
||||
Input files can be checked before executing OpenMC using the ``xml_validate``
|
||||
script. It is located in ``src/utils/xml_validate.py`` in the source code or in
|
||||
``bin/xml_validate`` in the install directory.
|
||||
|
||||
Two command line arguments can be set when running ``xml_validate``:
|
||||
Input files can be checked before executing OpenMC using the
|
||||
``openmc-validate-xml`` script which is installed alongside the Python API. Two
|
||||
command line arguments can be set when running ``openmc-validate-xml``:
|
||||
|
||||
* ``-i``, ``--input-path`` - Location of OpenMC input files.
|
||||
*Default*: current working directory
|
||||
* ``-r``, ``--relaxng-path`` - Location of OpenMC RelaxNG files.
|
||||
*Default*: None
|
||||
|
||||
If the RelaxNG path is not set, ``xml_validate`` will search for these files
|
||||
because it expects that the user is either running the script located in the
|
||||
install directory ``bin`` folder or in ``src/utils``. Once executed, it will
|
||||
match OpenMC XML files with their RelaxNG schema and check if they are valid.
|
||||
Below is a table of the messages that will be printed after each file is
|
||||
checked.
|
||||
If the RelaxNG path is not set, the script will search for these files because
|
||||
it expects that the user is either running the script located in the install
|
||||
directory ``bin`` folder or in ``src/utils``. Once executed, it will match
|
||||
OpenMC XML files with their RelaxNG schema and check if they are valid. Below
|
||||
is a table of the messages that will be printed after each file is checked.
|
||||
|
||||
======================== ===================================
|
||||
Message Description
|
||||
|
|
@ -193,7 +190,7 @@ should be performed. It has the following attributes/sub-elements:
|
|||
*Default*: None
|
||||
|
||||
:threshold:
|
||||
The precision trigger's convergence criterion for the
|
||||
The precision trigger's convergence criterion for the
|
||||
combined :math:`k_{eff}`.
|
||||
|
||||
*Default*: None
|
||||
|
|
@ -646,16 +643,16 @@ particle number, respectively.
|
|||
-------------------------
|
||||
|
||||
OpenMC includes tally precision triggers which allow the user to define
|
||||
uncertainty thresholds on :math:`k_{eff}` in the ``<eigenvalue>`` subelement of
|
||||
``settings.xml``, and/or tallies in ``tallies.xml``. When using triggers,
|
||||
uncertainty thresholds on :math:`k_{eff}` in the ``<eigenvalue>`` subelement of
|
||||
``settings.xml``, and/or tallies in ``tallies.xml``. When using triggers,
|
||||
OpenMC will run until it completes as many batches as defined by ``<batches>``.
|
||||
At this point, the uncertainties on all tallied values are computed and
|
||||
compared with their corresponding trigger thresholds. If any triggers have not
|
||||
been met, OpenMC will continue until either all trigger thresholds have been
|
||||
At this point, the uncertainties on all tallied values are computed and
|
||||
compared with their corresponding trigger thresholds. If any triggers have not
|
||||
been met, OpenMC will continue until either all trigger thresholds have been
|
||||
satisfied or ``<max_batches>`` has been reached.
|
||||
|
||||
The ``<trigger>`` element provides an active "toggle switch" for tally
|
||||
precision trigger(s), the maximum number of batches and the batch interval. It
|
||||
precision trigger(s), the maximum number of batches and the batch interval. It
|
||||
has the following attributes/sub-elements:
|
||||
|
||||
:active:
|
||||
|
|
@ -674,11 +671,11 @@ has the following attributes/sub-elements:
|
|||
OpenMC will check if the trigger has been reached at each batch defined
|
||||
by ``batch_interval`` after the minimum number of batches is reached.
|
||||
|
||||
.. note:: If this tag is not present, the ``batch_interval`` is predicted
|
||||
dynamically by OpenMC for each convergence check. The predictive
|
||||
model assumes no correlation between fission sources
|
||||
distributions from batch-to-batch. This assumption is reasonable
|
||||
for fixed source and small criticality calculations, but is very
|
||||
.. note:: If this tag is not present, the ``batch_interval`` is predicted
|
||||
dynamically by OpenMC for each convergence check. The predictive
|
||||
model assumes no correlation between fission sources
|
||||
distributions from batch-to-batch. This assumption is reasonable
|
||||
for fixed source and small criticality calculations, but is very
|
||||
optimistic for highly coupled full-core reactor problems.
|
||||
|
||||
|
||||
|
|
@ -1391,8 +1388,8 @@ The ``<tally>`` element accepts the following sub-elements:
|
|||
Number of scoring events
|
||||
|
||||
:trigger:
|
||||
Precision trigger applied to all filter bins and nuclides for this tally.
|
||||
It must specify the trigger's type, threshold and scores to which it will
|
||||
Precision trigger applied to all filter bins and nuclides for this tally.
|
||||
It must specify the trigger's type, threshold and scores to which it will
|
||||
be applied. It has the following attributes/sub-elements:
|
||||
|
||||
:type:
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ repository::
|
|||
By default, the cloned repository will be set to the development branch. To
|
||||
switch to the source of the latest stable release, run the following commands::
|
||||
|
||||
cd openmc/src
|
||||
cd openmc
|
||||
git checkout master
|
||||
|
||||
.. _GitHub: https://github.com/mit-crpg/openmc
|
||||
|
|
@ -132,14 +132,13 @@ following
|
|||
|
||||
.. code-block:: sh
|
||||
|
||||
mkdir src/build
|
||||
cd src/build
|
||||
mkdir build && cd build
|
||||
cmake ..
|
||||
make
|
||||
|
||||
Note that first a build directory is created as a subdirectory of the source
|
||||
directory. The Makefile in ``src/`` will automatically perform an out-of-source
|
||||
build with default options.
|
||||
directory. The Makefile in the top-level directory will automatically perform an
|
||||
out-of-source build with default options.
|
||||
|
||||
CMakeLists.txt Options
|
||||
++++++++++++++++++++++
|
||||
|
|
@ -166,7 +165,7 @@ should be used:
|
|||
|
||||
.. code-block:: sh
|
||||
|
||||
cmake -Ddebug=on /path/to/src
|
||||
cmake -Ddebug=on /path/to/openmc
|
||||
|
||||
Compiling with MPI
|
||||
++++++++++++++++++
|
||||
|
|
@ -177,14 +176,14 @@ the MPI Fortran wrapper. For example, in a bash shell:
|
|||
.. code-block:: sh
|
||||
|
||||
export FC=mpif90
|
||||
cmake /path/to/src
|
||||
cmake /path/to/openmc
|
||||
|
||||
Note that in many shells, an environment variable can be set for a single
|
||||
command, i.e.
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
FC=mpif90 cmake /path/to/src
|
||||
FC=mpif90 cmake /path/to/openmc
|
||||
|
||||
Compiling with HDF5
|
||||
+++++++++++++++++++
|
||||
|
|
@ -195,14 +194,14 @@ the HDF5 Fortran wrapper. For example, in a bash shell:
|
|||
.. code-block:: sh
|
||||
|
||||
export FC=h5fc
|
||||
cmake /path/to/src
|
||||
cmake /path/to/openmc
|
||||
|
||||
As noted above, an environment variable can typically be set for a single
|
||||
command, i.e.
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
FC=h5fc cmake /path/to/src
|
||||
FC=h5fc cmake /path/to/openmc
|
||||
|
||||
To compile with support for both MPI and HDF5, use the parallel HDF5 wrapper
|
||||
``h5pfc`` instead. Note that this requires that your HDF5 installation be
|
||||
|
|
@ -216,8 +215,7 @@ the root directory of the source code:
|
|||
|
||||
.. code-block:: sh
|
||||
|
||||
mkdir src/build
|
||||
cd src/build
|
||||
mkdir build && cd build
|
||||
cmake ..
|
||||
make
|
||||
make install
|
||||
|
|
@ -267,7 +265,8 @@ the source code root directory:
|
|||
|
||||
.. code-block:: sh
|
||||
|
||||
cd src
|
||||
mkdir build && cd build
|
||||
cmake ..
|
||||
make
|
||||
|
||||
This will build an executable named ``openmc``.
|
||||
|
|
@ -293,7 +292,6 @@ in the root directory of the OpenMC distribution:
|
|||
|
||||
.. code-block:: sh
|
||||
|
||||
cd src
|
||||
make
|
||||
|
||||
This will build an executable named ``openmc``.
|
||||
|
|
@ -312,7 +310,6 @@ the source directory and run the following:
|
|||
|
||||
.. code-block:: sh
|
||||
|
||||
cd src
|
||||
make test
|
||||
|
||||
If you want more options for testing you can use ctest_ command. For example,
|
||||
|
|
@ -320,7 +317,7 @@ if we wanted to run only the plot tests with 4 processors, we run:
|
|||
|
||||
.. code-block:: sh
|
||||
|
||||
cd src/build
|
||||
cd build
|
||||
ctest -j 4 -R plot
|
||||
|
||||
If you want to run the full test suite with different build options please
|
||||
|
|
@ -365,12 +362,12 @@ the following steps must be taken:
|
|||
2. In the root directory, a file named ``xsdir``, or some variant thereof,
|
||||
should be present. This file contains a listing of all the cross sections and
|
||||
is used by MCNP. This file should be converted to a ``cross_sections.xml``
|
||||
file for use with OpenMC. A Python script is provided in the OpenMC
|
||||
distribution for this purpose:
|
||||
file for use with OpenMC. A utility is provided in the OpenMC distribution
|
||||
for this purpose:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
openmc/src/utils/convert_xsdir.py xsdir31 cross_sections.xml
|
||||
openmc/scripts/openmc-xsdir-to-xml xsdir31 cross_sections.xml
|
||||
|
||||
3. In the converted ``cross_sections.xml`` file, change the contents of the
|
||||
<directory> element to the absolute path of the directory containing the
|
||||
|
|
@ -416,9 +413,8 @@ Running OpenMC
|
|||
Once you have a model built (see :ref:`usersguide_input`), you can either run
|
||||
the openmc executable directly from the directory containing your XML input
|
||||
files, or you can specify as a command-line argument the directory containing
|
||||
the XML input files. For example, if the path of your OpenMC executable is
|
||||
``/home/username/openmc/src/openmc`` and your XML input files are in the
|
||||
directory ``/home/username/somemodel/``, one way to run the simulation would be:
|
||||
the XML input files. For example, if your XML input files are in the directory
|
||||
``/home/username/somemodel/``, one way to run the simulation would be:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue