Variance Reduction - SCONE

Important Limitation

SCONE's variance reduction capabilities are limited compared to production codes like MCNP or SERPENT. SCONE does not support weight windows, DXTRAN spheres, exponential transform, cell importance maps, or source biasing as input-deck features. Advanced VR techniques would require modification of SCONE's Fortran source code.

Why Variance Reduction Matters

Monte Carlo simulations can be computationally expensive, especially when tracking particles through thick materials or measuring rare events. Variance reduction techniques help focus computational effort where it matters most. If you have experience with MCNP or SERPENT, you may be familiar with weight windows, implicit capture, splitting/roulette, and DXTRAN. SCONE supports only a subset of these concepts through its input deck.

Common VR Concepts (for Reference)

Implicit capture: Absorb particles with reduced weight instead of terminating them; reduces variance in absorbing regions.
Weight windows: Split or roulette particles based on spatial/energy bounds; not available in SCONE input.
DXTRAN spheres: Force particles toward small detectors; not available in SCONE input.
Exponential transform: Bias path lengths in deep-penetration problems; not available in SCONE input.

What SCONE Supports: Collision Operator

SCONE configures collision behavior through the collisionOperator block. The standard neutron continuous-energy operator is neutronCEstd. Analog vs implicit capture behavior is determined by the collision operator implementation, not by a separate variance_reductionblock. There is no variance_reduction { ... }, weight_windows,exponential_transform, or dxtran in SCONE input syntax.

Correct SCONE Input Structure

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 { ... } cells { ... } universes { ... } }
nuclearData { handles { ce { type aceNeutronDatabase; aceLibrary /path; } } materials { ... } }
inactiveTally {}
activeTally { fissionRate { type collisionClerk; response (fission); fission { type macroResponse; MT -6; } } }

The collisionOperator block uses semicolon-terminated key-value pairs and nested curly braces. The collision operator controls how neutrons interact at collision sites; any implicit-capture or weight-control logic is built into the operator type, not specified via separate VR cards.

What Does Not Exist in SCONE Input

The following constructs are not valid SCONE syntax. Do not use them in your input deck.

variance_reduction { ... }
weight_windows { mesh cartesian ... }
exponential_transform
dxtran
cell_importances or importance maps
source_biasing
Any ... end block terminators (SCONE uses })

Improving Efficiency Within SCONE's Limits

Within the constraints of the input deck, you can still improve simulation efficiency:

Increase pop and active cycles for better statistics.
Use appropriate inactive cycles to allow source convergence.
Choose tally responses and maps that match your problem (e.g., fission rate with spatial maps).
Ensure nuclear data and geometry are correctly specified to avoid wasted particles.

Advanced VR: Source Code Modification

SCONE is a research/educational code with a modular Fortran architecture. Adding weight windows, DXTRAN, exponential transform, or cell importance maps would require extending the collision operator, transport operator, or tally logic in the source code. There is no input-deck hook for these features. If your application demands advanced variance reduction, consider using MCNP, SERPENT, or OpenMC, which support these techniques natively.

Next Steps

SCONE runs in parallel using OpenMP (shared memory). The Parallel Computing section explains how to compile with OpenMP and control thread count at runtime.

Continue to Parallel Computing

SCONE Guide

SCONE Verification Notice

Variance Reduction in SCONE