Fix indexing of layers in high freq. output

[xylar]

Previously, the layer above the one containing the desired depth was being selected, rather than the layer containing the depth.

The default depth if no layer is found is now the deepest layer, rather than the first layer. This is because, if no layer is found, it means that even the deepest layer is shallower than the desired depth, and the only sensible default is the deepest layer.

non-BFB only for MPAS-Ocean high-frequency output.

Fixes #6496

[xylar]

I successfully ran ERS_Ld5.T62_oQU120.CMPASO-NYF.chrysalis_intel and added some temporary print statements, see:

/lcrc/group/e3sm/ac.xasay-davis/scratch/chrys/ERS_Ld5.T62_oQU120.CMPASO-NYF.chrysalis_intel.20240703_024722_lcosnw

With this fix, I'm seeing:

var                 i    refBottomDepth(i-1)     refBottomDepth(i)
-----------------------------------------------------------------
iLevel0100          26   97.8969986438751        106.103993177414
iLevel0250          38   237.887019395828        254.577030897141
iLevel0700          55   688.487065076828        729.107051134109
iLevel2000          75   1977.58716273308        2074.75707554817

So I do believe the fix is correct and the previous results were incorrect.

[xylar]

@jonbob, I've marked this as non-BFB because I assume high-frequency output is included in E3SM's checks. Could you verify this? And we presumably need to coordinate with @rljacob to find out if this should wait for the maint-3.0 branch or go in before that.

[vanroekel]

Approved by visual inspection and testing from @xylar. In addition to the bug fix I like the switch to the bottom if the layer is not found. Having a surface value in regions shallower than the target depth (as we do now) can lead to confusion in interpretation.

Thanks for the fixes @xylar!

[xylar]

Thanks @vanroekel!

[rljacob]

If high-frequency output is in the 3.0 default output, then yes this should wait.

[xylar]

@rljacob, yes, it is.

[jonbob]

@xylar -- high frequency output is not used in testing BFBness, but it is in the 3.0 default output. So it makes sense to wait

[mark-petersen]

Yes, I agree both based on the logic and your output.

[jonbob]

Passes:

• ERP_Ld3.ne30pg2_r05_IcoswISC30E3r5.WCYCL1850.chrysalis_intel.allactive-pioroot1

merged to next

[jonbob]

merged to master

[rljacob]

I'm not sure why this was labeled v3.1beta. There weren't any diffs to bless.

[rljacob]

Is the high-frequency output not in our production tests? It should be.

[jonbob]

@rljacob -- those files are produced by default in our production tests, but no current testing does cprnc comparisons of mpaso output files

[jonbob]

@rljacob -- I think is was labeled v3.1beta because it would change output for any of the ongoing v3 campaigns, even if it didn't change the state as seen by the coupler

[rljacob]

Its changing a diagnostic quantity and not the prognostic state (or it would cause a diff in the coupler output). Thats a gray area for versioning.

[jonbob]

@rljacob -- agreed. We were worried about adding anything that could make differences in the DECK run, even just diagnostic files

[rljacob]

I'm looking at the v3 output and see a file with string "mpaso.hist.am.highFrequencyOutput". Is that the only one affected by this change?

[jonbob]

@rljacob -- yes, that should be it