Running MCNP Simulations

A run is three things in order: an environment that can find nuclear data, an input deck, and an execution line that names the files MCNP should read and write. Miss the first and the code starts, then fails when it cannot open a table. Miss the second and there is nothing to transport. The third is short once the other two are right.

MCNP resolves ZAIDs through an xsdir (or xsdir_mcnp) file that lives under the directory named by DATAPATH. Put that directory on the environment, put the mcnp6 binary on your PATH, and a bare mcnp6 with no arguments should print version information rather than "command not found."

# Linux/Mac setup
export DATAPATH=/opt/mcnp/MCNP_DATA
export PATH=$PATH:/opt/mcnp/bin

# Windows setup  
set DATAPATH=C:\MCNP\MCNP_DATA
set PATH=%PATH%;C:\MCNP\bin

# Verify setup
mcnp6       # Run with no args to see version info

The DATAPATH variable tells MCNP where to find nuclear cross-section libraries. Without this, MCNP cannot access the nuclear data needed for transport calculations. The PATH variable should include the MCNP executable directory so you can run mcnp6 from any location.

Before a long production job, run the same deck with a tiny particle count once. Geometry and missing tables show up in seconds that way; a full kcode burn does not teach you anything new about a broken cell.

The command line is a short list of keyword assignments. i= names the input; o= names the output file. Other files appear during the run — a RUNTPE for checkpoint and restart, and an MCTAL if you ask for one. A leading c continues a previous calculation from where it left off.

# Simple run with default settings
mcnp6 i=uranium_sphere.i o=uranium_sphere.o

# Name every output file at once with a common prefix.
# This writes fuel_o, fuel_r and fuel_m - see the note below.
mcnp6 i=fuel_assembly.i n=fuel_

# Continue that run from its checkpoint. The RUNTPE it left behind
# is fuel_r, and the new output must not overwrite the old one.
mcnp6 c i=fuel_assembly.i o=fuel_continued.o r=fuel_r

n= is a different thing that is easy to mistake for o=. It sets a common prefix for every file the run produces, appending o, r and m to it. So n=fuel_results.out does not write fuel_results.out — it writes fuel_results.outo, fuel_results.outr and fuel_results.outm. Useful when you want a whole run's files grouped under one name; confusing when you meant o=.

While the job is running, the output file grows with cycle summaries. Follow it live, and search for the completion line when you want the final estimate:

# Monitor progress in real-time (while MCNP runs)
tail -f output.o

# Check for completion
grep "final estimated" output.o

The tail command lets you monitor MCNP's progress in real time, while grep searches for completion indicators in the output file. For additional debugging, add a DBCN card to your input deck.

Particle histories are independent enough that MCNP can spread them across cores on one machine, or across nodes with MPI. Shared-memory parallelism is the tasks keyword on the same mcnp6 line you already use. Distributed memory needs the MPI-enabled binary and a launcher such as mpirun or srun.

# Run with 8 parallel tasks on one node
mcnp6 i=input.i o=output.o tasks 8

# Optimal task count (usually equals CPU cores)
mcnp6 i=input.i o=output.o tasks $(nproc)

The tasks parameter should typically equal the number of CPU cores on your system. Each task shares the available system memory. Too many tasks can slow down calculations due to memory contention and communication overhead.

# Run across multiple nodes with MPI
mpirun -np 32 mcnp6.mpi i=input.i o=output.o

# SLURM job script example
#!/bin/bash
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=16
#SBATCH --time=24:00:00
#SBATCH --mem=64G

srun mcnp6.mpi i=reactor.i o=reactor.o

MPI parallelism lets MCNP run across multiple compute nodes. That requires the MPI-enabled binary (mcnp6.mpi) and appropriate job-scheduler configuration. The total number of MPI ranks should balance communication overhead with computational efficiency.

Long jobs need a way to resume after a wall-clock limit or a crash. MCNP writes RUNTPE files that capture the simulation state; a continue run picks up from that file. How often a dump is written is controlled from the deck with PRDMP, not from the command line.

# Add PRDMP card to your input deck for checkpointing:
#   PRDMP 2J 1    (controls dump/print frequency)

# Restart from checkpoint. A run started as
#   mcnp6 i=input.i o=output.o
# leaves its RUNTPE under the default name 'runtpe', not output.r.
mcnp6 c i=input.i o=output_new.o r=runtpe

# Verify restart statistics match
grep "cycles" output.o output_new.o

The PRDMP card controls dump and print frequency. In MCNP, J means "jump" (use the default value for that position). When restarting, MCNP continues from the state saved in the RUNTPE file. Check that restarted runs show continuous cycle numbering rather than starting over at cycle one.

Lost particles are the usual geometry symptom: a history enters a region that is not defined, or hits a bad surface intersection. Plotting mode and a raised lost-particle limit help you find the hole before you spend a night of CPU on it.

# Plot geometry to check for gaps
mcnp6 i=input.i ip

# Add LOST card to input to control lost particle limit
# Add PTRAC card to input for detailed particle tracking

The plotting mode (ip) lets you visualize geometry to identify gaps or overlaps. Add a LOST card to control how many particles can be lost before termination. The PTRAC data card enables detailed particle-tracking output.

Slow runs are a different class of problem: variance reduction that fights you, awkward geometry, or physics options that spend time you do not need. Memory use is printed in the output header; debug cards and weight-window data cards live in the deck, not on the command line.

# Profile particle tracking time
# Add DBCN card to input deck for debug output

# Weight windows and importance sampling are
# controlled via data cards (WWP, WWE, IMP) in
# the input deck, not command-line options.

Debug output shows time spent in different parts of the calculation. Weight-window parameters (WWP) can improve efficiency for deep-penetration problems; they do not replace a correct geometry.

The running example for this path is the PWR pin on Example: Pin Cell, mirrored as mcnp-examples/example_pin/pin_cell.i. Once DATAPATH points at your libraries, the launch from that directory is ordinary:

mcnp6 i=pin_cell.i o=pin_cell.o

The deck's kcode card asks for 5000 neutrons per cycle, skips 50, and runs 250 cycles in total — the same numbers as the example page. Add tasks N when you have cores to spare. When the job finishes, grep "final estimated" pin_cell.o is the quick check for the reported eigenvalue.