Skip to content

Use direction of travel when looking up weight window mesh bin - #4156

Open
GuySten wants to merge 3 commits into
openmc-dev:developfrom
GuySten:claude/awesome-euler-9x8m53
Open

GuySten wants to merge 3 commits into
openmc-dev:developfrom
GuySten:claude/awesome-euler-9x8m53

Conversation

@GuySten

@GuySten GuySten commented Oct 2, 2026

Copy link
Copy Markdown
Contributor

Description

When a geometry surface coincides with a plane of the weight window mesh, the weight window lookup at a surface checkpoint is done with the particle sitting exactly on that plane. The structured mesh index lookups (lower_bound_index for rectilinear meshes, ceil for regular meshes) resolve a position exactly on an element boundary to the element on the lower-coordinate side. As a result, a particle crossing such a surface in the +x/+y/+z direction is assigned the window of the element it is leaving, while a particle crossing in the opposite direction happens to get the correct one.

This was reported on Discourse (OpenMC's gamma transport with WW just slow or am I doing something wrong?) for a Cs-137 source in a W/Pb cask using ADVANTG weight windows whose mesh planes match the geometry. It showed up as an anisotropic relative error distribution and a much lower FOM than MCNP with the same weight windows. Another forum user traced the asymmetry to the weight-window lookup at surface checkpoints.

This PR offsets the lookup position by TINY_BIT along the particle's direction of travel in WeightWindows::get_weight_window, so a particle on a mesh boundary is assigned to the element it is entering. This is the same approach already used for tracklength mesh tallies in StructuredMesh::bins_crossed. Away from mesh boundaries the 1e-8 cm offset has no effect.

On a symmetric multigroup shielding problem with geometry planes on mesh planes and surface-only checkpoints, the relative error on the +x/+y/+z faces dropped from about 0.025 to about 0.016, matching the -x/-y/-z faces within statistics.

Checklist

  • I have performed a self-review of my own code
  • I have run clang-format (version 18) on any C++ source files (if applicable)
  • I have followed the style guidelines for Python source files (if applicable)
  • I have made corresponding changes to the documentation (if applicable)
  • I have added tests that prove my fix is effective or that my feature works (if applicable)

claude added 2 commits October 2, 2026 06:11
When a geometry surface coincides with a weight window mesh plane, the
surface checkpoint looks up the weight window with the particle sitting
exactly on the plane. Structured mesh index lookups resolve an exact
boundary position to the lower-coordinate element, so particles crossing
in the +x/+y/+z direction were assigned the window of the element they
were leaving. This produced asymmetric splitting/rouletting and a
direction-dependent loss of FOM (reported on Discourse for a gamma
shielding problem using ADVANTG weight windows whose mesh planes match
the geometry).

Nudge the lookup position by TINY_BIT along the direction of travel, as
is already done for tracklength mesh tallies, so the particle is
assigned to the element it is entering.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014RN7JroEkrbkLKVHbMDap9
@GuySten GuySten added the Bugs label Oct 2, 2026
Both tests apply weight windows at surface checkpoints on geometry
surfaces that coincide with weight window mesh planes. In the survival
biasing test, the reflective planes at x, y, z = 0 lie on the lower edge
of the mesh, so particles reflecting off them were previously found
outside the mesh and no window was applied; in the bootstrap test, a
cavity face lies on an interior mesh plane.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014RN7JroEkrbkLKVHbMDap9
@GuySten
GuySten marked this pull request as ready for review October 2, 2026 23:17
@GuySten
GuySten requested a review from pshriwise as a code owner October 2, 2026 23:17
@yrrepy yrrepy mentioned this pull request Oct 3, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants