Frontogenesis function pressure gradient correction

[whannah1]

This implements a missing correction for the frontogenesis function (FGF) used for the frontal gravity wave drag scheme. The FGF gradient calculations are done on model levels for convenience, but the original papers indicate a simple correction should be used to effectively put these gradients on height or pressure levels. However, going back to the original implementation in CESM with FV dynamics this correction was never implemented, and this mistake was carried through to E3SM with the SE dynamics.

The correction addresses problematic biases of excessive gravity wave drag over areas of steep topography. It is controlled by a new namelist variable "use_fgf_pgrad_correction" that is off by default to preserve the behavior of official v3 release version.

[BFB]

[mt5555]

verified (via inspection) the pressure gradient correction to the ugradv tensor-contraction operator.

One concern: this function is using hydrostatic pressure, computed from hvcoord struct and ps_v. In EAMxx, we are trying to avoid the use of hydrostatic pressure. We also want to avoid any assumptions about pressure coordinates, which means not using the hvcoord%a and b coefficients.

This code may be an example where we really do want to use hydrostatic pressure (since full NH pressure surfaces could intersect the ground to TOM). if that's the case, can you:

1. document that this code is intentionally using hydrostatic pressure
2. compute the hydrostatic pressure at interfaces by summing the "pseudo density" in each layer, starting at the model top. pseudo density is given by dp3d (dycore), pdel (EAM physics), or pseudo_density(EAMxx physics) There should be many examples of this 'scan' operation throughout the code. hydrostatic pressure at mid points is the simple average of interface pressure. this will then remove the use of hvcoord% structures.

As the scan for pint is a touch slow on GPUs, might be worth checking if the hydrostatic pint and pmid were not already computed by the calling program.

[whannah1]

One concern: this function is using hydrostatic pressure, computed from hvcoord struct and ps_v. In EAMxx, we are trying to avoid the use of hydrostatic pressure. We also want to avoid any assumptions about pressure coordinates, which means not using the hvcoord%a and b coefficients.

This code may be an example where we really do want to use hydrostatic pressure (since full NH pressure surfaces could intersect the ground to TOM). if that's the case, can you:

1. document that this code is intentionally using hydrostatic pressure
2. compute the hydrostatic pressure at interfaces by summing the "pseudo density" in each layer, starting at the model top. pseudo density is given by dp3d (dycore), pdel (EAM physics), or pseudo_density(EAMxx physics) There should be many examples of this 'scan' operation throughout the code. hydrostatic pressure at mid points is the simple average of interface pressure. this will then remove the use of hvcoord% structures.

As the scan for pint is a touch slow on GPUs, might be worth checking if the hydrostatic pint and pmid were not already computed by the calling program.

This is a good point... Although my first reaction is that for cases where we are running the non-hydrostatic dycor we probably want to disable the frontal GWD scheme anyway.

As a side note - I'm also working on an idea to make the frontal scheme "scale aware" by comparing the local resolution to the Rossby Radius. My initial dive into this topic yielded a pretty simple metric for approximating when frontogenesis is unresolved - and for grids finer than ne120 this suggested that the frontal GWD should always be disabled. So I'm sort of hoping this thing about the hydrostatic pressure will be a non-issue. But even if it is still an issue I think modifying this scheme to calculate the hydrostatic pressure should be a straightforward thing to address in the future.

[whannah1]

NOTE that we're planning to wait for PR #7791 to be merged first to fix the CI tests for the frontal GW src routine.

[singhbalwinder]

on next

[rljacob]

This broke the build for this case: SMS_R_Ld5.ne4_ne4.FSCM-ARM97.chrysalis_intel.eam-scm

[rljacob]

Also broke the build for these cases: SMS.ne4pg2_oQU480.F2010.chrysalis_intel.eam-preqx_ftype0, SMS.ne4pg2_oQU480.F2010.chrysalis_intel.eam-preqx_ftype1, SMS.ne4pg2_oQU480.F2010.chrysalis_intel.eam-preqx_ftype4

[singhbalwinder]

I have re-run the failed tests. Once all the tests pass, I will merge it again to the next.