Monte Carlo Fundamentals
Geometry & Materials
Constructive Solid Geometry (CSG)
All major Monte Carlo transport codes -- MCNP, OpenMC, and Serpent -- use Constructive Solid Geometry to define the simulation domain. In CSG, complex shapes are built from simple mathematical surfaces combined with Boolean set operations. Understanding CSG is essential because geometry errors are one of the most common sources of incorrect Monte Carlo results.
The fundamental idea is that every point in space can be classified as being on one side or the other of every surface. A cell (or region) is then defined as the intersection, union, or complement of these half-spaces. This approach can represent remarkably complex geometries using only basic analytic surfaces.
Why CSG Matters for Code Users
Most geometry bugs stem from misunderstanding how surfaces combine to form cells. If you can visualize which side of each surface a cell occupies, you can debug geometry problems quickly and build models confidently. Every Monte Carlo code requires this same mental model, even though the input syntax differs.
Surfaces: The Building Blocks
Surfaces are defined by implicit equations of the form f(x, y, z) = 0. The sign of f at any point determines which side of the surface that point lies on. This is called the surface sense: positive sense where f > 0, negative sense where f < 0.
All standard Monte Carlo surfaces (planes, spheres, cylinders, cones) are special cases of this equation.
The most commonly used surfaces in reactor modeling include:
Planes
ax + by + cz = d
Used for flat boundaries, reflective planes, and rectangular regions. Axis-aligned planes (e.g., x = 5) are the simplest and most common.
Spheres
(x-x₀)² + (y-y₀)² + (z-z₀)² = r²
Used for fuel kernels, containment boundaries, and criticality safety vessels. Positive sense means outside the sphere.
Cylinders
(x-x₀)² + (y-y₀)² = r² (z-axis cylinder)
The workhorse of reactor geometry. Fuel pins, control rods, coolant channels, and pressure vessels are all modeled as cylinders.
Cones
z² = k²(x² + y²)
Less common but needed for nozzle designs, some shielding geometries, and conical beam ports.
Surface Sense: The Most Common Source of Bugs
For a sphere centered at the origin with radius r, the implicit equation is f = x² + y² + z² - r². Points inside the sphere have f < 0 (negative sense) and points outside have f > 0 (positive sense).
In MCNP, negative sense is written as -1 (inside surface 1) and positive sense as 1 (outside surface 1). In OpenMC, the same concept uses -surfand +surf. Getting the sign wrong is the single most common geometry error in Monte Carlo modeling -- it places material where void should be and vice versa.
Cells: Combining Surfaces with Boolean Logic
Cells are defined by combining surface half-spaces using Boolean operations. The two fundamental operations are intersection (AND) and union (OR). Together with surface sense, they can describe any region expressible with CSG.
Example: A Fuel Pin Cell
Consider a cylindrical fuel pellet (surface 1, radius 0.41 cm) inside a cladding tube (surface 2, radius 0.47 cm) surrounded by coolant inside a square pitch cell (surfaces 3-6 for the four bounding planes):
- Fuel region: Inside surface 1 → negative sense of surface 1
- Cladding: Outside surface 1 AND inside surface 2 → intersection of positive sense of 1 with negative sense of 2
- Coolant: Outside surface 2 AND inside all four planes → intersection of positive sense of 2 with negative senses of bounding planes
The entire space must be accounted for -- no gaps, no overlaps. Every point in the problem domain must belong to exactly one cell. This is the fundamental rule of CSG geometry.
Intersection narrows regions (AND logic); union expands them (OR logic). Complement inverts a region.
In practice, most reactor geometries use intersections heavily (defining regions bounded by multiple surfaces) and unions occasionally (combining disjoint regions into one cell or creating complex shapes from simpler ones).
Material Specification
Each cell is assigned a material with a specific composition and density. Monte Carlo codes use this information to compute macroscopic cross-sections, which determine how neutrons interact with the material. Accurate material definitions are critical because small errors in composition or density can significantly affect results -- especially for k-effective.
Where ρ is mass density (g/cm³), Nₐ is Avogadro's number (6.022 × 10²³), and M is molar mass (g/mol).
For compounds and mixtures, each isotope has its own number density. Monte Carlo codes accept compositions specified as either atom fractions (relative number of atoms) or weight fractions (relative mass of each isotope). The conventions differ by code:
MCNP
Positive density = atom density (atoms/barn-cm). Negative density = mass density (g/cm³). Positive fractions = atom fractions. Negative fractions = weight fractions.
OpenMC
Explicit method calls: add_nuclide() with percent_type='ao'(atom) or 'wo' (weight). Density set separately viaset_density().
Serpent
Negative density = mass density (g/cm³). Positive density = atom density (atoms/barn-cm). Positive fractions = atom fractions. Negative fractions = weight fractions.
Temperature Effects on Materials
Temperature affects Monte Carlo calculations in two important ways: it changes material density through thermal expansion, and it broadens nuclear resonances through Doppler broadening. Both effects can be significant for reactor calculations.
Where α is the linear thermal expansion coefficient. Density decreases as temperature rises because volume increases.
Doppler broadening of resonances is handled internally by Monte Carlo codes using temperature-dependent cross-section libraries or on-the-fly broadening methods. This effect is crucial for reactor safety because it provides negative temperature feedback in most fuel types -- as fuel heats up, broadened resonances increase parasitic absorption, reducing reactivity.
Boundary Conditions
The outermost surfaces of your geometry require boundary conditions that tell the code what happens when a particle reaches the edge of the model. The choice of boundary condition significantly affects your results and determines what physical system your model represents.
Vacuum (escape)
Particles that reach this boundary are removed from the simulation. Used for the true outer boundary of finite systems. Any neutron that escapes is lost -- this represents leakage, which reduces k-effective.
Reflective
Particles are reflected specularly (mirror-like) back into the geometry. Used to exploit symmetry -- a quarter-core model with reflective boundaries on the symmetry planes is physically equivalent to the full core, but 4x cheaper to simulate.
Periodic
Particles exiting one boundary re-enter the geometry from the corresponding opposite boundary. Used for infinite lattice calculations where a single unit cell with periodic boundaries represents an infinite array. This gives k-infinity (k∞) rather than k-effective.
White (isotropic return)
Particles are returned with a cosine-weighted isotropic angular distribution. Used as an approximation of diffuse reflection from surrounding material. Less common than reflective boundaries but useful for certain benchmark problems.
Choosing Boundary Conditions
- Full reactor model: Vacuum on all outer surfaces (pressure vessel or shield exterior)
- Quarter-core: Reflective on two symmetry planes, vacuum on outer surfaces
- Single pin cell: Reflective or periodic on all six faces for infinite lattice approximation
- Assembly model: Reflective on all faces for standalone lattice physics; vacuum if modeling leakage
Lattice Structures: Modeling Repeated Geometry
Nuclear reactors are built from highly repetitive structures -- hundreds of fuel pins in an assembly, hundreds of assemblies in a core. Lattice constructs allow you to define one unit cell and replicate it across the geometry without defining each copy individually. This dramatically simplifies input and reduces memory usage.
In CSG-based codes, lattices work through the universe concept. You define a unit cell in its own local coordinate system (a "universe"), then fill lattice positions with that universe. The lattice handles the coordinate transformations automatically.
Each lattice position maps to a universe that defines its contents. Different positions can contain different universes.
Common lattice types include rectangular (Cartesian) lattices used for square-pitch fuel assemblies and hexagonal lattices used in VVER, CANDU, and many advanced reactor designs. The ability to fill different lattice positions with different universes allows modeling of control rod guide tubes, instrumentation tubes, and burnable absorber pins within an otherwise regular fuel assembly.
Practical Lattice Modeling Tips
- Verify unit cell dimensions: Lattice pitch must match the unit cell bounding surfaces exactly, or particles will be lost or misplaced
- Use geometry plotting: Always visualize your lattice geometry to check for errors before running transport
- Leverage nesting: Pins fill assembly lattices, assemblies fill core lattices -- this hierarchical approach mirrors real reactor design
- Watch for partial pins: Assemblies at the core periphery may have fuel pins cut by the core boundary; handle these carefully
Geometry Validation and Debugging
Geometry errors can silently corrupt Monte Carlo results. A misplaced surface or incorrect cell definition might not cause an obvious crash but could place the wrong material in a critical region, leading to subtly wrong answers. Systematic validation is essential.
Validation Techniques
- Visual inspection: Plot 2D cross-sections through your geometry at multiple elevations and angles. Color-code by material and look for unexpected regions.
- Stochastic volume calculation: Monte Carlo codes can estimate cell volumes by random sampling. Compare these against your engineering drawings.
- Lost particle checks: If particles enter undefined regions, the code will report "lost particles." Any lost particles indicate a geometry gap that must be fixed.
- Overlap detection: Most codes offer an overlap check mode that samples random points and flags locations claimed by multiple cells. Even a single overlap is a bug.
- Physical reasonableness: Do your calculated fuel mass, coolant volume, and structural material amounts match the design specification?
Common Geometry Mistakes
- Wrong surface sense: Confusing inside/outside of a cylinder or sphere -- this places fuel where coolant should be (or vice versa)
- Gaps between cells: Forgetting to account for a thin region between two surfaces, creating undefined space
- Overlapping cells: Two cell definitions that claim the same region of space, causing ambiguous material assignments
- Missing outer boundary: Forgetting to define the void or graveyard cell beyond the outermost surfaces
- Lattice pitch mismatch: Unit cell dimensions not matching the lattice pitch, causing gaps or overlaps at cell boundaries
Performance Considerations
Geometry tracking is one of the most computationally expensive operations in Monte Carlo transport. Every time a particle moves, the code must determine which surface it will cross next by solving ray-surface intersection equations for every surface in the current cell.
Distance t from point r₀ in direction Ω̂ to the surface f = 0. Computed for each bounding surface of the current cell.
The computational cost of geometry tracking scales with the number of surfaces per cell. Deep universe nesting and complex cells with many surfaces slow down tracking. Practical strategies to improve performance include:
- Minimize surfaces per cell: Use the simplest geometry that captures the important physics
- Use bounding surfaces: Enclosing complex regions within simple bounding boxes reduces unnecessary intersection tests
- Leverage lattice symmetry: Lattices are inherently efficient because coordinate transformations replace explicit surface definitions
- Avoid unnecessary detail: Small features far from tallies of interest can often be homogenized without affecting results