Fix inactive layer guard in gradient Richardson number computation - #518
Conversation
There was a problem hiding this comment.
Pull request overview
This PR fixes an inactive-layer guard in the gradient Richardson number
computation (Omega vertical mixing), addressing Issue #500 by ensuring edge
contributions are skipped when they would access inactive layers.
Changes:
- Update
GradRichardsonNumto guard usingMaxLayerEdgeTop(rather than the
deeper-side bound), preventing accesses into inactive layers. - Refactor
testGradRichNumsetup to rely more on mesh-provided connectivity,
add halo exchange afterMaxLayerCelledits, and set inactive-layer data to
fill values to catch erroneous access. - Adjust test sequencing by resetting min/max layer bounds at the end of
testGradRichNumand refreshing edge ranges.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| components/omega/test/ocn/VertMixTest.cpp | Updates vertical mixing tests to reflect corrected inactive-layer guarding and halo/range handling. |
| components/omega/src/ocn/VertMix.h | Fixes the Richardson-number functor guard to use MaxLayerEdgeTop for inactive-layer safety. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
3a56895 to
0f0b2e1
Compare
|
@katsmith133, would you mind reviewing this? |
TestingCTest unit tests
Polaris
|
Can do! Just did a quick read through of the code and it makes sense to me. I want to test it on PM. I can finish that up in the morning tomorrow. |
|
I believe PM is down today, but that would be great if you could test there. Thanks! |
Testing on PerlmutterCTest unit tests (CPU):
CTest unit tests (GPU):
I get the following compile errors with Polaris
|
0f0b2e1 to
edf086a
Compare
|
@mwarusz and @sbrus89 Since this currently has this issue in it: E3SM-Project#8650 and the PR that will pull that in to Omega (#521) is having some other issues to work out, would you prefer I hold off on testing this on PM-GPU? Or should I cherry pick E3SM-Project#8650's fix and test that way? Note that after today I will be gone for a week on PTO, so someone else might need to do the PM-GPU testing if we wait for #521. |
|
@katsmith133, I think you can go ahead and approve based on your other testing. I can take care of testing on pm-gpu once #521 is merged. Thanks for your other testing on pm! |
katsmith133
left a comment
There was a problem hiding this comment.
Approving based upon visual inspection and testing on PM, as well as testing by others on additional machines.
Assuming re-testing will pass on PM-GPU once #521 is merged.
|
Local merge passes CTests and Polaris
|
Fixes #500
While fixing the Richardson number functor was trivial, adapting the vertical mixing test to this change turned out to be more complicated. I made the following changes to this test:
CellsOnCellandNEdgesOnCell. This test in now passing with the arrays read from the mesh file.MaxLayerCellintestGradRichNum.BruntVaisalaFreqSqandGeomZMidto fill values in inactive layers intestGradRichNum.MinLayerCellandMaxLayerCellto 0 andNVertLayers, respectively, fromtestOneTwoOneFilterto the very end oftestGradRichNum. I added a call toVertCood::minMaxLayerEdgeright after to make the edge ranges consistent.Checklist
Linting
Building
Testing
aurora, oneapi-ifx, mpich
chrysalis, oneapi-ifx, openmpi
frontier, craygnu, mpich
frontier, craygnu-mphipcc, mpich
pm-cpu, gnu, mpich
pm-gpu, gnugpu, mpich
Provide relevant details in a comment to the PR titled
Testingwith the following:have been run on and indicate that are all passing.
has passed, using the Polaris
e3sm_submodules/Omegabaseline-pfor both the baseline (Polarise3sm_submodules/Omega) and the PR build