SCONE Guide

SCONE Verification Notice

SCONE is a research-oriented code with a smaller user base than MCNP, OpenMC, or SERPENT. Our examples are intended as educational guidance. For authoritative syntax, physics options, and nuclear data requirements, consult the official documentation.

Official SCONE documentation SCONE on GitHub Issues & discussions

Parallel Computing in SCONE

OpenMP (threads) and MPI (processes), per upstream CMake — no parallel block in the input

Threads and processes

Upstream SCONE enables OpenMP and MPI by default in CMakeLists.txt (see also the official Installation page). The input deck has no parallel { ... } block: you control parallelism at build time (-DOPENMP=OFF, -DMPI=OFF) and at launch (OMP_NUM_THREADS, mpirun). Start with a working build, then scale threads or processes (Installation).

No parallel block in the input

SCONE does not use a parallel { mode = ... }-style deck block. OpenMP and MPI are configured in CMake, not in *.inp. Domain decomposition, hybrid controls, or load-balancing keywords are not input-deck features.

How SCONE parallelizes

OpenMP adds shared-memory threads (histories run across threads). MPI links multiple processes for distributed-memory runs when you build with MPI=ON and launch with your site's MPI starter (e.g. mpirun / srun)—confirm the exact command with your cluster docs and SCONE version. Practical knobs:

CMake: OPENMP and MPI options (defaults ON upstream).
OpenMP runtime: OMP_NUM_THREADS before ./build/scone.out.
Input workload: pop, active, and inactive set how much work each run does.

Building with CMake (not a manual gfortran line)

Do not compile a single scone_main.f90 by hand—the project is built as scone.out via CMake. OpenMP flags are applied by the build system when OPENMP=ON.

build_scone.sh

# Build from the SCONE repo with CMake (OpenMP and MPI are CMake options; both default ON upstream)
git clone https://github.com/CambridgeNuclear/SCONE.git
cd SCONE
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -j$(nproc 2>/dev/null || echo 4)

# Laptop / no MPI: -DMPI=OFF (still get OpenMP unless -DOPENMP=OFF)
# cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DMPI=OFF

caalh/ReactorMCBrowse files

Tutorial snippet — no separate file in examples repo

Running with Multiple Threads

Set OMP_NUM_THREADS before launching the executable. The value should match the number of physical cores (or logical cores) you want to use.

run_scone_threads.sh

# Run with 4 OpenMP threads (Linux/macOS)
export OMP_NUM_THREADS=4
./build/scone.out input.inp

# Or inline for a single run
OMP_NUM_THREADS=4 ./build/scone.out input.inp

# Windows (PowerShell)
$env:OMP_NUM_THREADS = 4
.\build\scone.out input.inp

caalh/ReactorMCBrowse files

Tutorial snippet — no separate file in examples repo

Input Settings That Affect Parallel Performance

The pop, active, and inactive parameters control how many particles and cycles are run. Larger values increase total work and can improve parallel scaling, but also increase runtime and memory. The listing below is a complete testLib deck (same file as scone-examples/verify/tutorial_parallel_eigen_sample_testlib)—no ellipses.

tutorial_parallel_eigen_sample_testlib

// ===================================================================
// Parallel page — minimal full eigen deck (no ellipses); testLib
// Use with OMP_NUM_THREADS after building SCONE with OpenMP.
// ===================================================================
type eigenPhysicsPackage;
pop      5000;
active   20;
inactive 10;
XSdata   ce;
dataType ce;
collisionOperator { neutronCE { type neutronCEstd; } }
transportOperator { type transportOperatorDT; }
inactiveTally {}
activeTally {
  fissionRate { type collisionClerk; response (fission); fission { type macroResponse; MT -6; } }
}
geometry {
  type geometryStd;
  boundary (0 0 0 0 0 0);
  graph { type shrunk; }
  surfaces {
    cellBound { id 5; type zSquareCylinder; origin (0.0 0.0 0.0); halfwidth (0.63 0.63 0.0); }
  }
  cells { }
  universes {
    root { id 1; type rootUniverse; border 5; fill u<31000>; }
    pin  { id 31000; type pinUniverse; radii (0.39218 0.40005 0.45720 0.0); fills (UO2 Water Water Water); }
  }
}
nuclearData {
  handles { ce { type aceNeutronDatabase; aceLibrary $SCONE_ACE; } }
  materials {
    Water { temp 600; composition { 1001.03 6.67e-02; 8016.03 3.33e-02; } }
    UO2   { temp 600; composition { 92235.03 4.50e-02; } }
  }
}

caalh/ReactorMCBrowse filesscone-examples/verify/tutorial_parallel_eigen_sample_testlib

Verify harness (testLib + run_all.ps1)

Key Parameters

pop: Neutrons per cycle (production decks often use 10⁴–10⁵+).
active: Active cycles for tally statistics.
inactive: Discarded cycles for source convergence.

What the input deck does not configure

These are not ordinary input-file features (they are build- or launcher-level):

parallel { mode = ... } or any dedicated parallel block in the deck
Domain decomposition or load-balancing keywords in the input
settings { ... } input block

MPI+OpenMP can both be enabled in one build; how you launch (threads per rank, ranks per node) is environment- and platform-specific.

Best Practices

Match OMP_NUM_THREADS to available cores.
Use enough pop and active cycles for statistically meaningful results.
Ensure sufficient inactive cycles for source convergence.
For large problems, consider memory per thread when scaling.