Skip to content

Add vertical mixing tendencies#410

Open
hyungyukang wants to merge 15 commits into
E3SM-Project:developfrom
hyungyukang:omega/vmix-hookup
Open

Add vertical mixing tendencies#410
hyungyukang wants to merge 15 commits into
E3SM-Project:developfrom
hyungyukang:omega/vmix-hookup

Conversation

@hyungyukang

@hyungyukang hyungyukang commented May 18, 2026

Copy link
Copy Markdown

This PR adds the velocity and tracer vertical mixing tendency terms. The implicit vertical mixing is solved by using TriDiagDiffSolver and is applied once at the end of each time step.

  • Implemented implicit vertical mixing using TriDiagDiffSolver.
  • Added VertMixImplicit to VertMix.
  • Applied vertical mixing once at the end of each time step.
  • Note: Tangential velocity, which is required by ComputeGradRichardsonNum in VertMix, is temporarily handled in VertMix.

This PR includes #352 for testing purposes.

Checklist

  • Linting
  • Building
    • CMake build does not produce any new warnings from changes in this PR
  • Testing
    • Add a comment to the PR titled Testing with the following:
      • Which machines CTest unit tests
        have been run on and indicate that are all passing.
      • The Polaris omega_pr test suite
        has passed, using the Polaris e3sm_submodules/Omega baseline
      • Document machine(s), compiler(s), and the build path(s) used for -p for both the baseline (Polaris e3sm_submodules/Omega) and the PR build
      • Indicate "All tests passed" or document failing tests

@hyungyukang

Copy link
Copy Markdown
Author

Testing

CTest unit tests

  • Machine: frontier
  • Compiler: craygnu, craygnu-mphipcc
  • Build type: Release
  • Result: All tests passed

Polaris omega_pr suite

  • Baseline workdir: /lustre/orion/cli115/proj-shared/hgkang/E3SM/OMEGA/Polaris/work/pr_suite/260518_09_vMix_PR/baseline_omega
  • Baseline build: /lustre/orion/cli115/proj-shared/hgkang/E3SM/OMEGA/Polaris/polaris_main/e3sm_submodules/Omega
  • PR build: /lustre/orion/cli115/proj-shared/hgkang/E3SM/OMEGA/Omega_hyun_vmixHook_2
  • PR workdir: /lustre/orion/cli115/proj-shared/hgkang/E3SM/OMEGA/Polaris/work/pr_suite/260518_09_vMix_PR/branch_omega
  • Machine: frontier
  • Partition: batch
  • Compiler: craygnu
  • Build type: Release
  • Log: /lustre/orion/cli115/proj-shared/hgkang/E3SM/OMEGA/Polaris/work/pr_suite/260518_09_vMix_PR/branch_omega/polaris_omega_pr.o4609310
  • Result: All tests passed

@hyungyukang

hyungyukang commented May 18, 2026

Copy link
Copy Markdown
Author

Tested this branch using ocean/column/vmix_stable from E3SM-Project/polaris#435 and compared with MPAS-O.

Here are results of vmix_stable/forward:

  • Temperature at day 10:
image
  • Normal velocity at day 10:
image

@hyungyukang

Copy link
Copy Markdown
Author

@katsmith133 ,
Here're figures of VertVisc and VertDiff (vertViscTopOfCell and vertDiffTopOfCell in MPAS-O, respectively):

  • VertVisc at day 10:
image
  • VertDiff at day 10
image

I will retest your branch with this test case since you've updated it.

@katsmith133

Copy link
Copy Markdown

@katsmith133 , Here're figures of VertVisc and VertDiff (vertViscTopOfCell and vertDiffTopOfCell in MPAS-O, respectively):
...
I will retest your branch with this test case since you've updated it.

@hyungyukang, thanks for the plots! I doubt the updates I just made in #352 will result in any difference here, but doesn't hurt to check. Let me pull down this branch and take a look at things and see if anything pops out to me.

@hyungyukang hyungyukang force-pushed the omega/vmix-hookup branch 5 times, most recently from 7503bfb to 72ab187 Compare May 27, 2026 13:54
@hyungyukang hyungyukang force-pushed the omega/vmix-hookup branch 3 times, most recently from fd950d6 to 5abe72c Compare June 2, 2026 01:07
@katsmith133 katsmith133 self-requested a review June 3, 2026 15:35
@hyungyukang

hyungyukang commented Jun 4, 2026

Copy link
Copy Markdown
Author

Test results from column/vmix_stable/forward_no_vadv in Polaris is posted here: #352 (comment)

@hyungyukang

Copy link
Copy Markdown
Author

I fixed the bugs related to non-flat bottom topography and ran the overflow test to compare Omega with MPAS-O. MPAS-O was slightly modified to exclude horizontal FCT, since it has not yet been implemented in Omega.

The results below show temperature at 6 hours.

image

@sbrus89 sbrus89 requested a review from mwarusz June 17, 2026 15:18
@cbegeman

Copy link
Copy Markdown

@hyungyukang The PR doesn't include bottom drag in the implicit mixing, correct? So we will continue to use explicit bottom drag with implicit vmix?

@hyungyukang

Copy link
Copy Markdown
Author

@hyungyukang The PR doesn't include bottom drag in the implicit mixing, correct? So we will continue to use explicit bottom drag with implicit vmix?

@cbegeman , Yes, the implicit bottom drag is not included in this PR. I plan to open a separate PR for it after this one is merged.

@cbegeman cbegeman self-requested a review June 22, 2026 15:15

@katsmith133 katsmith133 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

My comments aren't super major, except for whether we want to split the vertical mixing stuff up in some way in anticipation of having multiple parameterizations.

GradRichNumSmoothed = Array2DReal("GradRichNumSmoothed", Mesh->NCellsSize,
VCoord->NVertLayersP1);

// TODO: Temporary handling of TangentialVelocity

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Is this temporary handling to be addressed in a later PR?


} // end defineIOFields

// Apply implicit velocity vertical mixing

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

In MPAS-O we have several files for the vertical mixing. One that handles the below calculations and several that do the computation of the coefficients (either from KPP or something else). Do we want to follow that design choice here in Omega? I feel like it might be good, as we add more mixing parameterizations, to have them split off more? Thoughts @vanroekel?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Yes I think so. This is what I'm doing in the forthcoming KPP PR. It's its own class in its own file.

0.5_Real * (VertVisc(JCell0, K + 1) + VertVisc(JCell1, K + 1)) /
(LocRhoSw * SpecVolEdgeTop);

G = DT * ViscAlphaEdgeTop / PseudoThickEdgeTop;

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Do we want more descriptive names for these variables (D, H, and X)?

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants