Skip to content

Fix get_index_in_direction for regular meshes#3948

Open
JoffreyDorville wants to merge 6 commits into
openmc-dev:developfrom
JoffreyDorville:fix_get_index_in_direction_regular_meshes
Open

Fix get_index_in_direction for regular meshes#3948
JoffreyDorville wants to merge 6 commits into
openmc-dev:developfrom
JoffreyDorville:fix_get_index_in_direction_regular_meshes

Conversation

@JoffreyDorville
Copy link
Copy Markdown
Contributor

@JoffreyDorville JoffreyDorville commented May 28, 2026

Description

For regular meshes, the function get_index_in_direction is returning 0 instead of 1 when the tested coordinate is coincident with the lower boundary. This results in points being incorrectly seen outside the mesh when they lie on surfaces corresponding to the lower boundaries of the mesh.

For rectilinear meshes, the function get_index_in_direction works as expected.

I added a cpp unit test to illustrate the problem and to show that this PR fixes it.

This fix also corrected the results of the weightwindows/survival_biasing regression tests which have been updated. I cross-checked that using an equivalent rectilinear mesh instead of the regular mesh in tests/regression_tests/weightwindows/survival_biasing/test.py produces the same results as the updated ones with the fix.

Rectilinear mesh used:

mesh = openmc.RectilinearMesh()
mesh.x_grid = np.linspace(0.0, 160.0, 21)
mesh.y_grid = np.linspace(0.0, 160.0, 21)
mesh.z_grid = np.linspace(0.0, 160.0, 2)

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)

Comment thread src/mesh.cpp
Copy link
Copy Markdown
Contributor

@GuySten GuySten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

@GuySten GuySten added the Merging Soon PR will be merged in < 24 hrs if no further comments are made. label May 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Bugs Merging Soon PR will be merged in < 24 hrs if no further comments are made.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants