From 84dde9b1e3fe79805c890f90b09a6df7c24712a2 Mon Sep 17 00:00:00 2001 From: Paul Romano Date: Wed, 28 Mar 2012 10:30:52 -0400 Subject: [PATCH] Greatly expanded documentation. --- docs/source/conf.py | 6 +- docs/source/developers.rst | 4 +- docs/source/devguide/index.rst | 16 + docs/source/devguide/structures.rst | 6 + docs/source/devguide/xml-fortran.rst | 6 + docs/source/index.rst | 13 +- docs/source/methods/geometry.rst | 24 ++ docs/source/methods/index.rst | 120 +----- docs/source/methods/introduction.rst | 10 + docs/source/methods/physics.rst | 95 +++++ docs/source/methods/tallies.rst | 17 + docs/source/publications.rst | 17 + docs/source/releasenotes/notes_0.4.2.rst | 9 + docs/source/usersguide/beginners.rst | 156 ++++++++ docs/source/usersguide/index.rst | 6 +- docs/source/usersguide/input.rst | 477 ++++++++++++----------- docs/source/usersguide/setup.rst | 132 +++++++ docs/source/usersguide/troubleshoot.rst | 108 +++++ readme.rst | 11 +- 19 files changed, 877 insertions(+), 356 deletions(-) create mode 100644 docs/source/devguide/index.rst create mode 100644 docs/source/devguide/structures.rst create mode 100644 docs/source/devguide/xml-fortran.rst create mode 100644 docs/source/methods/geometry.rst create mode 100644 docs/source/methods/introduction.rst create mode 100644 docs/source/methods/physics.rst create mode 100644 docs/source/methods/tallies.rst create mode 100644 docs/source/publications.rst create mode 100644 docs/source/usersguide/beginners.rst create mode 100644 docs/source/usersguide/setup.rst create mode 100644 docs/source/usersguide/troubleshoot.rst diff --git a/docs/source/conf.py b/docs/source/conf.py index bfdd713a88..e5ed16aab5 100644 --- a/docs/source/conf.py +++ b/docs/source/conf.py @@ -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. diff --git a/docs/source/developers.rst b/docs/source/developers.rst index be48bb409b..4f4713aaef 100644 --- a/docs/source/developers.rst +++ b/docs/source/developers.rst @@ -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 diff --git a/docs/source/devguide/index.rst b/docs/source/devguide/index.rst new file mode 100644 index 0000000000..a8ea5434c0 --- /dev/null +++ b/docs/source/devguide/index.rst @@ -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 diff --git a/docs/source/devguide/structures.rst b/docs/source/devguide/structures.rst new file mode 100644 index 0000000000..410b501639 --- /dev/null +++ b/docs/source/devguide/structures.rst @@ -0,0 +1,6 @@ +.. _devguide_structures: + +=============== +Data Structures +=============== + diff --git a/docs/source/devguide/xml-fortran.rst b/docs/source/devguide/xml-fortran.rst new file mode 100644 index 0000000000..1d83b465cb --- /dev/null +++ b/docs/source/devguide/xml-fortran.rst @@ -0,0 +1,6 @@ +.. _devguide_xml-fortran: + +========================= +xml-fortran Input Parsing +========================= + diff --git a/docs/source/index.rst b/docs/source/index.rst index 18db6e8628..5b8bebff35 100644 --- a/docs/source/index.rst +++ b/docs/source/index.rst @@ -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 diff --git a/docs/source/methods/geometry.rst b/docs/source/methods/geometry.rst new file mode 100644 index 0000000000..86d5a845a2 --- /dev/null +++ b/docs/source/methods/geometry.rst @@ -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)`. diff --git a/docs/source/methods/index.rst b/docs/source/methods/index.rst index 0aa3adebee..bc08102422 100644 --- a/docs/source/methods/index.rst +++ b/docs/source/methods/index.rst @@ -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 diff --git a/docs/source/methods/introduction.rst b/docs/source/methods/introduction.rst new file mode 100644 index 0000000000..02d4d078b0 --- /dev/null +++ b/docs/source/methods/introduction.rst @@ -0,0 +1,10 @@ +.. _methods_introduction: + +============ +Introduction +============ + +--------------------- +Criticality Algorithm +--------------------- + diff --git a/docs/source/methods/physics.rst b/docs/source/methods/physics.rst new file mode 100644 index 0000000000..b0d3b34daa --- /dev/null +++ b/docs/source/methods/physics.rst @@ -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. diff --git a/docs/source/methods/tallies.rst b/docs/source/methods/tallies.rst new file mode 100644 index 0000000000..7fbc25418f --- /dev/null +++ b/docs/source/methods/tallies.rst @@ -0,0 +1,17 @@ +.. _methods_tallies: + +======= +Tallies +======= + +---------------- +Analog Estimator +---------------- + +---------------------- +Track-length Estimator +---------------------- + +--------------- +Surface Current +--------------- diff --git a/docs/source/publications.rst b/docs/source/publications.rst new file mode 100644 index 0000000000..19f2353a09 --- /dev/null +++ b/docs/source/publications.rst @@ -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 + `_] diff --git a/docs/source/releasenotes/notes_0.4.2.rst b/docs/source/releasenotes/notes_0.4.2.rst index 8d4c1f2d2a..825a37d3a2 100644 --- a/docs/source/releasenotes/notes_0.4.2.rst +++ b/docs/source/releasenotes/notes_0.4.2.rst @@ -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 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 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 diff --git a/docs/source/usersguide/beginners.rst b/docs/source/usersguide/beginners.rst new file mode 100644 index 0000000000..14e52ca05d --- /dev/null +++ b/docs/source/usersguide/beginners.rst @@ -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 +`_ 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 `_ 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 + diff --git a/docs/source/usersguide/index.rst b/docs/source/usersguide/index.rst index 3673012bfb..0f1d5da345 100644 --- a/docs/source/usersguide/index.rst +++ b/docs/source/usersguide/index.rst @@ -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 diff --git a/docs/source/usersguide/input.rst b/docs/source/usersguide/input.rst index 3e0aec34e7..32f63bbcfa 100644 --- a/docs/source/usersguide/input.rst +++ b/docs/source/usersguide/input.rst @@ -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 John @@ -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. + +```` Element +------------------------- + +The ```` 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 ```` 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. + +```` Element +-------------------- + +The ```` 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 + +```` Element +------------------------- + +The ```` 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 + +```` Element +--------------------- + +The ```` 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 + +```` Element +--------------------- + +The ```` 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 + +```` Element +------------------ + +The ``seed`` element is used to set the seed used for the linear congruential +pseudo-random number generator. + + *Default*: 1 + +```` 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. + +```` Element +------------------------------ + +The ```` 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 + +```` Element +------------------- + +The ```` 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 + +```` Element +----------------------- + +The ```` 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: - +.. code-block:: xml + + @@ -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 @@ -94,10 +276,10 @@ could be written as:: -``surface`` Element -------------------- +```` Element +--------------------- -Each ``surface`` element can have the following attributes or sub-elements: +Each ```` 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 ----------------- +```` Element +------------------ -Each ``cell`` element can have the following attributes or sub-elements: +Each ```` 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 -------------------- +```` 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 ```` 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 ```` 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 --------------------- +```` 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:: - - + 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 ----------------------- +```` 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 ```` 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 ```` and ````. -``tally`` Element ------------------ +```` Element +------------------- -The ``tally`` element accepts the following sub-elements: +The ```` 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 ----------------- +```` 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 ````. 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 ---------------------------- +```` 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 ```` and any number output -figures can be defined with ```` 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 ```` and any number output figures can +be defined with ```` sub-elements. -``plot`` Element +```` 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: +```` 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 ```` element, which can override the default random colors for cells or materials. Each ``col_spec`` element must contain ``id`` and ``rgb`` sub-elements. diff --git a/docs/source/usersguide/setup.rst b/docs/source/usersguide/setup.rst new file mode 100644 index 0000000000..a148000c77 --- /dev/null +++ b/docs/source/usersguide/setup.rst @@ -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 +`_ 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 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 + 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. diff --git a/docs/source/usersguide/troubleshoot.rst b/docs/source/usersguide/troubleshoot.rst new file mode 100644 index 0000000000..40aa6a208a --- /dev/null +++ b/docs/source/usersguide/troubleshoot.rst @@ -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 +`_. + +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 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 + + 5 1 4032 + +.. _gfortran: http://gcc.gnu.org/wiki/GFortran + diff --git a/readme.rst b/readme.rst index f0762daf32..6fcf5bcf6d 100644 --- a/readme.rst +++ b/readme.rst @@ -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