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.
Neutron Transport in SCONE
Collision and transport operators, delta vs. surface tracking
Read Basics first — the same collisionOperator and transportOperator lines appear in every criticality deck. The delta-tracking lines below match tutorial_config_testlib; the surface-tracking pair swaps only the transport type (not part of the testLib harness). The header excerpt uses the same pop/active/inactive as that verified deck — scale up for production after debugging.
Transport Fundamentals
Neutron transport simulation tracks particles as they move through materials and undergo collisions. The collision operator determines what happens at each collision site (which nuclide, which reaction, secondary particles). The transport operator determines how particles move between collisions—how far they go and when they cross material boundaries.
SCONE offers three transport operators per the Input Manual: transportOperatorDT (Woodcock delta tracking), transportOperatorST (surface / ray tracing), and transportOperatorHT (hybrid, with a cutoff between DT and ST). Global geometry boundaries use integers 0 (vacuum), 1 (reflective), and 2 (periodic) for box-like outer surfaces; the manual notes that exotic surfaces may interpret these differently and that curved surfaces only allow vacuum. If you mix periodic/reflective boundaries with ST, validate against your SCONE version's docs—do not assume every BC works with every operator without testing.
inactiveTally {}Verify harness (testLib + run_all.ps1)
The collisionOperator block configures how neutron collisions are handled. neutronCE with type neutronCEstd provides standard continuous-energy collision physics. The transportOperator block selects the tracking method: transportOperatorDT for delta tracking or transportOperatorST for surface tracking.
Delta Tracking vs Surface Tracking
Delta tracking (DT) samples distances to the next collision using the total cross section and uses virtual collisions at material boundaries. It avoids explicit surface crossings and can be efficient for complex heterogeneous geometries. Surface tracking (ST) explicitly tracks particles from surface to surface, which can be preferable when boundaries are well-defined and surface crossings are frequent.
collisionOperator { neutronCE { type neutronCEstd; } }
transportOperator { type transportOperatorST; }Tutorial snippet — no separate file in examples repo
To use surface tracking instead of delta tracking, change transportOperatorDT to transportOperatorST. The collision operator remains the same.
Full Input Context
The transport and collision operators are specified at the top level of the input, alongside the physics package type and population parameters.
Incomplete input — no geometry or nuclearData. Text matches tutorial_config_testlib lines 5–15 (verified in run_all.ps1 as part of the full file).
type eigenPhysicsPackage;
pop 10000;
active 50;
inactive 20;
XSdata ce;
dataType ce;
collisionOperator { neutronCE { type neutronCEstd; } }
transportOperator { type transportOperatorDT; }
inactiveTally {}Verify harness (testLib + run_all.ps1)
Best Practices
Choose tracking methods based on your geometry complexity and material distributions. Delta tracking is often preferred for reactor core problems with many material interfaces. Surface tracking may perform better for simpler geometries with few surfaces. Test transport settings with simplified problems before scaling to full complexity.