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

SCONE Configuration Files

Introduction

This page now follows the same block-style structure used in your working BEAVRS-derived input deck. The example below is intentionally close to real SCONE practice instead of a generic pseudo-format.

Basic Structure

A practical configuration includes: package + run controls, operators, geometry, active tallies, and nuclear data/material blocks. Keep aceLibrary pathing portable and test with a small run first. A testLib-compatible version runs in scone-examples/verify/tutorial_config_testlib.

Here's a complete example that demonstrates the essential components:

plaintext

type eigenPhysicsPackage;

pop      100000;
active   300;
inactive 200;
XSdata ce;
dataType ce;

collisionOperator { neutronCE { type neutronCEstd; } }
transportOperator { type transportOperatorDT; }

geometry {
  type geometryStd;
  boundary (0 0 0 0 0 0);
  graph { type shrunk; }

  surfaces {
    outerRPV { id 1; type zTruncCylinder; radius 241.3; origin (0.0 0.0 230.0); halfwidth 230; }
    innerRPV { id 2; type zCylinder;      radius 219.710; origin (0.0 0.0 0.0); }
    coreCyl  { id 5; type zCylinder;      radius 194.84;  origin (0.0 0.0 0.0); }
  }

  cells {
    pressureVessel { type simpleCell; id 7;  surfaces (-1 2); filltype mat; material CarbonSteel; }
    outerWater     { type simpleCell; id 9;  surfaces (-2 5); filltype mat; material Water; }
    core           { type simpleCell; id 17; surfaces (-5);   filltype uni; universe 31000; }
  }

  universes {
    root { id 1; type rootUniverse; border 1; fill u<8888>; }
    coreAndStructures { id 8888; type cellUniverse; cells (7 9 17); }
    pin31 { id 31000; type pinUniverse; radii (0.39218 0.40005 0.45720 0.0); fills (UO2-31 Helium Zircaloy Water); }
  }
}

inactiveTally {}
activeTally {
  fissionRate {
    type collisionClerk;
    response (fission);
    fission { type macroResponse; MT -6; }
  }
}

nuclearData {
  handles {
    ce { type aceNeutronDatabase; aceLibrary /path/to/JEF311.aceXS; }
  }
  materials {
    Water { temp 600; composition { 1001.06 6.5512E-02; 8016.06 3.2683E-02; } }
    CarbonSteel { temp 600; composition { 26056.06 7.4465E-02; 26054.06 4.7437E-03; } }
    UO2-31 { temp 600; composition { 92235.06 7.2175E-04; 92238.06 2.2253E-02; 8016.06 4.5853E-02; } }
    Helium { temp 600; composition { 2004.06 2.4044E-04; } }
    Zircaloy { temp 600; composition { 40090.06 5.0E-03; 40091.06 1.1E-03; 40092.06 1.7E-03; 40094.06 1.7E-03; 40096.06 2.8E-04; } }
  }
}

Advanced Features

For full-core work, the key challenge is consistency rather than clever syntax: aligned IDs, validated surfaces/cells, and physically consistent materials across universes/lattices.

plaintext

# Practical validation checklist
1) Verify all surface IDs are unique in each namespace.
2) Verify each cell's surface sense (inside/outside) matches intent.
3) Plot axial and radial slices before transport runs.
4) Confirm materials referenced by cells exist in nuclearData.materials.
5) Confirm aceLibrary path is valid on the target machine.
6) Run a low-pop smoke test before production pop/active/inactive settings.

Best Practices

Use explicit comments on data provenance (library version, benchmark source, temperatures, boron/impurity assumptions). For benchmark decks, prioritize transparency over compactness.

Validation and Debugging

Debug workflow: plot geometry first, run low-pop criticality next, then scale to production particle counts only after tally behavior and source convergence are sensible.