Diagnosis of dia-coordinate transports in ALE mode

[ashao]

In ALE mode, vertical advection is effectively replaced by the regrid/remap step, however a vertical transport diagnostic is still useful especially in diagnostic z* or isopycnal coordinates. I've started working on doing this online in the model by integrating the continuity equation from the bottom up and avoiding unnecessary, repeated computations. Note: This branch doesn't even build yet since I haven't corrected any typos, but before going down too much of rabbit hole, I'd like some feedback on the implementation itself, any other 'features' that could be added as part of this contribution, or anything else that I've overlooked.
NOAA-GFDL/MOM6@dev/gfdl...ashao:vert_transport_diag

For example:

• @StephenGriffies, @adcroft, and I noted that my initial offline wmo diagnostic does not include the contribution from the free surface. This implementation doesn't add it yet either, but will be accounted for down the line once I figure out how to pass it into the post_vertical_transport_diag.
• @sdbachman, made the great suggestion to extend this to also calculate a vertical advective transport of tracer. My first thought along those lines is to calculate it based off the upstream, remapped tracer concentration, but would be curious to hear if there's a better/more accurate way to estimate that. My biggest question for this is how it relates to the currently available, tracer content tendency due to the vertical regrid/remap. The convergence of the vertical transports should be the equivalent of this tendency, but because we'd be calculating them differently within the model, they would not be exactly the same. I'm not sure how to highlight this difference so that it doesn't confuse too many people.

[StephenGriffies]

I am very glad you are moving ahead with this diagnostic.

Please note that if you wish this diagnostic to be useful in the non-Boussinesq p* diagnostic grid, then you will need to incorporate the bottom pressure tendency rather than the free surface tendency. I have the maths worked out in Sections 10.8.1 and 10.8.2 of the MOM5 manual if you wish.

[ashao]

@StephenGriffies, the non-Boussinesq mode completely slipped my mind. That's a great point and if I remember correctly (and I'll double check those equations) the top interface of the model in that case also needs the change in pressure (applied by atmosphere/ice). I'll modify the routine calculating wmo so that one can optionally include a surface and/or bottom boundary.

The other detail that I've been wondering how to deal with is evaporation and freshwater fluxes due to ice formation. These outgoing fluxes are not necessarily restricted to the top layer, but can be taken out over some portion (or in extreme cases) of the water column. In this case, the equations for w in the interior layers also need to account for this thickness/mass sink. Is that your understanding as well?

[StephenGriffies]

Yes, good point about mass entering/leaving within the column due to internal source/sinks. So yep, these need to be accounted for as well.

[ashao]

@adcroft / @Hallberg-NOAA , following from Steve's comment above, could you confirm that the effective 'conversion' of the prognostic z* to p* implied by Boussinesq vs. non-Boussinesq mode applies to the diagnostic grid as well. For example, when a (nominal) z* grid is specified in and BOUSSINESQ = True, a diagnostic p* grid cannot be requested.

[adcroft]

I am not sure that z* is z* in non-Boussinesq mode. The code simply stretches the column and does not use the EOS to find the thickness in meters so I think the z-like module would yield p* or something like it.

[ashao]

Staring at this code for a while, I agree (with some confidence) that non-Boussinesq z* is p*.

[adcroft]

Is it the vertical fluxes in A26-27 of https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2019MS001726 you want? I think those are the dia-coordinate transports.

[adcroft]

I continue to get questions about how to calculate w. @ashao what's the status of your script that calculates w* off-line in z* coordinates? If you think it's doing the right thing can you post a link to it here?

[ashao]

The current script is not correct because it does not account for the stretching of the water column:

https://github.com/NOAA-GFDL/MOM6-examples/blob/dev/gfdl/tools/analysis/verticalvelocity.py