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

Merge branch 'master' of git@github.com:mit-crpg/openmc

Browse source
This commit is contained in:
Nick Horelik 2012-03-28 09:21:18 -07:00
commit d117a810be
20 changed files with 895 additions and 356 deletions
Download patch file Download diff file Expand all files Collapse all files

18
docs/source/_templates/layout.html Normal file
View file

@ -0,0 +1,18 @@
{% extends "!layout.html" %}
{% block footer %}
{{ super() }}
<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-30411614-1']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
{% endblock %}

6
docs/source/conf.py
View file

@ -39,16 +39,16 @@ master_doc = 'index'
# General information about the project.
project = u'OpenMC'
copyright = u'2011, Massachusetts Institute of Technology'
copyright = u'2011-2012, Massachusetts Institute of Technology'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The short X.Y version.
version = "0.3"
version = "0.4"
# The full version, including alpha/beta/rc tags.
release = "0.3.2"
release = "0.4.2"
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.

4
docs/source/developers.rst
View file

@ -8,6 +8,7 @@ Active development of the OpenMC Monte Carlo code is currently led by:
* `Paul Romano`_
* `Bryan Herman`_
* `Nick Horelik`_
Advisors to the project include:
@ -15,8 +16,9 @@ Advisors to the project include:
* `Kord Smith`_
* `Andrew Siegel`_
.. _Paul Romano: mailto:romano7@mit.edu
.. _Paul Romano: mailto:paul.k.romano@gmail.com
.. _Bryan Herman: mailto:bherman@mit.edu
.. _Nick Horelik: mailto:nhorelik@mit.edu
.. _Benoit Forget: mailto:bforget@mit.edu
.. _Kord Smith: mailto:kord@mit.edu
.. _Andrew Siegel: mailto:siegela@mcs.anl.gov

16
docs/source/devguide/index.rst Normal file
View file

@ -0,0 +1,16 @@
.. _devguide:
=================
Developer's Guide
=================
Welcome to the OpenMC Developer's Guide! This guide documents and explains the
structure of the OpenMC source code and how to do various development tasks such
as debugging.
.. toctree::
:numbered:
:maxdepth: 2
structures
xml-fortran

6
docs/source/devguide/structures.rst Normal file
View file

@ -0,0 +1,6 @@
.. _devguide_structures:
===============
Data Structures
===============

6
docs/source/devguide/xml-fortran.rst Normal file
View file

@ -0,0 +1,6 @@
.. _devguide_xml-fortran:
=========================
xml-fortran Input Parsing
=========================

13
docs/source/index.rst
View file

@ -8,14 +8,13 @@ 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.
The development of OpenMC began at the `Massachusetts Institute of Technology`_
within the `Computational Reactor Physics Group`_.
The development of OpenMC is led by the `Computational Reactor Physics Group`_
at the `Massachusetts Institute of Technology`_. For more information on OpenMC,
feel free to contact `Paul Romano`_.
For more information on OpenMC, feel free to contact `Paul Romano`_.
.. _Massachusetts Institute of Technology: http://web.mit.edu
.. _Computational Reactor Physics Group: http://crpg.mit.edu
.. _Paul Romano: mailto:romano7@mit.edu
.. _Massachusetts Institute of Technology: http://web.mit.edu
.. _Paul Romano: mailto:paul.k.romano@gmail.com
--------
Contents
@ -28,4 +27,6 @@ Contents
releasenotes/index
methods/index
usersguide/index
devguide/index
publications
developers

24
docs/source/methods/geometry.rst Normal file
View file

@ -0,0 +1,24 @@
.. _methods_geometry:
========
Geometry
========
-------------------
Reflective Surfaces
-------------------
In general, a surface can be written in the form :math:`f(x,y,z) = 0`. If a
neutron is traveling in direction :math:`\vec{v}` and crosses a reflective
surface of the above form, it can be shown that the velocity vector will then
become
.. math::
\mathbf{v'} = \mathbf{v} - 2 (\mathbf{v} \cdot \hat{\mathbf{n}})
\hat{\mathbf{n}}
where :math:`\hat{\mathbf{n}}` is a unit vector normal to the surface at the
point of the surface crossing. The direction of the surface normal will be the
gradient to the surface at the point of crossing, i.e. :math:`\mathbf{n} =
\nabla f(x,y,z)`.

120
docs/source/methods/index.rst
View file

@ -1,118 +1,18 @@
.. _methods:
===========
Methodology
===========
======================
Theory and Methodology
======================
The OpenMC code solves the neutron transport equation using the Monte Carlo
method whereby particles are tracked as they randomly move through a geometry,
undergoing collisions, and creating secondary particles.
-------------------
Reflective Surfaces
-------------------
.. toctree::
:numbered:
:maxdepth: 2
In general, a surface can be written in the form :math:`f(x,y,z) = 0`. If a
neutron is traveling in direction :math:`\vec{v}` and crosses a reflective
surface of the above form, it can be shown that the velocity vector will then
become
.. math::
\mathbf{v'} = \mathbf{v} - 2 (\mathbf{v} \cdot \hat{\mathbf{n}})
\hat{\mathbf{n}}
where :math:`\hat{\mathbf{n}}` is a unit vector normal to the surface at the
point of the surface crossing. The direction of the surface normal will be the
gradient to the surface at the point of crossing, i.e. :math:`\mathbf{n} =
\nabla f(x,y,z)`.
------------------------------
Free Gas Scattering Kinematics
------------------------------
When a neutron scatters off of a nucleus, many times it is assumed that the
target nucleus is at rest. However, if the material is at a temperature greater
than 0 K, it will have motion associated with the thermal vibration. Thus, the
velocity of the neutrno relative to the target nucleus is in general not the
same as the velocity of the neutron entering the collision.
The affect of the thermal motion on the interaction probability can be written
as
.. math::
:label: freegas1
v_n \sigma (v_n, T) = \int_0^\infty d\mathbf{v}_T \sigma(v_r, 0)
\mathbf{v}_r p(\mathbf{v}_T)
One assumption we can make here is that the velocity distribution for the
thermal motion is isotropic, i.e.
.. math::
:label: freegas2
p(\mathbf{v}_T) d\mathbf{v}_T = \frac{1}{4\pi} p(v_T) dv_T d\mu d\phi
With this assumption, we can now rewrite equation :eq:`freegas1` as
.. math::
:label: freegas3
v_n \sigma (v_n, T) = \frac{1}{2} \int_{-1}^1 d\mu \int\limits_{v_r > 0}
v_r \sigma (v_r, 0) p(v_T) dv_T
To change the outer variable of integration from :math:`\mu` to :math:`v_r`, we
can establish a relation between these variables based on the law of cosines.
.. math::
:label: lawcosine
2 v_n v_T \mu = v_n^2 + v_T^2 - v_r^2
The probability distribution for the magnitude of the velocity of the target
nucleus and the angle between the neutron and target velocity is
.. math::
:label: freegas4
P(v_T, \mu) = \frac{\sigma (v_r, 0) v_r P(v_T)}{2 \sigma (v_n, T) v_n}
It is normally assumed that :math:`\sigma (v_r, 0)` is constant over the range
of relative velocities of interest. This is a good assumption for almost all
cases since the elastic scattering cross section varies slowly with velocity for
light nuclei, and for heavy nuclei where large variations can occur due to
resonance scattering, the moderating effect is rather small. Nonetheless, this
assumption can cause incorrect answers in systems with U-238 where the low-lying
resonances can cause a significant amount of upscatter that would be ignored by
this assumption.
With this (sometimes incorrect) assumption, we see that the probability
distribution is proportional to
.. math::
:label: freegas5
P(v_T, \mu) \propto v_r P(v_T) = | v_n - v_T | P(v_T)
We can divide this probability distribution into two parts as such:
.. math::
:label: freegas6
P(v_T, \mu) &= f_1(v_T, \mu) f_2(v_T) \\
f_1(v_T, \mu) &= \frac{| v_n - v_T |}{\hat{f_1} (v_n + v_T)} \\
f_2(v_T) &= (v_n + v_T) P(v_T)
In general, any probability distribution function of the form :math:`p(x) =
f_1(x) f_2(x)` with :math:`f_1(x)` bounded can be sampled by sampling
:math:`x_s` from the distribution
.. math:: \frac{f_2(x)}{\int f_2(x) dx}
and accepting it with probability
.. math:: \frac{f_1(x_s)}{\max f_1(x)}
It is normally assumed that the velocity distribution of the target nucleus
assumes a Maxwellian distribution in velocity.
introduction
geometry
physics
tallies

10
docs/source/methods/introduction.rst Normal file
View file

@ -0,0 +1,10 @@
.. _methods_introduction:
============
Introduction
============
---------------------
Criticality Algorithm
---------------------

95
docs/source/methods/physics.rst Normal file
View file

@ -0,0 +1,95 @@
.. _methods_physics:
=======
Physics
=======
------------------------------
Free Gas Scattering Kinematics
------------------------------
When a neutron scatters off of a nucleus, many times it is assumed that the
target nucleus is at rest. However, if the material is at a temperature greater
than 0 K, it will have motion associated with the thermal vibration. Thus, the
velocity of the neutrno relative to the target nucleus is in general not the
same as the velocity of the neutron entering the collision.
The affect of the thermal motion on the interaction probability can be written
as
.. math::
:label: freegas1
v_n \sigma (v_n, T) = \int_0^\infty d\mathbf{v}_T \sigma(v_r, 0)
\mathbf{v}_r p(\mathbf{v}_T)
One assumption we can make here is that the velocity distribution for the
thermal motion is isotropic, i.e.
.. math::
:label: freegas2
p(\mathbf{v}_T) d\mathbf{v}_T = \frac{1}{4\pi} p(v_T) dv_T d\mu d\phi
With this assumption, we can now rewrite equation :eq:`freegas1` as
.. math::
:label: freegas3
v_n \sigma (v_n, T) = \frac{1}{2} \int_{-1}^1 d\mu \int\limits_{v_r > 0}
v_r \sigma (v_r, 0) p(v_T) dv_T
To change the outer variable of integration from :math:`\mu` to :math:`v_r`, we
can establish a relation between these variables based on the law of cosines.
.. math::
:label: lawcosine
2 v_n v_T \mu = v_n^2 + v_T^2 - v_r^2
The probability distribution for the magnitude of the velocity of the target
nucleus and the angle between the neutron and target velocity is
.. math::
:label: freegas4
P(v_T, \mu) = \frac{\sigma (v_r, 0) v_r P(v_T)}{2 \sigma (v_n, T) v_n}
It is normally assumed that :math:`\sigma (v_r, 0)` is constant over the range
of relative velocities of interest. This is a good assumption for almost all
cases since the elastic scattering cross section varies slowly with velocity for
light nuclei, and for heavy nuclei where large variations can occur due to
resonance scattering, the moderating effect is rather small. Nonetheless, this
assumption can cause incorrect answers in systems with U-238 where the low-lying
resonances can cause a significant amount of upscatter that would be ignored by
this assumption.
With this (sometimes incorrect) assumption, we see that the probability
distribution is proportional to
.. math::
:label: freegas5
P(v_T, \mu) \propto v_r P(v_T) = | v_n - v_T | P(v_T)
We can divide this probability distribution into two parts as such:
.. math::
:label: freegas6
P(v_T, \mu) &= f_1(v_T, \mu) f_2(v_T) \\
f_1(v_T, \mu) &= \frac{| v_n - v_T |}{\hat{f_1} (v_n + v_T)} \\
f_2(v_T) &= (v_n + v_T) P(v_T)
In general, any probability distribution function of the form :math:`p(x) =
f_1(x) f_2(x)` with :math:`f_1(x)` bounded can be sampled by sampling
:math:`x_s` from the distribution
.. math:: \frac{f_2(x)}{\int f_2(x) dx}
and accepting it with probability
.. math:: \frac{f_1(x_s)}{\max f_1(x)}
It is normally assumed that the velocity distribution of the target nucleus
assumes a Maxwellian distribution in velocity.

17
docs/source/methods/tallies.rst Normal file
View file

@ -0,0 +1,17 @@
.. _methods_tallies:
=======
Tallies
=======
----------------
Analog Estimator
----------------
----------------------
Track-length Estimator
----------------------
---------------
Surface Current
---------------

17
docs/source/publications.rst Normal file
View file

@ -0,0 +1,17 @@
.. _publications:
============
Publications
============
- Paul K. Romano and Beonit Forget, "The OpenMC Monte Carlo Particle Transport
Code," *Annals of Nuclear Energy*, Submitted (2012).
- Andrew R. Siegel, Kord Smith, Paul K. Romano, Benoit Forget, and Kyle Felker,
"The effect of load imbalances on the performance of Monte Carlo codes in LWR
analysis", *Journal of Computational Physics*, Submitted (2012).
- Paul K. Romano and Benoit Forget, "Parallel Fission Bank Algorithms in Monte
Carlo Criticality Calculations," *Nuclear Science and Engineering*, **170**,
pp. 125--135 (2012). [`PDF
<http://web.mit.edu/romano7/www/nse_v170_n2_pp125-135.pdf>`_]

9
docs/source/releasenotes/notes_0.4.2.rst
View file

@ -22,6 +22,9 @@ hand (mostly on the number of nuclides in the problem).
New Features
------------
- Reading/writing binary source files.
- Added more messages for <trace> or high verbosity.
- Estimator for diffusion coefficient.
- Ability to specify 'point' source type.
- Ability to change random number seed.
- User's can now specify units='sum' on a <density> tag. This tells the code
@ -32,6 +35,12 @@ New Features
Bug Fixes
---------
- `b2c40e`_: Fixed bug in incoming energy filter for track-length tallies.
- `5524fd`_: Mesh filter now works with track-length tallies.
- `d050c7`_: Added Bessel's correction to make estimate of variance unbiased.
- `2a5b9c`_: Fixed regression in plotting.
.. _b2c40e: https://github.com/mit-crpg/openmc/commit/b2c40e
.. _5524fd: https://github.com/mit-crpg/openmc/commit/5524fd
.. _d050c7: https://github.com/mit-crpg/openmc/commit/d050c7
.. _2a5b9c: https://github.com/mit-crpg/openmc/commit/2a5b9c

156
docs/source/usersguide/beginners.rst Normal file
View file

@ -0,0 +1,156 @@
.. _usersguide_beginners:
============================
A Beginner's Guide to OpenMC
============================
--------------------
What does OpenMC do?
--------------------
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
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
behavior of these neutrons (or the behavior of the energy produced or any other
quantity one is interested in) very accurately.
Using Monte Carlo methods to determine the average behavior of various physical
quantities in a nuclear reactor is quite different from other means of solving
the same problem. The other class of methods for determining the behavior of
neutrons and reactions rates in a reactor is so-called `determinstic`_
methods. In these methods, the starting point is not randomly simulating
particles but rather writing an equation that describes the average behavior of
the particles. The equation that describes the average behavior of neutrons is
called the `neutron transport`_ equation. This equation is a seven-dimensional
equation (three for space, three for velocity, and one for time) and is very
difficult to solve directly. For all but the simplest problems, it is necessary
to make some sort of `discretization`_. As an example, we can divide up all
space into small sections which are homogeneous and then solve the equation on
those small sections. After these discretizations and various approximations,
one can arrive at forms that are suitable for solution on a computer. Among
these are discrete ordinates, method of characteristics, finite-difference
diffusion, and nodal methods.
So why choose Monte Carlo over deterministic methods? Each method has its pros
and cons. Let us first take a look at few of the salient pros and cons of
deterministic methods:
- **Pro**: Depending on what method is used, solution can be determined very
quickly.
- **Pro**: The solution is a global solution, i.e. we know the average behavior
everywhere.
- **Pro**: Once the problem is converged, the solution is known.
- **Con**: If the model is complex, it is necessary to do sophisticated mesh
generation.
- **Con**: It is necessary to generate multi-group cross sections which requires
knowing the solution *a priori*.
Now let's look at the pros and cons of Monte Carlo methods:
- **Pro**: No mesh generation is required to build geometry. By using
`constructive solid geometry`_, it's possible to build arbitrarily complex
models with curved surfaces.
- **Pro**: Monte Carlo methods can be used with either continuous-energy or
multi-group cross sections.
- **Pro**: Running simulations in parallel is conceptually very simple.
- **Con**: Because they related on repeated random sampling, they are
computationally very expensive.
- **Con**: A simulation doesn't automatically give you the global solution
everywhere -- you have to specifically ask for those quantities you want.
- **Con**: Even after the problem is converged, it is necessary to simulate
many particles to reduce stochastic uncertainty.
Because fewer approximations are made in solving a problem by the Monte Carlo
method, it is often seen as a "gold standard" which can be used as a benchmark
for a solution of the same problem by deterministic means. However, it comes at
the expense of a potentially longer simulation.
-----------------
How does it work?
-----------------
In order to do anything, the code first needs to have a model of some problem of
interest. This could be a nuclear reactor or any other physical system with
fissioning material. You, as the code user, will need to describe the model so
that the code can do something with it. A basic model consists of a few things:
- A description of the geometry -- the problem should be split up into regions
of homogeneous material.
- For each different material in the problem, a description of what nuclides are
in the material and at what density.
- Various parameters telling the code how many particles to simulate and what
options to use.
- A list of different physical quantities that the code should return at the end
of the simulation. Remember, in a Monte Carlo simulation, if you don't ask for
anything, it will not give you any answers (other than a few default
quantities).
-----------------------
What do I need to know?
-----------------------
If you are starting to work with OpenMC, there are a few things you should be
familiar with. Whether you plan on working in Linux, Mac OS X, or Windows, you
should be comfortable working in a command line environment. There are many
resources online for learning command line environments. If you are using Linux
or Mac OS X (also Unix-derived), `this tutorial
<http://www.ee.surrey.ac.uk/Teaching/Unix/>`_ will help you get acquianted with
commonly-used commands.
OpenMC uses a version control software called `git`_ to keep track of changes to
the code, document bugs and issues, and other development tasks. While you don't
necessarily have to have git installed in order to download and run OpenMC, it
makes it much easier to receive updates if you do have it installed and have a
basic understanding of how it works. There are a list of good `git tutorials`_
at the git documentation website. The `OpenMC source code`_ and documentation
are hosted at `GitHub`_. In order to receive updates to the code directly,
submit `bug reports`_, and perform other development tasks, you may want to sign
up for a free account on GitHub. Once you have an account, you can follow `these
instructions <http://help.github.com/set-up-git-redirect>`_ on how to set up
your computer for using GitHub.
If you are new to nuclear engineering, you may want to review the NRC's `Reactor
Concepts Manual`_. This manual describes the basics of nuclear power for
electricity generation, the fission process, and the overall systems in a
pressurized or boiling water reactor. Another resource that is a bit more
technical than the Reactor Concepts Manual but still at an elementary level is
the DOE Fundamentals Handbook on Nuclear Physics and Reactor Theory `Volume I`_
and `Volume II`_. You may also find it helpful to review the following terms:
- `Neutron cross section`_
- `Effective multiplication factor`_
- `Flux`_
.. _nuclear reactor: http://en.wikipedia.org/wiki/Nuclear_reactor
.. _Monte Carlo: http://en.wikipedia.org/wiki/Monte_Carlo_method
.. _fission: http://en.wikipedia.org/wiki/Nuclear_fission
.. _determinstic: http://en.wikipedia.org/wiki/Deterministic_algorithm
.. _neutron transport: http://en.wikipedia.org/wiki/Neutron_transport
.. _discretization: http://en.wikipedia.org/wiki/Discretization
.. _constructive solid geometry: http://en.wikipedia.org/wiki/Constructive_solid_geometry
.. _git: http://git-scm.com/
.. _git tutorials: http://git-scm.com/documentation
.. _Reactor Concepts Manual: http://web.mit.edu/romano7/www/reactor_concepts.pdf
.. _Volume I: http://www.hss.doe.gov/nuclearsafety/techstds/docs/handbook/h1019v1.pdf
.. _Volume II: http://www.hss.doe.gov/nuclearsafety/techstds/docs/handbook/h1019v2.pdf
.. _OpenMC source code: https://github.com/mit-crpg/openmc
.. _GitHub: https://github.com/
.. _bug reports: https://github.com/mit-crpg/openmc/issues
.. _Neutron cross section: http://en.wikipedia.org/wiki/Neutron_cross_section
.. _Effective multiplication factor: http://en.wikipedia.org/wiki/Effective_multiplication_factor
.. _Flux: http://en.wikipedia.org/wiki/Neutron_flux

6
docs/source/usersguide/index.rst
View file

@ -8,6 +8,10 @@ Welcome to the OpenMC User's Guide! This tutorial will guide you through the
essential aspects of using OpenMC to perform neutronic simulations.
.. toctree::
:maxdepth: 2
:numbered:
:maxdepth: 3
beginners
setup
input
troubleshoot

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

@ -1,8 +1,8 @@
.. _usersguide_input:
========================
Creating XML Input Files
========================
=======================
Writing XML Input Files
=======================
Unlike many other Monte Carlo codes which use an arbitrary-format ASCII file
with "cards" to specify a particular geometry, materials, and associated run
@ -12,7 +12,9 @@ to be exchanged efficiently between different programs and interfaces.
Anyone who has ever seen webpages written in HTML will be familiar with the
structure of XML whereby "tags" enclosed in angle brackets denote that a
particular piece of data will follow. Let us examine the follow example::
particular piece of data will follow. Let us examine the follow example:
.. code-block:: xml
<person>
<firstname>John</firstname>
@ -35,14 +37,190 @@ Overview of Files
-----------------
To assemble a complete model for OpenMC, one needs to create separate XML files
for the geometry, materials, and settings. Additionally, an optional tallies XML
file specifies physical quantities to be tallied. OpenMC expects that these
files are called:
for the geometry, materials, and settings. Additionally, there are two optional
input files. The first is a tallies XML file that specifies physical quantities
to be tallied. The second is a plots XML file that specifies regions of geometry
which should be plotted. OpenMC expects that these files are called:
* ``geometry.xml``
* ``materials.xml``
* ``setings.xml``
* ``tallies.xml``
* ``plots.xml``
--------------------------------------
Settings Specification -- settings.xml
--------------------------------------
All simulation parameters and miscellaneous options are specified in the
settings.xml file.
``<criticality>`` Element
-------------------------
The ``<criticality>`` element indicates that a criticality calculation should be
performed. It has the following attributes/sub-elements:
:batches:
The total number of batches, where each batch corresponds to multiple
fission source iterations. Batching is done to eliminate correlation between
realizations of random variables.
*Default*: None
:generations_per_batch:
The number of total fission source iterations per batch.
*Default*: 1
:inactive:
The number of inactive batches. In general, the starting cycles in a
criticality calculation can not be used to contribute to tallies since the
fission source distribution and eigenvalue are generally not converged
immediately.
*Default*: None
:particles:
The number of neutrons to simulate per fission source iteration.
*Default*: None
.. _cross_sections:
``<cross_sections>`` Element
----------------------------
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.
``<cutoff>`` Element
--------------------
The ``<cutoff>`` element indicates the weight cutoff used below which particles
undergo Russian roulette. Surviving particles are assigned a user-determined
weight. Note that weight cutoffs and Russian rouletting are not turned on by
default. This element has the following attributes/sub-elements:
:weight:
The weight below which particles undergo Russian roulette.
*Default*: 0.25
:weight_avg:
The weight that is assigned to particles that are not killed after Russian
roulette.
*Default*: 1.0
``<energy_grid>`` Element
-------------------------
The ``<energy_grid>`` element determines the treatment of the energy grid during
a simulation. Setting this element to "nuclide" will cause OpenMC to use a
nuclide's energy grid when determining what points to interpolate between for
determining cross sections (i.e. non-unionized energy grid). To use a unionized
energy grid, set this element to "union". Note that the unionized energy grid
treatment is slightly different than that employed in Serpent.
*Default*: union
``<entropy>`` Element
---------------------
The ``<entropy>`` element describes a mesh that is used for calculting Shannon
entropy. This mesh should cover all possible fissionable materials in the
problem. It has the following attributes/sub-elements:
:dimension:
The number of mesh cells in the x, y, and z directions, respectively.
*Default*: If this tag is not present, the number of mesh cells is
automatically determined by the code.
:lower_left:
The Cartersian coordinates of the lower-left corner of the mesh.
*Default*: None
:upper_right:
The Cartersian coordinates of the upper-right corner of the mesh.
*Default*: None
``<ptables>`` Element
---------------------
The ``<ptables>`` element determines whether probability tables should be used
in the unresolved resonance range if available. This element has no attributes
or sub-elements and can be set to either "off" or "on".
*Default*: on
``<seed>`` Element
------------------
The ``seed`` element is used to set the seed used for the linear congruential
pseudo-random number generator.
*Default*: 1
``<source>`` Element
--------------------
The ``source`` element gives information on an initial source guess for
criticality calculations. It takes the following attributes:
:type:
The type of source distribution. Setting this to "box" indicates that the
starting source should be sampled uniformly in a parallelepiped. Setting
this to "point" indicates that the starting source should be sampled from an
isotropic point source. Setting this to "file" indicates that the starting
source should be sampled from a ``source.binary`` file.
:coeffs:
For a "box" source distribution, ``coeffs`` should be given as six real
numbers, the first three of which specify the lower-left corner of a
parallelepiped and the last three of which specify the upper-right
corner. Source sites are sampled uniformly through that parallelepiped.
For a "point" source distribution, ``coeffs`` should be given as three real
numbers which specify the (x,y,z) location of an isotropic point source
For a "file" source distribution, ``coeffs`` should not be specified.
``<survival_biasing>`` Element
------------------------------
The ``<survival_biasing>`` element has no attributes and assumes wither the
value ``on`` or ``off``. If turned on, this option will enable the use of
survival biasing, otherwise known as implicit capture or absorption.
*Default*: off
``<trace>`` Element
-------------------
The ``<trace>`` element can be used to print out detailed information about a
single particle during a simulation. This element should be followed by three
integers: the batch number, generation number, and particle number.
*Default*: None
``<verbosity>`` Element
-----------------------
The ``<verbosity>`` element tells the code how much information to display to
the standard output. A higher verbosity corresponds to more information being
displayed. This element takes the following attributes:
:value:
The specified verbosity between 1 and 10.
*Default*: 5
--------------------------------------
Geometry Specification -- geometry.xml
@ -57,9 +235,11 @@ bounding surfaces.
Every geometry.xml must have an XML declaration at the beginning of the file and
a root element named geometry. Within the root element the user can define any
number of cells, surfaces, and lattices. Let us look at the following example::
number of cells, surfaces, and lattices. Let us look at the following example:
<?xml version="1.0">
.. code-block:: xml
<?xml version="1.0"?>
<geometry>
<!-- This is a comment -->
@ -83,7 +263,9 @@ At the beginning of this file is a comment, denoted by a tag starting with
may span multiple lines. One convenient feature of the XML input format is that
sub-elements of the ``cell`` and ``surface`` elements can also be equivalently
expressed of attributes of the original element, e.g. the geometry file above
could be written as::
could be written as:
.. code-block:: xml
<?xml version="1.0">
<geometry>
@ -94,10 +276,10 @@ could be written as::
</geometry>
``surface`` Element
-------------------
``<surface>`` Element
---------------------
Each ``surface`` element can have the following attributes or sub-elements:
Each ``<surface>`` element can have the following attributes or sub-elements:
:id:
A unique integer that can be used to identify the surface.
@ -105,8 +287,8 @@ Each ``surface`` element can have the following attributes or sub-elements:
*Default*: None
:type:
The type of the surfaces. This can be ``x-plane``, ``y-plane``, ``z-plane``,
``plane``, ``x-cylinder``, ``y-cylinder``, ``z-cylinder``, or ``sphere``.
The type of the surfaces. This can be "x-plane", "y-plane", "z-plane",
"plane", "x-cylinder", "y-cylinder", "z-cylinder", or "sphere".
*Default*: None
@ -117,10 +299,10 @@ Each ``surface`` element can have the following attributes or sub-elements:
*Default*: None
:boundary:
The boundary condition for the surface. This can be ``transmission``,
``vacuum``, or ``reflective``.
The boundary condition for the surface. This can be "transmission",
"vacuum", or "reflective".
*Default*: ``transmission``
*Default*: "transmission"
The following quadratic surfaces can be modeled:
@ -159,10 +341,10 @@ The following quadratic surfaces can be modeled:
A sphere of the form :math:`(x - x_0)^2 + (y - y_0)^2 + (z - z_0)^2 =
R^2`. The coefficients specified are ":math:`x_0 \: y_0 \: z_0 \: R`".
``cell`` Element
----------------
``<cell>`` Element
------------------
Each ``cell`` element can have the following attributes or sub-elements:
Each ``<cell>`` element can have the following attributes or sub-elements:
:id:
A unique integer that can be used to identify the surface.
@ -195,13 +377,13 @@ Each ``cell`` element can have the following attributes or sub-elements:
*Default*: None
``lattice`` Element
-------------------
``<lattice>`` Element
---------------------
The ``lattice`` can be used to represent repeating structures (e.g. fuel pins in
an assembly) or other geometry which naturally fits into a two-dimensional
The ``<lattice>`` can be used to represent repeating structures (e.g. fuel pins
in an assembly) or other geometry which naturally fits into a two-dimensional
structured mesh. Each cell within the lattice is filled with a specified
universe. A ``lattice`` accepts the following attributes or sub-elements:
universe. A ``<lattice>`` accepts the following attributes or sub-elements:
:id:
A unique integer that can be used to identify the surface.
@ -240,8 +422,8 @@ universe. A ``lattice`` accepts the following attributes or sub-elements:
Materials Specification -- materials.xml
----------------------------------------
``material`` Element
--------------------
``<material>`` Element
----------------------
Each ``material`` element can have the following attributes or sub-elements:
@ -249,12 +431,13 @@ Each ``material`` element can have the following attributes or sub-elements:
A unique integer that can be used to identify the material.
: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", or "atom/cm3". For example, this could
be specified as::
<density value="4.5" units="g/cm3" />
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.
*Default*: None
@ -282,182 +465,18 @@ Each ``material`` element can have the following attributes or sub-elements:
*Default*: None
``default_xs`` Element
----------------------
``<default_xs>`` Element
------------------------
In some circumstances, the cross-section identifier may be the same for many or
all nuclides in a given problem. In this case, rather than specifying the
``xs=...`` attribute on every nuclide, a ``default_xs`` element can be used to
``xs=...`` attribute on every nuclide, a ``<default_xs>`` element can be used to
set the default cross-section identifier for any nuclide without an identifier
explicitly listed. This element has no attributes and accepts a 3-letter string
that indicates the default cross-section identifier, e.g. "70c".
*Default*: None
--------------------------------------
Settings Specification -- settings.xml
--------------------------------------
All simulation parameters and miscellaneous options are specified in the
settings.xml file.
``criticality`` Element
-----------------------
The ``criticality`` element indicates that a criticality calculation should be
performed. It has the following attributes/sub-elements:
:batches:
The total number of batches, where each batch corresponds to multiple
fission source iterations. Batching is done to eliminate correlation between
realizations of random variables.
*Default*: None
:generations_per_batch:
The number of total fission source iterations per batch.
*Default*: 1
:inactive:
The number of inactive batches. In general, the starting cycles in a
criticality calculation can not be used to contribute to tallies since the
fission source distribution and eigenvalue are generally not converged
immediately.
*Default*: None
:particles:
The number of neutrons to simulate per fission source iteration.
*Default*: None
``cross_sections`` Element
--------------------------
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 environment variable
``CROSS_SECTIONS`` will be used to find the path to the XML cross section
listing.
``cutoff`` Element
------------------
The ``cutoff`` element indicates the weight cutoff used below which particles
undergo Russian roulette. Surviving particles are assigned a user-determined
weight. Note that weight cutoffs and Russian rouletting are not turned on by
default. This element has the following attributes/sub-elements:
:weight:
The weight below which particles undergo Russian roulette.
*Default*: 0.25
:weight_avg:
The weight that is assigned to particles that are not killed after Russian
roulette.
*Default*: 1.0
``energy_grid`` Element
-----------------------
The ``energy_grid`` element determines the treatment of the energy grid during a
simulation. Setting this element to "nuclide" will cause OpenMC to use a
nuclide's energy grid when determining what points to interpolate between for
determining cross sections (i.e. non-unionized energy grid). To use a unionized
energy grid, set this element to "union". Note that the unionized energy grid
treatment is slightly different than that employed in Serpent.
*Default*: union
``entropy`` Element
-------------------
This element describes a mesh that is used for calculting Shannon entropy. This
mesh should cover all possible fissionable materials in the problem. It has the
following attributes/sub-elements:
:dimension:
The number of mesh cells in the x, y, and z directions, respectively.
*Default*: If this tag is not present, the number of mesh cells is
automatically determined by the code.
:lower_left:
The Cartersian coordinates of the lower-left corner of the mesh.
*Default*: None
:upper_right:
The Cartersian coordinates of the upper-right corner of the mesh.
*Default*: None
``ptables`` Element
-------------------
The ``ptables`` element determines whether probability tables should be used in
the unresolved resonance range if available. This element has no attributes or
sub-elements and can be set to either "off" or "on".
*Default*: on
``seed`` Element
----------------
The ``seed`` element is used to set the seed used for the linear congruential
pseudo-random number generator.
*Default*: 1
``source`` Element
------------------
The ``source`` element gives information on an initial source guess for
criticality calculations. It takes the following attributes:
:type:
The type of source distribution. Currently, the only accepted option is
"box"
:coeffs:
For a "box" source distribution, ``coeffs`` should be given as six integers,
the first three of which specify the lower-left corner of a parallelepiped
and the last three of which specify the upper-right corner. Source sites are
sampled uniformly through that parallelepiped.
``survival_biasing`` Element
----------------------------
The ``survival_biasing`` element has no attributes and assumes wither the
value ``on`` or ``off``. If turned on, this option will enable the use of
survival biasing, otherwise known as implicit capture or absorption.
*Default*: off
``trace`` Element
-----------------
The ``trace`` element can be used to print out detailed information about a
single particle during a simulation. This element should be followed by two
integers, the cycle and one for the particle number.
*Default*: None
``verbosity`` Element
---------------------
The ``verbosity`` element tells the code how much information to display to the
standard output. A higher verbosity corresponds to more information being
displayed. This element takes the following attributes:
:value:
The specified verbosity between 1 and 10.
*Default*: 5
------------------------------------
Tallies Specification -- tallies.xml
------------------------------------
@ -476,12 +495,12 @@ filters can be used for a tally. The following types of filter are available:
cell, universe, material, surface, birth region, pre-collision energy,
post-collision energy, and an arbitrary structured mesh.
The two valid elements in the tallies.xml file are ``tally`` and ``mesh``.
The two valid elements in the tallies.xml file are ``<tally>`` and ``<mesh>``.
``tally`` Element
-----------------
``<tally>`` Element
-------------------
The ``tally`` element accepts the following sub-elements:
The ``<tally>`` element accepts the following sub-elements:
:filters:
A list of filters to specify what region of phase space should contribute to
@ -561,11 +580,11 @@ The following responses can be tallied.
:nu-fission:
Total production of neutrons due to fission
``mesh`` Element
----------------
``<mesh>`` Element
------------------
If a structured mesh is desired as a filter for a tally, it must be specified in
a separate element with the tag name ``mesh``. This element has the following
a separate element with the tag name ``<mesh>``. This element has the following
attributes/sub-elements:
:type:
@ -582,8 +601,8 @@ attributes/sub-elements:
:width:
The width of mesh cells in each direction.
``assume_separate`` Element
---------------------------
``<assume_separate>`` Element
-----------------------------
In cases where the user needs to specify many different tallies each of which
are spatially separate, this tag can be used to cut down on some of the tally
@ -596,16 +615,16 @@ tallies. This element should be followed by "yes" or "no"
*Default*: no
-------------------------------------------
Geometry Plotting Specification -- plot.xml
-------------------------------------------
--------------------------------------------
Geometry Plotting Specification -- plots.xml
--------------------------------------------
A basic 2D plotting capability is available in OpenMC by creating a
plots.xml file and subsequently running with the command-line flag ``-plot``. The
root element of the plot.xml is simply ``<plots>`` and any number output
figures can be defined with ``<plot>`` sub-elements.
A basic 2D plotting capability is available in OpenMC by creating a plots.xml
file and subsequently running with the command-line flag ``-plot``. The root
element of the plots.xml is simply ``<plots>`` and any number output figures can
be defined with ``<plot>`` sub-elements.
``plot`` Element
``<plot>`` Element
------------------
Each plot must contain a combination of the following attributes or sub-elements:
@ -627,14 +646,14 @@ Each plot must contain a combination of the following attributes or sub-elements
*Default*: ``cell``
:origin:
Specifies the XYZ coordinate of the center of the plot. Should be 3 floats
separated by spaces.
Specifies the (x,y,z) coordinate of the center of the plot. Should be three
floats separated by spaces.
*Default*: None - Required entry
:width:
Specifies the width of the plot along each of the basis directions.
Should be 2 or 3 floats separated by spaces for 2D plots and 3D plots,
Specifies the width of the plot along each of the basis directions. Should
be two or three floats separated by spaces for 2D plots and 3D plots,
respectively.
*Default*: None - Required entry
@ -652,18 +671,18 @@ Each plot must contain a combination of the following attributes or sub-elements
*Default*: "slice"
``plot`` elements of ``type`` ``slice`` also contain the following attributes or
sub-elements:
``<plot>`` elements of ``type`` "slice" also contain the following attributes or
sub-elements:
:basis:
Keyword specifying the plane of the plot for ``slice`` type plots. Can be
one of: ``xy``, ``xz``, ``yz``.
one of: "xy", "xz", "yz".
*Default*: ``xy``
*Default*: "xy"
:pixels:
Specifies the number of pixes to be used along each of the basis directions for
``slice`` plots. Should be 2 integers separated by spaces.
Specifies the number of pixes to be used along each of the basis directions
for "slice" plots. Should be two integers separated by spaces.
.. warning:: The ``pixels`` input determines the output file size. For the PPM
format, 10 million pixels will result in a file just under 30 MB in
@ -675,16 +694,16 @@ sub-elements:
.. warning:: Geometry features along a basis direction smaller than ``width``/``pixels``
along that basis direction may not appear in the plot.
*Default*: None - Required entry for ``slice`` plots
*Default*: None - Required entry for "slice" plots
:background:
Specifies the RGB color of the regions where no OpenMC cell can be found. Should
be 3 integers deparated by spaces.
be three integers separated by spaces.
*Default*: 0 0 0 (white)
:col_spec:
Any number of this optional tag may be included in each ``plot`` element, which can
Any number of this optional tag may be included in each ``<plot>`` element, which can
override the default random colors for cells or materials. Each ``col_spec``
element must contain ``id`` and ``rgb`` sub-elements.

132
docs/source/usersguide/setup.rst Normal file
View file

@ -0,0 +1,132 @@
.. _usersguide_setup:
==============================
Installation and Configuration
==============================
-------------
Prerequisites
-------------
In order to compile OpenMC, you will need to have a Fortran compiler installed
on your machine. Since a number of Fortran 2003 features are used in the code,
it is recommended that you use the latest version of whatever compiler you
choose. For gfortran_, it is recommended that you use version 4.5.0 or above.
If you are using Debian or a Debian derivative such as Ubuntu, you can install
the gfortran compiler using the following command::
sudo apt-get install gfortran
To compile with support for parallel runs on a distributed-memory architecture,
you will need to have a valid implementation of MPI installed on your
machine. The code has been tested and is known to work with the latest versions
of both OpenMPI_ and MPICH2_. You may use older versions of MPI implementations
at your own risk. OpenMPI and/or MPICH2 can be installed on Debian derivatives
with::
sudo apt-get install mpich2
sudo apt-get install openmpi-bin
To compile with support for HDF5_ output (highly recommended), you will need to
have HDF5 installed on your computer. The installed version will need to have
been compiled with the same compiler you intend to compile OpenMC with.
.. _gfortran: http://gcc.gnu.org/wiki/GFortran
.. _OpenMPI: http://www.open-mpi.org
.. _MPICH2: http://www.mcs.anl.gov/mpi/mpich/
.. _HDF5: http://www.hdfgroup.org/HDF5/
--------------------
Obtaining the Source
--------------------
All OpenMC source code is hosted on GitHub_. This means that you will need to
have git_ installed on your computer in order to get source code and updates
directly from the repository. GitHub has a good set of `instructions
<http://help.github.com/set-up-git-redirect>`_ for how to set up git to work
with GitHub since this involves setting up ssh_ keys. With git installed and
setup, the following command will download the full source code from the GitHub
repository::
git clone git@github.com:mit-crpg/openmc.git
.. _GitHub: http://github.com
.. _git: http://git-scm.com
.. _ssh: http://en.wikipedia.org/wiki/Secure_Shell
-------------------
Build Configuration
-------------------
All configuration for OpenMC is done within the Makefile located in
``src/Makefile``. In the Makefile, you will see that there are a number of User
Options which can be changed. It is recommended that you do not change anything
else in the Makefile unless you are experienced with compiling and building
software using Makefiles. The following parameters can be set from the User
Options sections in the Makefile:
COMPILER
This variable tells the Makefile which compiler to use. Valid options are
gfortran, intel, pgi, ibm, and cray.
DEBUG
Enables debugging when compiling. The flags added are dependent on which
compiler is used.
PROFILE
Enables profiling using the GNU profiler, gprof.
OPTIMIZE
Enables high-optimization using compiler-dependent flags. For gfortran,
this compiles with -O3. For Intel Fortran, this compiles with -O3 as well as
interprocedural optimization.
USE_MPI
Enables parallel runs using the Message Passing Interface. Users should also
set the MPI_ROOT directory further down in the Makefile.
USE_HDF5
Enables HDF5 output in addition to normal screen and text file output. Users
should also set the HDF5_ROOT directory further down in the Makefile.
It is also possible to change these options from the command line itself. For
example, if you want to compile with DEBUG turned on without actually change the
Makefile, you can enter the following from a terminal::
make DEBUG=yes
---------
Compiling
---------
To compile the code, run the following commands from within the root directory
for OpenMC:
.. code-block:: sh
cd src
make
This will build an executable named ``openmc``.
---------------------------
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 distributed with MCNP or Serpent.
To use cross sections distributed with MCNP, change the <directory> element in
the ``cross_sections.xml`` file in the root directory of the OpenMC distribution
to the location of the MCNP cross-sections. Then, either set the
:ref:`cross_sections` in a settings.xml file or the :envvar:`CROSS_SECTIONS`
environment variable to the absolute path of the ``cross_sections.xml`` file.
Similarly, to use cross-sections distributed with Serpent, change the
<directory> element in the ``cross_sections_serpent.xml`` file in the root
directory of the OpenMC distribution to the location of the Serpent
cross-sections. Then, either set the :ref:`cross_sections` in a settings.xml
file or the :envvar:`CROSS_SECTIONS` environment variable to the absolute path
of the ``cross_sections_serpent.xml`` file.

108
docs/source/usersguide/troubleshoot.rst Normal file
View file

@ -0,0 +1,108 @@
.. _usersguide_troubleshoot:
======================
Troubleshooting OpenMC
======================
-------------------------
Problems with Compilation
-------------------------
If you are experiencing problems trying to compile OpenMC, first check if the
error you are receiving is among the following options.
Fatal Error: File 'xml_data_settings_t.mod' opened at (1) is not a GFORTRAN module file
***************************************************************************************
When OpenMC compiles, the first thing it needs to do is compile source in the
xml-fortran subdirectory. If you compiled everything with a compiler other than
gfortran, performed a :program:`make clean`, and then tried to :program:`make`
with gfortran, the xml-fortran modules would have been compiled with a different
compiler. To fix this, try clearing out all modules and object files with
:program:`make distclean` and then recompiling.
gfortran: unrecognized option '-cpp'
************************************
You are probably using a version of the gfortran compiler that is too
old. Download and install the latestest version of gfortran_.
f951: error: unrecognized command line option "-fbacktrace"
***********************************************************
You are probably using a version of the gfortran compiler that is too
old. Download and install the latestest version of gfortran_.
make[1]: ifort: Command not found
*********************************
You tried compiling with the Intel Fortran compiler and it was not found on your
:envvar:`PATH`. If you have the Intel compiler installed, make sure the shell
can locate it (this can be tested with :program:`which ifort`).
make[1]: pgf90: Command not found
*********************************
You tried compiling with the PGI Fortran compiler and it was not found on your
:envvar:`PATH`. If you have the PGI compiler installed, make sure the shell can
locate it (this can be tested with :program:`which ifort`).
-------------------------
Problems with Simulations
-------------------------
Segmentation Fault
******************
A segmentation fault occurs when the program tries to access a variable in
memory that was outside the memory allocated for the program. The best way to
debug a segmentation fault is to re-compile OpenMC with debug options turned
on. First go to your ``openmc/src`` directory where OpenMC was compiled and type
the following commands:
.. code-block:: sh
make distclean
make DEBUG=yes
Now when you re-run your problem, it should report exactly where the program
failed. If after reading the debug output, you are still unsure why the program
failed, send an email to the OpenMC `developers
<mailto:paul.k.romano@gmail.com>`_.
ERROR: No cross_sections.xml file was specified in settings.xml or in the CROSS_SECTIONS environment variable.
**************************************************************************************************************
OpenMC needs to know where to find cross section data for each
nuclide. Information on what data is available and in what files is summarized
in a cross_sections.xml file. You need to tell OpenMC where to find the
cross_sections.xml file either with the :ref:`cross_sections` in settings.xml or
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: After particle __ crossed surface __ it could not be located in any cell and it did not leak.
****************************************************************************************************
This error can arise either if a problem is specified with no boundary
conditions or if there is an error in the geometry itself. First check to ensure
that all of the outer surfaces of your geometry have been given vacuum or
reflective boundary conditions. If proper boundary conditions have been applied
and you still receive this error, it means that a surface/cell/lattice in your
geometry has been specified incorrectly or is missing.
The best way to debug this error is to turn on a trace for the particle getting
lost. After the error message, the code will display what batch, generation, and
particle number caused the error. In your settings.xml, add a <trace> tag
followed by the batch, generation, and particle number. This will give you
detailed output every time that particle enters a cell, crosses a boundary, or
has a collision. For example, if you received this error at cycle 5, generation
1, particle 4032, you would enter:
.. code-block:: xml
<trace>5 1 4032</trace>
.. _gfortran: http://gcc.gnu.org/wiki/GFortran

11
readme.rst
View file

@ -21,11 +21,10 @@ Compiling for multiple processors can be controlled with the USE_MPI and MPI
variables. The MPI variable should be set to the base directory of the MPI
implementation installed on your computer.
OpenMC has been tested on Linux platforms with Intel, GNU, PGI, and Cray
compilers. It is recommended to use the latest version of whatever compiler you
should choose to use as there are a number of Fortran 2003 and 2008 intrinsics
that are used in OpenMC. While no testing has been done on Mac or Windows
platforms, there is no reason to believe it should not compile on any platform.
OpenMC has been tested on Linux, Mac, and Windows platforms with Intel, GNU,
PGI, and Cray compilers. It is recommended to use the latest version of whatever
compiler you should choose to use as there are a number of Fortran 2003 and 2008
intrinsics that are used in OpenMC.
--------------
Running OpenMC
@ -45,4 +44,4 @@ on your PATH, you may run::
where *numProcs* is the number of processors you desire to run on.
.. _Paul Romano: mailto:romano7@gmail.com
.. _Paul Romano: mailto:paul.k.romano@gmail.com