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.
SCONE Basics
Block-style input structure and minimum working configuration
Build SCONE and know where your executable and ACE library live (Installation). You pass one block-style text file to the binary (often .inp), not separate MCNP/Serpent-style card columns — use ; and nested { } blocks. k-eigenvalue iterates the fission source until keff stabilizes; pop is neutrons per cycle, inactive discard cycles, active tally cycles. ACE is your processed library path in aceLibrary.
Minimum Working Structure
A minimal SCONE input has: physics package, operators, geometry, universes, then tallies. The example below uses a cellUniverse with three annular cells (fuel, clad, water)—same topology as the walkthrough text. The file is imported from scone-examples/verify/tutorial_basics_celluniverse_testlib (testLib: clad uses Water nuclides as a stand-in because Zircaloy isotopes are not in IntegrationTestFiles/testLib).
// ===================================================================
// SCONE Basics page — cellUniverse fuel pin (testLib nuclides)
// Same topology as Basics.tsx: fuel | clad | water rings; clad uses Water
// composition as testLib stand-in (no Zr in testLib).
// Verified: export SCONE_ACE=IntegrationTestFiles/testLib
// ===================================================================
type eigenPhysicsPackage;
pop 10000;
active 50;
inactive 20;
XSdata ce;
dataType ce;
collisionOperator { neutronCE { type neutronCEstd; } }
transportOperator { type transportOperatorDT; }
inactiveTally {}
activeTally {
fissionRate { type collisionClerk; response (fission); fission { type macroResponse; MT -6; } }
}
// ===================================================================
// GEOMETRY
// ===================================================================
geometry {
type geometryStd;
boundary ( 0 0 0 0 0 0 );
graph { type shrunk; }
surfaces {
fuelR { id 1; type zCylinder; radius 0.41; origin (0.0 0.0 0.0); }
cladR { id 2; type zCylinder; radius 0.475; origin (0.0 0.0 0.0); }
cellBound { id 5; type zSquareCylinder; origin (0.0 0.0 0.0); halfwidth (0.63 0.63 0.0); }
}
cells {
fuel { type simpleCell; id 10; surfaces (-1); filltype mat; material fuel; }
clad { type simpleCell; id 11; surfaces (-2 1); filltype mat; material clad; }
water { type simpleCell; id 12; surfaces (2 -5); filltype mat; material water; }
}
universes {
root { id 1; type rootUniverse; border 5; fill u<999>; }
pin { id 999; type cellUniverse; cells (10 11 12); }
}
}
// ===================================================================
// NUCLEAR DATA (testLib)
// ===================================================================
nuclearData {
handles { ce { type aceNeutronDatabase; aceLibrary $SCONE_ACE; } }
materials {
fuel { temp 600; composition { 92235.03 4.50e-02; } }
clad { temp 600; composition { 1001.03 6.67e-02; 8016.03 3.33e-02; } }
water { temp 600; composition { 1001.03 6.67e-02; 8016.03 3.33e-02; } }
}
}
Verify harness (testLib + run_all.ps1)
Production library: keep the same geometry; replace nuclearData with real UO₂ / Zircaloy / water .06 (or your evaluation) and set aceLibrary:
Not in run_all.ps1 as this block alone — nuclearData excerpt only; pair with the verified geometry above and your full ACE library.
nuclearData {
handles { ce { type aceNeutronDatabase; aceLibrary /path/to/your.aceXS; } }
materials {
fuel { temp 600; composition { 92235.06 7.22e-04; 92238.06 2.23e-02; 8016.06 4.59e-02; } }
clad { temp 600; composition { 40090.06 5.00e-03; 40091.06 1.10e-03; 40092.06 1.70e-03; 40094.06 1.70e-03; 40096.06 2.80e-04; } }
water { temp 600; composition { 1001.06 6.67e-02; 8016.06 3.33e-02; } }
}
}Production-style deck — full ACE library
Physics package and run controls
type eigenPhysicsPackage; tells SCONE this is a criticality (k-eigenvalue) calculation. The fission source is iterated until it converges. pop 10000 means 10,000 neutrons per cycle; active 50 means 50 cycles contribute to tallies; inactive 20 means 20 cycles are used first to let the fission source settle before tallying. XSdata ce and dataType ce select continuous-energy nuclear data.
Collision and transport operators
The collisionOperator block configures how neutrons interact at collision sites. neutronCE { type neutronCEstd; } uses standard analog collision physics. The transportOperator block controls how neutrons move between collisions. type transportOperatorDT selects Woodcock delta tracking, which is efficient for heterogeneous geometries. Alternatively, transportOperatorST uses surface tracking (ray tracing).
Tallies
inactiveTally {} is empty when you only score during active cycles. activeTally defines what to accumulate after the source has converged—for example a collisionClerk with fission response MT -6 (total fission). Large decks in this guide (e.g. BEAVRS) place tally blocks before geometry; that matches the repository's cleaned benchmark file.
Geometry: surfaces, cells, universes
The geometry block defines where neutrons travel. surfaces are mathematical boundaries: fuelR and cladR are z-aligned cylinders; cellBound is a square cylinder that defines the pin-cell boundary. cells combine surfaces: the fuel cell is inside cylinder 1 (-1); the clad is between cylinders 1 and 2 (-2 1); the water is between cylinder 2 and the outer boundary (2 -5). The minus sign means "inside" the surface. universes group cells: the root universe fills the cell boundary with the pin universe, which contains the fuel, clad, and water cells.
Nuclear data
The nuclearData block points to an ACE-format cross-section library and defines material compositions. Each material lists nuclides (e.g. 92235.06 for U-235 at 600 K) with atomic densities. Material names must match material in cells and fills in pin universes.
Coming from MCNP or Serpent?
There are no cell/surface cards or mat lines. Instead, everything lives in nested blocks: run controls and operators, then (in full-core examples) inactiveTally / activeTally, then geometry, then nuclearData. Material names in nuclearData.materials must exactly match material keywords in cells.
Mental Model
A SCONE input is organized into a few logical layers. At the top level, pop, active, and inactive control the Monte Carlo run: how many particles per cycle, how many cycles contribute to statistics, and how many cycles are used for source convergence before tallying begins. The data mode (XSdata ce, dataType ce) selects continuous-energy transport.
The collision and transport operators define how neutrons interact with matter and how they are tracked through geometry. The geometry block assembles surfaces, cells, and universes into a coherent spatial model. Finally, the tally blocks specify what is scored during active cycles—fission rates, capture, flux maps, and so on. Understanding this flow makes it easier to locate and fix errors when something goes wrong.