Pitfalls and troubleshooting

Serpent produces two types of error messages:

1. Input errors, identified by text "Input error", followed by the error message. If the error can be related to a specific input parameter, then also the name of the parameter and the line number in the input file are printed.
2. Run-time errors, in which case the name of the associated subroutine is printed, along with some additional information.

The first class of errors are (ideally) related to a problem in the input file. It should be noted, however, that the parameter name and line number may not reflect the original cause of the error, but rather the point where things started going wrong. Incorrectly typed input card names, for example, cause the parser to ignore the card altogether, and the following values are interpreted as entries belonging to the previous card.

Run-time errors should not occur, and they should always be reported to the developer team. This is also the case if the calculation crashes (segmentation fault or similar). In such case repeating the calculation in debug mode may reveal some additional information on what went wrong.

Serpent also produces a number of warning messages that may or may not be important. The code is pretty meticulous about errors, so problems let off with a warning are usually not too severe.

Things to check in case of suspicious results

Material volumes

Material volumes are not necessarily needed for most transport simulations, but they do affect the results of burnup calculation. Serpent prints an error message if the volume of an irradiated material is not available. The most typical error related to volumes is that the code attempts to calculate the volumes of two-dimensional pin-structures automatically, but for some reason this calculation produces incorrect results. This happens, for example, when:

• The geometry has axial dimension (3D geometry is assumed to be 2D)
• Some parts of the fuel pins are located outside the geometry (pins are clipped by cell, universe or geometry boundary)
• When universe symmetries are used (unable to account for pins in symmetry positions)

Serpent cannot identify these problems, so no error message is printed.

Material volumes should always be checked using the Monte Carlo based volume checker routine before running the calculation. If the values are incorrect, or the calculation produces an error message on missing values, the volumes must be set manually.

Unresolved resonance probability table sampling

Unresolved resonance probability table sampling is not used by default. This method is needed to account for self-shielding effects in the unresolved resonance region. The effect is usually not significant in thermal systems, but can lead to noticeable discrepancies in fast-spectrum systems.

Probability table sampling is switched on using the set ures option.

Mass vs. atomic densities

The densities and compositions of materials can be entered in atomic or mass units (see the input syntax of the material card), and using incorrect units may lead to unexpected results. The difference may not be clearly noticeable if the material consists nuclides with similar atomic weight, but if there are both light and heavy nuclides the results can be off by tens of percent.

In particular, using incorrect units for isotopes in water causes a major distortion in the flux spectrum in LWR calculations. In burnup calculation this results in completely unexpected depletion rate of ²³⁵U and build-up rate of ²³⁹Pu.

The material and nuclide densities used in the calculation can be checked from the nuclide and material output file (<input>.out).

MPI parallelization without MPI mode

MPI scripts such as mpirun allow running Serpent even if the source code was not complied in MPI mode. Instead of starting a single parallel simulation, the result is multiple independent simulations that read and write the same input and output files. If two or more writing operations happen to overlap, identical sections are repeated in the output files. If the tasks are sufficiently off-sync, the writing operations do not overlap, and it may actually seem like everything is OK - the correct number of CPU's are working and the results look reasonable. The only thing that seems to be wrong is that the running time does not reflect the speed-up expected from the parallelization.

When MPI parallelization is executed correctly, the run-time output shows the number of mpi tasks, for example (MPI=10). The number of tasks is also printed in variable MPI_TASKS in the main output file. Whether the source code was compiled in MPI mode or not can be checked with sss2 -version.

Unable to start or maintain criticality source simulation

Criticality source simulation requires an initial guess for the fission source distribution. If no source definition is provided, Serpent samples source points uniformly throughout all fissile materials, i.e. materials with fissile isotopes. This creates two potential problems:

1. If the fissile material covers only a small volume of the total geometry, the sampling of the initial source may fail completely
2. If the geometry contains both active and inactive fissile zones (e.g. seed and blanket), the calculation may fail after the first generation because the majority of source points are placed in the inactive zone

The solution to both problems is to use explicit source definition that puts sufficient number of points in the active parts of the fuel. I