ExperimentalGuided course track

Zero to full-core BEAVRS

A sequenced path through ReactorMC's existing tutorials: Monte Carlo fundamentals, your code's basics, geometry and materials, a pin cell, a 17×17 assembly, tallies and analysis — ending at the MIT BEAVRS full-core benchmark. Each module has a hands-on checkpoint you verify with the BelvoirDynamics tools.

This track is experimental: it sequences and links pages that already exist rather than adding new lesson content, and its structure may change. Progress is stored only in this browser (localStorage) — nothing is uploaded.

Your progress

0 of 9 checkpoints complete

Your code

The path is the same for all four codes; this switches which code-specific reading each module shows. You can change it at any time.

1

Module 1: Monte Carlo foundations & choosing your code

Understand what a Monte Carlo transport calculation actually does — random sampling, the Boltzmann equation, and why every result carries a statistical uncertainty — then pick the code you will carry through the rest of the course.

Checkpoint

Build: Read the code comparison page and pick your primary code for this course (you can switch the tabs below at any time). Then install OWEN in VS Code or Cursor — the later checkpoints use its tools. GROVES (desktop) or NICHOLS (Sublime Text / Notepad++) work too, but the checkpoint wording follows OWEN's command names.

Verify: Paste any example deck from this site into a new file and run Validate Input Deck on it — confirming the toolchain works before you have anything of your own to check.

Expect: The validator runs and reports its findings on the example deck. Self-check from the reading: you should be able to explain why a finite reactor is critical at k-eff = 1 while its lattice k-infinity must be greater than 1 to pay for leakage.

Validate Input DeckOWEN commands
2

Module 2: Install your code & run a first input

Get your chosen code installed and execute a minimal input end to end, so every later module is about physics and modeling rather than toolchain problems.

Checkpoint

Build: Run the minimal first-input deck from your code's tutorial exactly as written, without modifying it.

Verify: Point OWEN at your executable (owen.<code>.* settings) and use Run Simulation, or run from the command line — then confirm the run completed and a k-effective with an uncertainty was printed.

Expect: A clean run that converges. As one calibrated reference: the Serpent first-simulation tutorial's reflective pin problem lands around k ≈ 1.2–1.3 — well above 1.0 because reflective boundaries remove leakage. Your code's first example will differ; what matters here is a completed run and a quoted uncertainty, not a specific value.

Run SimulationValidate Input DeckOWEN commands
3

Module 3: Geometry: surfaces, cells & CSG

Learn constructive solid geometry the way all four codes use it — surfaces with senses, Boolean cell regions, and the discipline of leaving no gaps or overlaps.

Checkpoint

Build: From scratch, build the classic three-region pin geometry: a fuel cylinder inside a cladding annulus inside a square water cell (no lattice yet, dummy materials are fine).

Verify: Open it in 3D Geometry Preview and orbit the model, then run Validate Input Deck to catch undefined regions, overlaps, and sense mistakes the picture can hide.

Expect: Three concentric regions with no gaps: every point in the problem belongs to exactly one cell, and the validator reports no geometry errors. No physics numbers yet — this module is purely about airtight geometry.

3D Geometry PreviewValidate Input DeckOWEN commands
4

Module 4: Materials & nuclear data

Define real reactor materials — UO2 fuel, Zircaloy cladding, borated water — and understand what the code does with them: nuclide identifiers, evaluated libraries, temperatures, and thermal scattering.

Checkpoint

Build: Give your pin geometry real materials: ~4%-enriched UO2 fuel, Zircaloy cladding, and water — with S(α,β) thermal scattering applied to the water only (never to the fuel: the kernel describes hydrogen bound in H2O).

Verify: Run Validate Input Deck on the updated deck, then open ALLEN Cross-Sections and plot U-238 capture to see the resonance structure your fuel now carries.

Expect: The validator passes, and in ALLEN the U-238 (n,γ) curve shows the resolved resonance region — sharp capture peaks starting at a few eV — which is exactly the physics that Doppler broadening and self-shielding act on in later modules. Qualitative check only; no k-eff yet.

Validate Input DeckALLEN Cross-SectionsOWEN commands
5

Module 5: The pin cell: your first real eigenvalue calculation

Combine geometry and materials into a reflected PWR pin cell, run a criticality calculation, and read the result critically — value, uncertainty, and convergence.

Checkpoint

Build: Build and run a reflected pin cell — either your own deck from modules 3–4 or the ready-made pin-cell prebuilt model that Input Builder offers for all four codes.

Verify: Validate Input Deck, then Run Simulation, then open the output with View Results to read k, its uncertainty, and the convergence behavior.

Expect: A reflected fresh pin is strongly supercritical: the MCNP example page quotes k-infinity typically 1.3–1.5 for fresh 4% fuel at that moderation ratio, and the Serpent example quotes roughly 1.31–1.35 for a 4.5%-enriched pin. With ~1.25 million active histories, expect a k uncertainty around 0.0002–0.0005 (MCNP example page). If you land far outside that band, check enrichment, densities, boundary conditions, and the S(α,β) card first.

Input BuilderValidate Input DeckRun SimulationView ResultsOWEN commands
6

Module 6: Assemblies: universes & lattices

Scale from one pin to a 17×17 PWR assembly using the universe/lattice machinery every code shares — repeated pin universes, guide tubes, and an assembly-pitch boundary.

Checkpoint

Build: Build a 17×17 assembly at 1.26 cm pin pitch with the real Westinghouse layout: 24 guide tubes plus the central instrument tube (25 non-fuel positions). Lattice Builder can generate the lattice block for any of the four codes so you don't hand-type 289 entries.

Verify: Inspect it in 3D Geometry Preview — count the guide-tube positions and check the pattern's symmetry — then Run Simulation and View Results for the pin-power distribution.

Expect: The Serpent assembly example quotes pin-power peaking of roughly 1.15–1.25, with the hottest pins adjacent to the water-filled guide tubes — extra moderation raises local thermal flux. k-infinity stays in the same supercritical ballpark as the pin cell; the new result to study is the power map, not the eigenvalue.

Lattice Builder3D Geometry PreviewRun SimulationView ResultsOWEN commands
7

Module 7: Tallies, results & statistical analysis

Extract physics beyond k-eff — fluxes, spectra, reaction rates — and judge whether the statistics behind each number can be trusted.

Checkpoint

Build: Add an energy-binned flux tally (spectrum) to your assembly or pin cell and rerun it.

Verify: Open the run in View Results and look at the flux spectrum plot alongside the k-eff convergence trace; check the relative errors on your tally bins.

Expect: A recognizable LWR spectrum: a thermal peak (Maxwellian around ~0.025 eV at room temperature, shifted with moderator temperature), a 1/E slowing-down region pocked by resonance dips, and a fast fission hump around 1–2 MeV. Statistically, aim for tally relative errors below a few percent in the bins you care about — if they are larger, run more histories rather than over-reading noise.

Run SimulationView ResultsOWEN commands
8

Module 8: Cross-code fluency: the Rosetta Stone

Cement what is concept versus what is syntax by expressing the same model in a second code — the fastest way to make your knowledge portable across MCNP, OpenMC, Serpent, and SCONE.

Checkpoint

Build: Translate your pin cell into a second code. Use Convert Deck for a first-pass mechanical translation (MCNP↔OpenMC, plus MCNP→Serpent/SCONE), then finish any flagged constructs by hand with the Rosetta Stone open beside you.

Verify: Validate Input Deck on the translated deck, Run Simulation in the second code, and compare both k values in View Results.

Expect: The two codes agree on k within combined statistical uncertainties plus a small nuclear-data bias — different evaluated libraries (ENDF/B, JEFF) legitimately shift k by a few hundred pcm, so identical geometry and materials need not mean identical k to the fourth decimal. A large gap means a modeling difference, not 'codes disagree'.

Convert DeckValidate Input DeckRun SimulationView ResultsOWEN commands
9

Module 9: Capstone: the full-core BEAVRS benchmark

Apply everything to a real benchmark — the MIT BEAVRS Westinghouse 4-loop PWR: 193 assemblies, three enrichment zones, burnable poisons, baffle, barrel, and vessel.

Checkpoint

Build: Download the BEAVRS full-core deck for your code from the Community Library benchmark page and study how the deck composes everything you built in modules 3–7. If your hardware allows (full-core eigenvalue runs need substantial memory and CPU), run it with a modest particle count.

Verify: Explore the core in 3D Geometry Preview — OWEN ships a full-core BEAVRS preview with measurement tools — then, if you ran it, read the eigenvalue and convergence in View Results.

Expect: BEAVRS Cycle 1 hot zero power with all rods out and ~975 ppm soluble boron should sit near k-eff ≈ 1.0. The site's verified runs: the author-verified SCONE deck re-run with ENDF/B-VIII.0 gave k-eff = 0.98906 ± 0.00019, and the run-verified OpenMC translation gave k-eff = 0.99737 ± 0.00030 (100k particles/cycle, 40 inactive + 100 active cycles). The MCNP and Serpent decks are spec-derived translations that have not been benchmark-validated — expect the same ballpark, but treat their numbers accordingly.

3D Geometry PreviewRun SimulationView ResultsOWEN commands

Checkpoint verification refers to OWEN command names (the VS Code & Cursor extension); GROVES offers the same workflows on the desktop, and NICHOLS covers Sublime Text and Notepad++. Every expected result above is taken from this site's audited example pages and verified benchmark decks — where a range is wide, that honestly reflects how much enrichment, moderation, and nuclear-data library choices move the answer.

Feedback on this experimental track is welcome — it links existing pages rather than replacing them, so the full per-code tutorials remain the reference.