Add vertical mixing tendencies#410
Conversation
TestingCTest unit tests
Polaris
|
|
Tested this branch using Here are results of
|
|
@katsmith133 ,
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. |
7503bfb to
72ab187
Compare
fd950d6 to
5abe72c
Compare
|
Test results from |
f280be8 to
d272fbe
Compare
d272fbe to
f2a132f
Compare
|
@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. |
- Implemented implicit vertical mixing using TriDiagDiffSolver. - Added applyVertMixImplicit to VertMix. - Applied vertical mixing once at the end of each time step. - Note: Tangential velocity is temporarily handled in VertMix.
f2a132f to
abbc5c2
Compare
katsmith133
left a comment
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Is this temporary handling to be addressed in a later PR?
|
|
||
| } // end defineIOFields | ||
|
|
||
| // Apply implicit velocity vertical mixing |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
Do we want more descriptive names for these variables (D, H, and X)?





This PR adds the velocity and tracer vertical mixing tendency terms. The implicit vertical mixing is solved by using
TriDiagDiffSolverand is applied once at the end of each time step.TriDiagDiffSolver.VertMixImplicittoVertMix.ComputeGradRichardsonNuminVertMix, is temporarily handled inVertMix.This PR includes #352 for testing purposes.
Checklist
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