1. Software Design¶
OpenMOC uses a compiled language coupled with a scripting language “glue” [Sanner], a methodology that has increasingly gained traction across disciplines since it enables both usability and performance. The majority of the source code is written in C/C++ as it is the most robust and well supported general purpose, high performance, compiled programming language with object-oriented features. In addition, OpenMOC’s solver routines for the GPU are written in NVIDIA’s CUDA programming language [CUDA] - a compiled language with similar syntax to C/C++. The widely adopted Simplified Wrapper Interface Generator (SWIG) [Beazley] is deployed to expose the C/C++/CUDA classes and routines to the Python scripting language. The model to couple the compiled C/C++/CUDA code to the Python scripting language is illustrated in Figure 1. OpenMOC’s Python interface allows for rapid prototyping and testing of code features and tight integration with the rich ecosystem of powerful data processing and visualization tools developed for Python.
1.1. Object-Oriented Design¶
OpenMOC is designed using the Object-Oriented (OO) programming paradigm, the standard for software development for over two decades. In OO programming, data structures called classes are used to encapsulate both attributes and subroutines. Object-oriented programming is powerful since it directly enables code generalization and requires the use of trust boundaries which lead to more resilient code. An OpenMOC simulation is created through the instantiation and manipulation of class objects. A complete listing of classes in OpenMOC is displayed in Table 1.
Class | Parent Class | Category |
---|---|---|
Surface |
N/A | Constructive Solid Geometry |
Plane |
Surface |
Constructive Solid Geometry |
XPlane |
Plane |
Constructive Solid Geometry |
YPlane |
Plane |
Constructive Solid Geometry |
ZCylinder |
Surface |
Constructive Solid Geometry |
Cell |
N/A | Constructive Solid Geometry |
Universe |
Universe |
Constructive Solid Geometry |
Lattice |
N/A | Constructive Solid Geometry |
Geometry |
N/A | Constructive Solid Geometry |
TrackGenerator |
N/A | Ray Tracing |
TrackGenerator3D |
TrackGenerator | Ray Tracing |
Quadrature |
N/A | Ray Tracing |
Material |
N/A | Nuclear Data |
Solver |
N/A | Method of Characteristics |
CPUSolver |
Solver |
Method of Characteristics |
CPULSSolver |
CPUSolver |
Method of Characteristics |
GPUSolver |
Solver |
Method of Characteristics |
VectorizedSolver |
CPUSolver |
Method of Characteristics |
Table 1: OpenMOC’s classes.
1.2. Python Modules¶
OpenMOC’s Python interface makes it relatively easy to create complicated simulation input. Generating input for an OpenMOC simulation does not involve writing an input file in the traditional sense. OpenMOC leverages the flexiblity provided by Python to allow users complete control to build their inputs in one or more scripts just as one may do for any Python program. The user imports the necessary OpenMOC modules (see Table 2) into Python and “builds” a simulation using only those classes and routines which are needed.
Module | Description |
---|---|
openmoc |
The main module for OpenMOC |
openmoc.options |
Command line options |
openmoc.log |
Level-based logging messages |
openmoc.materialize |
Import/export multi-group nuclear data |
openmoc.plotter |
Visualizations for geometry, flux, etc. |
openmoc.process |
Data processing |
openmoc.cuda |
Solver for NVIDIA GPUs |
openmoc.krylov |
Solver based on krylov IRAM methods |
Table 2: OpenMOC’s Python modules.
[Sanner] |
|
[CUDA] | NVIDIA, “NVIDIA CUDA C Programming Guide.” http://docs.nvidia.com/cuda/cuda-c-programming-guide/ (2013). |
[Beazley] |
|