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

Merge branch 'develop' into cmake

Browse source
This commit is contained in:
Bryan Herman 2014-03-10 17:43:27 -04:00
commit 71c327eb59
59 changed files with 5823 additions and 398 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -264,7 +264,9 @@ attributes/sub-elements:
:file:
If this attribute is given, it indicates that the source is to be read from
a binary source file whose path is given by the value of this element
a binary source file whose path is given by the value of this element. Note,
the number of source sites needs to be the same as the number of particles
simulated in a fission source generation.
*Default*: None
@ -348,8 +350,10 @@ attributes/sub-elements:
The ``<state_point>`` element indicates at what batches a state point file
should be written. A state point file can be used to restart a run or to get
tally results at any batch. This element has the following
attributes/sub-elements:
tally results at any batch. The default behavior when using this tag is to
write out the source bank in the state_point file. This behavior can be
customized by using the ``<source_point>`` element. This element has the
following attributes/sub-elements:
:batches:
A list of integers separated by spaces indicating at what batches a state
@ -364,19 +368,52 @@ attributes/sub-elements:
*Default*: None
``<source_point>`` Element
--------------------------
The ``<source_point>`` element indicates at what batches the source bank
should be written. The source bank can be either written out within a state
point file or separately in a source point file. This element has the following
attributes/sub-elements:
:batches:
A list of integers separated by spaces indicating at what batches a state
point file should be written. It should be noted that if source_separate
tag is not set to "true", this list must be a subset of state point batches.
*Default*: Last batch only
:interval:
A single integer :math:`n` indicating that a state point should be written
every :math:`n` batches. This option can be given in lieu of listing
batches explicitly. It should be noted that if source_separate tag is not
set to "true", this value should produce a list of batches that is a subset
of state point batches.
*Default*: None
:source_separate:
If this element is set to "true", a separate binary source file will be
If this element is set to "true", a separate binary source point file will be
written. Otherwise, the source sites will be written in the state point
directly.
*Default*: false
:source_write: If this element is set to "false", source sites are not written
to the state point file. This can substantially reduce the size of state
points if large numbers of particles per batch are used.
:source_write:
If this element is set to "false", source sites are not written
to the state point or source point file. This can substantially reduce the
size of state points if large numbers of particles per batch are used.
*Default*: true
:overwrite_latest:
If this element is set to "true", a source point file containing
the source bank will be written out to a separate file named
``source.binary`` or ``source.h5`` depending on if HDF5 is enabled.
This file will be overwritten at every single batch so that the latest
source bank will be available. It should be noted that a user can set both
this element to "true" and specify batches to write a permanent source bank.
``<survival_biasing>`` Element
------------------------------
@ -1052,7 +1089,7 @@ sub-elements:
the PNG format can often times reduce the file size by orders of
magnitude without any loss of image quality. Likewise,
high-resolution voxel files produced by OpenMC can be quite large,
but the equivalent SILO files will by significantly smaller.
but the equivalent SILO files will be significantly smaller.
*Default*: "slice"

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

@ -244,7 +244,15 @@ the root directory of the source code:
sudo make install
This will build an executable named ``openmc`` and install it (by default in
/usr/local/bin).
/usr/local/bin). If you do not have administrative privileges, you can install
OpenMC locally by replacing the last command with:
.. code-block:: sh
make install -e prefix=$HOME/.local
The ``prefix`` variable can be changed to any path for which you have
write-access.
Compiling on Windows
--------------------
@ -320,10 +328,27 @@ 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_. The TALYS-based evaluated nuclear data library, TENDL_, is
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.
Using ENDF/B-VII.1 Cross Sections from NNDC
-------------------------------------------
The NNDC_ provides ACE data from the ENDF/B-VII.1 neutron and thermal scattering
sublibraries at four temperatures processed using NJOY_. To use this data with
OpenMC, a script is provided with OpenMC that will automatically download,
extract, and set up a confiuration file:
.. code-block:: sh
cd openmc/data
python get_nndc_data.py
At this point, you should set the :envvar:`CROSS_SECTIONS` environment variable
to the absolute path of the file ``openmc/data/nndc/cross_sections.xml``.
Using JEFF Cross Sections from OECD/NEA
---------------------------------------
@ -370,6 +395,8 @@ 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.
.. _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
.. _JEFF: http://www.oecd-nea.org/dbdata/jeff/
.. _here: http://www.oecd-nea.org/dbdata/pubs/jeff312-cd.html

106
docs/source/usersguide/processing.rst
View file

@ -5,11 +5,11 @@ Data Processing and Visualization
=================================
This section is intended to explain in detail the recommended procedures for
carrying out common tasks with OpenMC. While several utilities of varying
complexity are provided to help automate the process, in many cases it will be
extremely beneficial to do some coding in Python to quickly obtain results. In
these cases, and for many of the provided utilities, it is necessary for your
Python installation to contain:
carrying out common post-processing tasks with OpenMC. While several utilities
of varying complexity are provided to help automate the process, in many cases
it will be extremely beneficial to do some coding in Python to quickly obtain
results. In these cases, and for many of the provided utilities, it is necessary
for your Python installation to contain:
* [1]_ `Numpy <http://www.numpy.org/>`_
* [1]_ `Scipy <http://www.scipy.org/>`_
@ -41,6 +41,55 @@ Plotting in 2D
.. image:: ../_images/atr.png
:height: 200px
See below for a simple example of a plots xml file that demonstrates the
capabilities of 2D slice plots. Here we assume that there is a ``geometry.xml``
file containing 7 cells.
.. code-block:: xml
<?xml version="1.0" encoding="UTF-8"?>
<plots>
<plot id="1" type="slice" color="cell" basis="xy">
<filename> myplot </filename>
<origin> 0 0 </origin>
<width> 10 10 </width>
<pixels> 2000 2000 </pixels>
<background> 0 0 0 </background>
<col_spec id="1" rgb="198 226 255"/>
<col_spec id="2" rgb="255 218 185"/>
<col_spec id="3" rgb="255 255 255"/>
<col_spec id="4" rgb="101 101 101"/>
<col_spec id="7" rgb="123 123 231"/>
<mask background="255 255 255">
<components> 1 3 4 5 6 </components>
</mask>
</plot>
</plots>
In this example, OpenMC will produce a plot named ``myplot.ppm`` when run in
plotting mode. The picture will be on the xy-plane, depicting the rectangle
between points (-5,-5) and (5,5) with 2000 pixels along each dimension. The
color of each pixel is determined by placing a particle at the center of that
pixel and using OpenMC's internal ``find_cell`` routine (the same one used for
particle tracking during simulation) to determine the cell and material at that
location. In this example, pixels are 10/2000=0.005 cm wide, so points will be
at (-4.9975,-4.9975), (-4.9950,-4.9975), (-4.9925,-4.9975), etc. This is pointed
out to demonstrate that this plot may miss any features smaller than 0.005 cm,
since they could exist between pixel centers. More pixels can be used to resolve
finer features, but could result in larger files.
The ``background``, ``col_spec``, and ``mask`` elements define how to set pixel
colors based on the cell ids at each pixel center. In this example, RGB colors
are specified for cells 1,2,3,4, and 7, a random color will be assigned to cells
5 and 6, and a black background color (``rgb="0 0 0"``) will be applied to
locations where no cell is defined. However, the ``mask`` element here says that
only cells 1,3,4,5, and 6 should be displayed, with other cells taking a white
color (``rgb="255 255 255"``), which overrides the ``col_spec`` for cell 2 and
the random color assigned to cell 7.
After running OpenMC to obtain PPM files, images should be saved to another
format before using them elsewhere. This cuts down the size of the file by
orders of magnitude. Most image viewers and editors that can view PPM images
@ -53,7 +102,7 @@ Ubuntu: ``sudo apt-get install imagemagick``). Images are then converted like:
.. code-block:: sh
convert plot.ppm plot.png
convert myplot.ppm myplot.png
Plotting in 3D
--------------
@ -61,10 +110,37 @@ Plotting in 3D
.. image:: ../_images/3dgeomplot.png
:height: 200px
See below for a simple example of a plots xml file that demonstrates the
capabilities of 3D voxel plots.
.. code-block:: xml
<?xml version="1.0" encoding="UTF-8"?>
<plots>
<plot id="1" type="voxel" color="mat">
<filename> myplot </filename>
<origin> 0 0 0 </origin>
<width> 10 10 10 </width>
<pixels> 500 500 500 </pixels>
</plot>
</plots>
Voxel plots are built the same way 2D slice plots are, by determining the cell
or material id of a particle at the center of each voxel. In this example, the
space covered is the cube between the points (-5,-5,-5) and (5,5,5), with voxel
centers 10/500 = 0.02 cm apart. The binary VOXEL files that are produced do not
specify any color - instead containing only material or cell ids (material id
in this example) - and thus the ``background``, ``col_spec``, and ``mask``
elements are not used. If no cell is found at a voxel center, an id of -1 is
stored.
The binary VOXEL files output by OpenMC can not be viewed directly by any
existing viewers. In order to view them, they must be converted into a standard
mesh format that can be viewed in ParaView, Visit, etc. The provided utility
voxel.py accomplishes this for SILO:
mesh format that can be viewed in ParaView, Visit, etc. This typically will
compress the size of the file significantly. The provided utility voxel.py
accomplishes this for SILO:
.. code-block:: sh
@ -88,13 +164,21 @@ or
Users can process the binary into any other format if desired by following the
example of voxel.py. For the binary file structure, see :ref:`devguide_voxel`.
Once processed into a standard 3D file format, colors and masks can be defined
using the stored id numbers to better explore the geometry. The process for
doing this will depend on the 3D viewer, but should be straightforward.
.. image:: ../_images/3dba.png
:height: 200px
.. note:: 3D voxel plotting can be very computer intensive for the viewing
program (Visit, Paraview, etc.) if the number of voxels is large (>10
million or so). Thus if you want an accurate picture that renders
smoothly, consider using only one voxel in a certain direction. For
instance, the 3D pin lattice figure above was generated with a
500x500x1 voxel mesh, which allows for resolution of the cylinders
without wasting too many voxels on the axial dimension.
instance, the 3D pin lattice figure at the beginning of this section
was generated with a 500x500x1 voxel mesh, which allows for resolution
of the cylinders without wasting too many voxels on the axial
dimension.
-------------------

12
docs/source/usersguide/troubleshoot.rst
View file

@ -79,6 +79,14 @@ with the :envvar:`CROSS_SECTIONS` environment variable. It is recommended to add
a line in your ``.profile`` or ``.bash_profile`` setting the
:envvar:`CROSS_SECTIONS` environment variable.
ERROR: Invalid usage of L(I) in ACE data; Consider using more recent data set.
******************************************************************************
The cross-sections requested in ``materials.xml`` do not conform to the current
standard format. This typically happens with fissionable nuclides in a ``.6*c``
library as distributed with MCNP. Please try a newer library such as any from
the ``.7*c`` set.
Geometry Debugging
******************
@ -107,8 +115,8 @@ have many particles travelling through them there will not be many locations
where overlaps are checked for in that region. The user should refer to the
output after a geometry debug run to see how many checks were performed in each
cell, and then adjust the number of starting particles or starting source
distributions accordingly to achieve good coverage.
distributions accordingly to achieve good coverage.
ERROR: After particle __ crossed surface __ it could not be located in any cell and it did not leak.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^