Fixes Omega ssh calculation

[vanroekel]

The current SSH calculation is designed for stacked shallow water only and was causing issues (such as NaNs in the barotropic channel case) in current tests. The SSH calculation is moved to the VertCoord class and computed alongside ZMid and ZInterface

Checklist

• Linting
  • Pre-commit run locally
• 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
    • Document testing used to verify the changes including any tests that are added/modified/impacted.

resolves #321
resolves #332

[xylar]

Shouldn't this be the following?

Suggested change

	if (KLyr == 0) {
	if (KLyr == KMin) {

[vanroekel]

Oh yes, definitely. I'll fix that

[vanroekel]

Testing
Currently have tested the cases in the related issues.

Barotropic channel

With omega/develop layer thickness at the 10th step in the top layer are

array([nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan,
       nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan,
       nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan,
       nan])

with this PR

array([33.32555911, 33.32555911, 33.32555911, 33.32555911, 33.32555911,
       33.32555911, 33.32555911, 33.32555911, 33.32555911, 33.32555911,
       33.34110755, 33.34110755, 33.34110755, 33.34110755, 33.34110755,
       33.34110755, 33.34110755, 33.34110755, 33.34110755, 33.34110755,
       33.34110755, 33.34110755, 33.34110755, 33.34110755, 33.34110755,
       33.34110755, 33.34110755, 33.34110755, 33.34110755, 33.34110755,
       33.32555911, 33.32555911, 33.32555911, 33.32555911, 33.32555911,
       33.32555911, 33.32555911, 33.32555911, 33.32555911, 33.32555911])

In the single column test case, also confirmed that when using pseudoThickness in the input file from polaris the ZMid and ZInterface values look as expected and SshCell is 0 as expected.

Currently running the omega_pr suite on perlmutter. Will update when finished.

[vanroekel]

A note that this PR breaks the manufactured solution tests b/c it provides geometric thickness. This would need the Polaris addition of PseudoThickness and renaming in Omega, or alternatively we could add a bit of code to Omega to convert to pseudothickness if layerthickness is provided. Any thoughts on how to proceed?

[cbegeman]

@vanroekel This draft PR converts geometric thickness to pseudo-thickness in the initial condition E3SM-Project/polaris#460. I have also planned to include in this PR a conversion from pseudo-thickness to geometric thickness in the reading of model output. Would this address the issue you're seeing?

[vanroekel]

@vanroekel This draft PR converts geometric thickness to pseudo-thickness in the initial condition E3SM-Project/polaris#460. I have also planned to include in this PR a conversion from pseudo-thickness to geometric thickness in the reading of model output. Would this address the issue you're seeing?

So in the processing of test results it would convert back? That would be excellent. I do think for the planar manufactured solutions we'd need to provide a temperature / salinity for the pseudo thickness, but if we did I think that + your PR would address things.

[cbegeman]

So in the processing of test results it would convert back? That would be excellent. I do think for the planar manufactured solutions we'd need to provide a temperature / salinity for the pseudo thickness, but if we did I think that + your PR would address things.

Exactly. I'll check in with you about the development timing so that this PR doesn't get held up.

[brian-oneill]

Now that #328 has been merged in, this will need to be rebased carefully. The computeVarsOnCells method is removed here, since SshCell was the only thing computed in it, but for the VertAdv I added a ProvThickness auxiliary variable which is calculated here. So the computeVarsOnCells method should remain, just need to remove the lines calculating the SshCell.

[brian-oneill]

This is fine, you should still remove the LayerThicknessAux.computeVarsOnCells call from computeMomAux. I added it to AuxiliaryState::computeAll in #328 since it is now needed for tracer tendencies, not velocity tendencies.

[cbegeman]

Noting that E3SM-Project/polaris#460 requires SpecVol in output. I propose that we wait to merge until either this PR or another one brings in the ability to output SpecVol.

[cbegeman]

Sometime in between your last test and mine rebased onto 9cd8efb there seems to have been a commit introduced that reverts us back to the NaN behavior. I was testing with #370 so I'll test again without it and report back.

[cbegeman]

@brian-oneill I see you've been working on this branch. Let me know when it's ready for re-testing.
A rebase onto the latest Omega submodule hash would also be appreciated at that point.

[cbegeman]

Polaris testing criteria

1. A non-zero SSH field is correct for a single layer case with flat bathymetry
   Works with develop, e.g. ocean/planar/barotropic_gyre/munk/free-slip at 6 mo

(bottomDepth - layerThickness.sum(dim='nVertLevels') - SSH

2. A non-zero SSH field is correct for a single layer case with variable bathymetry

3. A non-zero SSH field is correct for a multi-layer case with flat bathymetry

4. A non-zero SSH field is correct for a multi-layer case with variable bathymetry

I'm thinking we merge this PR after we get passes for these cases. I'll edit this PR to add the polaris case names for each. Let me know if you have any suggestions.