4. Constructive Solid Geometry¶
OpenMOC uses constructive solid geometry (CSG) to represent complex reactor models in software. The constructive solid geometry formulation is the method of choice for many advanced modeling software packages, including some Computer-aided Design (CAD) implementations. CSG allows complex spatial models to be built using boolean operations - such as intersections and unions - of simple surfaces and building blocks termed primitives, as illustrated in Figure 1 [Wikipedia]. The constructive solid geometry approach is well suited for reactor models which typically are highly structured and contain repeating patterns. This is the case for commercial PWRs and BWRs whose cores are built out of a rectangular lattice of fuel assemblies, each of which is a rectangular lattice of fuel pins.
There are a number of benefits to using the CSG formulation. First, CSG enables simulation codes to significantly reduce the memory footprint required to model the geometry. For example, rather than representing each fuel pin explicitly in memory, a fuel pin primitive is represented by a single data structure. A second major benefit to the CSG formulation is that it is a general and extensible approach which allows for ray tracing routines to be written in an abstract fashion that is independent of the primitives themselves.
OpenMOC’s implementation of the routines and data structures for CSG are in large part inspired by those used in the OpenMC code. The following sections describe the primitives and algorithms used for CSG modeling in OpenMOC.
4.1. CSG Formulation¶
The constructive solid geometry formulation in OpenMOC is predicated upon the use of several key objects which allow one to construct a spatial model from simple primitives in a hierarchical fashion. The following sections describe each of these fundamental objects in order of increasing complexity. The reader should note that the CSG formulation in OpenMOC is capable of describing the full 3D space, but defining a 2D geometry for a 2D case is fairly straightforward.
Section 4.1.1 develops the formulation for surfaces which are used to divide space into separate unique halfspaces. Section 4.1.2 describes universes which represent the entirety of 2D (or 3D) space and provide a “clean pallet” upon which one can build a simple structure of cells. Section 4.1.3 describes cells, of which the region attribute contains one or more surfaces that bound a subset of space filled by either a material or a universe. Section 4.1.4 describes lattices which are used to create a bounded union of universes through a series of coordinate transformations. A typical hierarchy for the way in which surfaces, universes, cells and lattices are constructed to represent a reactor model in OpenMOC is illustrated in Figure 2.
4.1.1. Surfaces and Halfspaces¶
The fundamental primitive in OpenMOC is a surface. A 3D surface in the -plane is defined as the set of points that satisfy for some function that will henceforth be termed the potential function of the surface. The potential divides the -plane into two halfspaces. The set of coordinates for which is called the positive halfspace while those coordinates for which collectively form the negative halfspace. Figure 3 illustrates the concepts of halfspaces for an arbitrary elliptical surface.
For a surface primitive to be incorporated into the OpenMOC CSG framework, the ray tracing routines require the primitive to include a method to find the intersection point(s) on the surface along some unit trajectory vector originating from any point . A depiction of this is given in Figure 4 for the parametrized distance between and the surface.
Presently, OpenMOC includes surface primitive types that are most useful for constructing LWR models. These surfaces are from a subset of potential functions called quadratic surfaces as discussed in the following section.
4.1.1.1. Quadratic Surfaces¶
A generalized quadratic surface in 3D is a second order surface with following form:
(1)
Quadratic surfaces include planes, cylinders and ellipsoids. The quadratic surface primitives available in OpenMOC at the date of this writing are displayed in Table 1.
Surface | Class | Potential Equation | Parameters |
---|---|---|---|
Arbitrary plane | Plane | ||
Plane perpendicular to -axis | XPlane | ||
Plane perpendicular to -axis | YPlane | ||
Plane perpendicular to -axis | ZPlane | ||
Circle in the -plane | ZCylinder |
Table 1: Quadratic surface primitives in OpenMOC.
The following sections develop the methodology used in OpenMOC to compute the distance from any point in the -plane to each of the surfaces in Table 1.
4.1.1.2. Arbitrary Plane¶
An arbitrary plane is described by the following potential equation:
(2)
To find the intersection point along some trajectory with a Plane, substitute the intersection point on the surface into the potential equation and rearrange to find the following parametrized distance :
(3)
4.1.1.3. XPlane¶
A plane perpendicular to the -axis is described by the following potential equation:
(4)
To find the intersection point along some trajectory with a XPlane, substitute the intersection point on the surface into the potential equation and rearrange to find the following parametrized distance :
(5)
4.1.1.4. YPlane¶
Similar to the XPlane, a plane perpendicular to the -axis is described by the following potential equation:
(6)
To find the intersection point along some trajectory with a YPlane, substitute the intersection point on the surface into the potential equation and rearrange to find the following parametrized distance :
(7)
4.1.1.5. ZPlane¶
Similar to the ZPlane, a plane perpendicular to the -axis is described by the following potential equation:
(8)
To find the intersection point along some trajectory with a ZPlane, substitute the intersection point on the surface into the potential equation and rearrange to find the following parametrized distance :
(9)
4.1.1.6. ZCylinder¶
A circle in the -plane centered at with radius is described by the following potential equation:
(10)
To find the intersection point along some trajectory with a ZCylinder, substitute the intersection point on the surface into the potential equation, define and , and rearrange to find the following parametrized distance :
(11)
(12)
The parametrized distance is in the form of the quadratic formula, and there may be one or two real solutions, or two complex solutions. In the case of one solution, it indicates that the trajectory vector merely glances the surface of the ZCylinder. The two solution case represents a trajectory vector that intersects the ZCylinder surface and passes through on the opposite side. Complex solutions are unphysical and represent the fact that the trajectory will not pass through the circle at all.
4.1.2. Regions¶
A region is a cell attribute that contains a CSG tree of halfspaces which is used to describe the spatial extent of a cell.
4.1.3. Cells¶
A cell is defined to be the region bounded by a boolean combination of surface halfspaces. OpenMOC supports intersection, union and complement of surface halfspaces. The halfspaces are kept in the region cell attribute. The cell also has a fill attribute, filled by either a material or a universe, described in the following section.
Figure 5 illustrates the use of five surface halfspaces to make up a simple pin cell. The halfspace for each surface is indicated by “” or “” symbols, while each cell is uniquely identified by a color and number. The fuel pin is described by the negative halfspace of the ZCylinder surface, while the moderator is made up of the intersection of the positive halfspace of the ZCylinder and positive/negative halfspaces of the left/right and bottom/top XPlanes and YPlanes, respectively.
4.1.4. Universes¶
A universe is a collection of one or more cells that fill the entirety of the -plane. Each cell may be filled with a material or a separate universe. Universes allow unique structures to be created from cells, and for simple replication of that structure throughout a model by placing it in various locations throughout the geometry. The universe-based CSG formulation in OpenMOC is similar to that used in Monte Carlo neutron transport codes such as [OpenMC], [MCNP] and [Serpent].
A universe of 10 cells constructed from the halfspace intersections of two XPlanes, two YPlanes and one ZCylinder surface is depicted in Figure 6. The halfspace for each surface is indicated by “” or “” symbols, while each cell is uniquely identified by a color and number.
4.1.5. Lattices¶
Lattices are an extremely useful construct for modeling regular, repeating structures. This is especially the case for reactor cores which typically contain rectangular or hexagonal arrays of fuel pins. For this reason, lattices are a common structure in many neutron transport codes, such as OpenMC, MCNP and Serpent.
OpenMOC currently contains two lattice implementation for 3D Cartesian arrays. A lattice can be specified by the number of array elements along the , and axes, the dimensions of each lattice cell, and the universe to fill each lattice cell. The lattice specification represents a coordinate transformation such that the center of each lattice cell maps to the origin of the universe within it. This allows for a single universe to be replicated in some or all lattice cells without redundantly storing the universe many times in memory.
Alternatively, a lattice can be defined using a set of widths in each Cartesian direction, to form a 3D non-uniform array. This is especially useful to model water gaps in PWRs, fuel bundle walls in BWRs and the baffle in both reactors.
Figure 7 illustrates a simple 4 4 lattice, with each lattice cell filled by one of three different universes. Each universe contains two cells representing the moderator and a fuel pin of some diameter.
4.2. References¶
[Wikipedia] | Wikipedia, “Constructive Solid Geometry,” http://en.wikipedia.org/wiki/Constructive_solid_geometry (2013). |
[OpenMC] |
|
[MCNP] | X-5 Monte Carlo Team, “MCNP - A General Monte Carlo N-Particle Transport Code, Version 5.” Technical Report LA-UR-03-1987, Los Alamos National Laboratory (2008). |
[Serpent] |
|