Visc_rem_[uv] multiplied momentum budget diagnostics

[NoraLoose]

This PR implements modified diagnostics for the momentum budget.

Modified momentum budget

The modified momentum budget diagnostics

• filter out the balance between PFu and du_dt_visc in vanished layers,
• leave the momentum budget as is in non-vanished layers.

In practice, this is done by modifying the original zonal momentum budget

du_dt = CAu + PFu + u_BT_accel + diffu + du_dt_visc    (1)

to

du_dt = [visc_rem_u * CAu] + [visc_rem_u * PFu] + [visc_rem_u * u_BT_accel] + [visc_rem_u * diffu] + [visc_rem_u * du_dt_visc + (1-visc_rem_u) * du_dt]   (2)

as per @Hallberg-NOAA's suggestion in https://github.com/ocean-eddy-cpt/WP1T4-2D-EKE-NW2/issues/8.

There are five terms in square brackets on the right hand side of (2). The first 4 are labelled as CAu_visc_rem, PFu_visc_rem, u_BT_accel_visc_rem, diffu_visc_rem. These are the 4 new implemented diagnostics.

The 5th term, [visc_rem_u * du_dt_visc + (1-visc_rem_u) * du_dt], has a slightly more complex form. To make our lives easier, I decided to drop the implementation for this 5th term, because it can be diagnosed exactly as the residual du_dt - CAu_visc_rem - PFu_visc_rem - u_BT_accel_visc_rem - diffu_visc_rem from existing diagnostics.

Everything that I am describing above is similarly done for the meridional momentum budget.

Why are the new diagnostics useful?

The new diagnostics are helpful for my CPT work because I apply a spatial filter to each of the terms in the momentum and KE budget. This filter will spread high PFu / du_dt_visc values from vanished layers into the interior ocean, which contaminates my EKE budget. The problem is solved when the PFu / du_dt_visc balance is masked out in vanished layers from the get-go.

[NoraLoose]

PS: The unit tests suggest that I made syntax errors in MOM_diagnostics.F90. I am confused - I am able to compile with intel on cheyenne just fine. :confused:

[gustavo-marques]

I am happy to meet early next week to discuss the issues you are having. Let's coordinate that via Slack.

[NoraLoose]

Thanks Gustavo!

Let's coordinate that via Slack.

Sounds good.

[NoraLoose]

Thanks everyone for your help! With @gustavo-marques's help, I figured out what the issue was. I have now implemented both the momentum and KE budget diagnostics. Here are two summary plots that show the updated vs. original diagnostics in the lowermost layer of NW2 (5 day average):

Momentum budget

Key point: the *_visc_rem multiplied momentum budget diagnostics filter out the balancing terms of the pressure gradient force (PFu) and vertical viscosity (du_dt_visc) in vanished layers, as desired.

KE budget

Key point: the updated KE budget diagnostics (designed to be consistent with the visc_rem_[uv] multiplied momentum budget diagnostics) are identical to the original KE diagnostics. In hindsight, this makes sense: one dots the momentum budget diagnostics with uh to compute the KE budget diagnostics. The differences between the old and new momentum budget diags are found only in vanished layers, so the KE budget does not feel it.

Since the new and original KE budget diagnostics are identical (up to numerical noise), I am therefore now considering to take the KE budget diagnostics out of this PR.

[NoraLoose]

To keep it simple -- and to avoid redundant diagnostics --, I am restricting this PR to visc_rem_[uv] multiplied momentum budget diagnostics only. The associated KE budget diagnostics that were originally part of this PR are now removed.

The code changes are ready for review now. All tests are passing except for one regression test that complains about the fact that the diagnostics have been changed.

[gustavo-marques]

@NoraLoose, thanks for this PR. I was able to compile the code but it fails in the NW2 test because of the issues pointed above. I think it will run just fine that after you address them.

[NoraLoose]

Thanks @gustavo-marques for walking me through the allocation issue!

Dropping of d[uv]_dt_visc_rem

To make our lives easier, I have dropped the more complex diagnostic du_dt_visc_rem. This diagnostic is more complex than the other new diagnostics because it requires not only du_dt_visc and visc_rem_u, but also du_dt. Having to know du_dt resulted in complications with allocation across different modules / routines.

The diagnostic du_dt_visc_rem can be dropped because it can actually (by construction) be exactly diagnosed from diagnostics that are already there:

du_dt_visc_rem = du_dt - CAu_visc_rem - PFu_visc_rem - u_BT_accel_visc_rem - diffu_visc_rem

I have updated the PR description above accordingly.

Testing

I have tested the remaining 8 momentum budget diagnostics (4 zonal, 4 meridional) as follows. Recall that

PFu_visc_rem = PFu * visc_rem_u,

i.e. PFu_visc_rem is simply the visc_rem_u-multiplied version of PFu. Same holds for CAu_visc_rem, u_BT_accel_visc_rem, and diffu_visc_rem.

• I wrote out PFu_visc_rem, PFu, and visc_rem_u on a timestep basis, and
• compared PFu_visc_rem (online diagnostic) vs. PFu * visc_rem_u (offline diagnostic). These two should give the exact same result.

Here, I am showing this comparison for an example time step and the lowermost layer.

The residual in the last column is orders of magnitude smaller than the signal, which gives me confidence that the new diagnostics are implemented correctly. I found the same for other layers as well as the meridional budget.

[gustavo-marques]

Thanks for the changes @NoraLoose! It looks good to me now. I've verified that it does not change answers in one of the NW2 tests.

[NoraLoose]

Awesome! Thanks for your help and for handling this PR so quickly, @gustavo-marques!

[Hallberg-NOAA]

Very nicely done @NoraLoose, and thanks for your help and being so responsive, @gustavo-marques.

I think that others will find these new diagnostics to be very valuable as well, and would like to see these changes merged into the shared main branch, hopefully sooner rather than later. Do we have a strategy for propagating these changes to the shared main branch, either by a PR to dev/ncar or dev/gfdl?

[gustavo-marques]

Hi @Hallberg-NOAA, yes I will send a PR from dev/cpt to dev/gfdl to propagate these changes to the main branch.