Fix bugs in calls to vertical mixing within timesteppers - #488
Conversation
Also use getters to access state instead of raw access
| // Re-exchange halos after vertical mixing | ||
| Pacer::timingBarrier("ForwardBackward:vMixHaloExchBarrier", 3, Comm); | ||
| Pacer::start("ForwardBackward:vMixHaloExch", 3); | ||
| State->exchangeHalo(VelCurLevel); | ||
| Tracers::exchangeHalo(VelCurLevel); | ||
| Pacer::stop("ForwardBackward:vMixHaloExch", 3); |
There was a problem hiding this comment.
Alternatively we could move this to the end of VertMix::VertMixImplicit so that each time stepper did not have to manually call the halo exchange.
Seems like the more self contained approach and less error prone for when more time steppers are added in the future.
I'm just not that familiar with VertMix, so not sure if there are downsides I'm not considering.
|
CIME Testing:Rebasing onto #470 Testing (all-pass):
Note: with 03e986a (from #470) the default timestepper is changed to |
|
@hyungyukang and @mwarusz, you seem like the best reviewers. Please take a look or suggest alternative reviewers if you don't have time. |
|
@andrewdnolan , thanks for opening this bug fix PR. It looks like shear vertical mixing is the source of the non-BFB behavior. With only background and convective vertical mixing enabled, the implicit vertical mixing remains BFB across different numbers of GPUs and CPU cores. I’m investigating it further. |
|
After digging into it further, I found that Omega/components/omega/src/ocn/VertMix.h Lines 113 to 179 in 061d0ab One communication-efficient solution would be to perform a halo exchange for GradRichNum after it is computed.
However, following the MPAS-Ocean approach and the suggestion in this PR, a more robust solution would be to perform halo exchanges after applying the implicit vertical mixing: Omega/components/mpas-ocean/src/mode_forward/mpas_ocn_time_integration_split_ab2.F Lines 2694 to 2740 in 061d0ab If we go with this approach, I would suggest computing the implicit vertical mixing only for owned cells/edges to avoid unnecessary computations in the halo regions. I'd be happy to help implement this. @mwarusz , what do you think about this approach? |
mwarusz
left a comment
There was a problem hiding this comment.
The fixes look fine to me. CTests pass on perlmutter cpu and gpu.
If we go with this approach, I would suggest computing the implicit vertical mixing only for owned cells/edges to avoid unnecessary computations in the halo regions. I'd be happy to help implement this.
@mwarusz , what do you think about this approach?
Sounds good to me.
hyungyukang
left a comment
There was a problem hiding this comment.
I'm approving this PR based on my testing (E3SM-Project/polaris#683 (comment)) and visual inspection.
Once this PR is merged, I will open a follow-up PR to compute implicit vertical mixing only over owned cells/edges, avoiding unnecessary computations in the halo regions.
|
Thanks for looking into the details @hyungyukang. Sounds like a good plan of action to me! |
|
Passes all Polaris
|
|
Passes with local merge: |
|
Passes CTests on pm-gpu and pm-cpu. Expected diffs and errors unrelated to this PR for Polaris
|
- Bring in diffs due to vertical mixing fix which addresses ERS and PEM tests (E3SM-Project/Omega#488)


Addresses two issue when calling
VertMixfrom the time stepping loop which were causing ERS tests for fail:VertMixImplicitVertMixImplicitmodifies state variables.Fixes #487
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