Basic Concepts & Workflow

Monte Carlo Neutron Transport

Monte Carlo methods solve the neutron transport equation by simulating individual particle histories rather than discretizing the equation on a spatial or energy grid. Each neutron begins at a source location with a sampled energy and direction, then travels through the geometry until it undergoes an interaction. The type of interaction — scattering, absorption, or fission — is determined by sampling from probability distributions derived from nuclear cross-section data. By tracking a large number of such histories, the code builds up a statistical estimate of quantities like the neutron flux, reaction rates, and the multiplication factor.

The key advantage of this approach is geometric generality. Because particles are tracked individually through whatever geometry is defined, Monte Carlo codes handle complex three-dimensional configurations without the approximations that deterministic methods require. The trade-off is statistical uncertainty: every result is an estimate with an associated standard deviation that decreases as the square root of the number of particle histories simulated.

Serpent uses continuous-energy cross sections, meaning that neutron interactions are sampled at the particle's actual energy rather than within pre-defined energy groups. This avoids the self-shielding approximations inherent in multigroup methods and is especially important for capturing resonance effects in fuel materials.

Serpent Input Structure

A Serpent input file is a plain text file that describes the problem to be solved. It contains material definitions specifying the nuclear composition and density of each region, surface definitions describing the geometric boundaries, cell definitions assigning materials to the volumes bounded by those surfaces, and settings that control the physics and execution parameters.

% Material definition
mat fuel -10.4 tmp 900
92235.09c  0.04
92238.09c  0.96
8016.09c   2.0

% Surface definition
surf 1 cyl 0.0 0.0 0.4

% Cell definition
                  cell 1 0 fuel -1
cell 2 0 outside 1

% Simulation settings
set pop 10000 100 20
set bc 2
set acelib "sss_endfb7u.xsdata"

Serpent's input format is free-form and order-independent for most card types, though organizing the file into logical sections (materials, geometry, settings) makes it far easier to read and maintain. Comments begin with the percent sign and continue to the end of the line.

The Simulation Workflow

A typical Serpent workflow begins with preparing the input file. You define the geometry and materials for your problem, select the appropriate cross-section libraries, and choose simulation parameters such as the neutron population size and the number of active and inactive cycles. For an initial test, keeping the population small (a few thousand neutrons) allows you to quickly check for geometry errors before committing to a production run.

Running the simulation is straightforward: you invoke Serpent from the command line with the input file as an argument. During execution, Serpent prints progress information to the terminal, including the current cycle number, the running estimate of k-effective, and the simulation speed in neutrons per second. Warning messages, if any, also appear in this output stream.

After the calculation finishes, Serpent writes results to several output files. The primary results file (with a _res.m suffix) contains global quantities like k-effective and its statistical uncertainty. If you defined detectors (tallies), their results appear in _det0.m files. For burnup calculations, isotopic inventories and reaction rates at each time step are written to _dep.m. All of these output files use MATLAB-compatible syntax, making them easy to load and plot with MATLAB, Octave, or Python scripts.

Output Files

The main results file contains the final k-effective estimate, neutron generation time, effective delayed neutron fraction, and other integral parameters. Each quantity is reported with its statistical uncertainty, which you should always examine — a result without a meaningful uncertainty is not useful for engineering decisions.

The running log file (with an _out or .out extension) records everything that happened during the simulation: initialization messages, geometry check results, cycle-by-cycle k-effective values, memory usage, and timing statistics. This file is your first stop when diagnosing problems or verifying that the calculation converged properly.

Detector output files contain the spatial, energy, or material-specific tallies that you requested in the input. These are the workhorse outputs for most analysis tasks, providing flux spectra, reaction rate distributions, power profiles, and other quantities that characterize the neutron physics of your model.

Best Practices

Start every new model with a coarse geometry and small particle population. Run Serpent to confirm that the geometry is defined correctly and that there are no input errors before investing computational time in a production calculation. Use the geometry plotting capability to visually verify your model — many subtle errors in cell definitions become immediately obvious in a plot.

Organize your input files consistently. Use descriptive material and surface names, group related definitions together, and add comments that explain the physical meaning of key parameters rather than simply restating what the code syntax does. Maintaining a template file for common configurations saves time and reduces errors when setting up new calculations.

Always check statistical convergence before trusting results. The relative statistical uncertainty on k-effective should be well below 100 pcm for most reactor physics applications. For detailed spatial distributions or reaction rates in small regions, you may need significantly more particle histories to achieve acceptable statistics. Comparing results from two independent runs with different random number seeds provides additional confidence that the calculation has converged.