Added diagnostics separating resolved and parameterized tracer advection (requesting feedback)

[pittwolfe]

I've added diagnostics that report tracer advection due to resolved (Tr_ad[x/y]_resolved) and parameterized (Tr_ad[x/y]_param) transport separately. The modifications "work" in the sense that existing answers are unchanged in the (limited) set of tests I've done and the output doesn't look obviously wrong. I'm hoping to get some feedback on my approach before I get into more aggressive testing in case I need to refactor everything.

The modifications are in the GM_tracer_diags branch of my MOM6 fork.

My approach is:

• Add uhtr_resolved and vhtr_resolved to MOM_control_struct to accumulate the resolved transport separately from the parameterized transport
• Call advect_tracer passing resolved transport and the difference between resolved and total transport
• To avoid updating the tracer fields and update the right diagnostics during these calls, added a new optional argument to advect_tracer to specify which kind of transport it's called with. Tracer fields are only updated if called with resolved transport (which is the default if optional argument is unset). This also required modifications to advect_x and advect_y.
• When called with resolved or parameterized transport, it only computes advection of tracers with active diagnostics

Some possibly safer approaches that avoid modifying the core advection routines:

1. Add new routines to calculate advection for the resolved and parameterized transport. Downside: would require updating all the advection routines any time one of them is changed.
2. Call unmodified advect_tracer with fake versions of the tracer registry and diagnostics control structures. The relevant tracers would be copied into the fake tracer registry, avoiding updates to the prognostic tracer fields. The fake diagnostics control structure would make sure that the correct diagnostics are updated. Downside: seemed harder to code because I don't fully understand the inner workings of the tracer registry.

I'd be willing to pursue option 2, but if the current approach is considered good enough I won't bother.

Thanks in advance for any feedback.

[gustavo-marques]

@pittwolfe, thank you very much for adding this capability!

I went through your code, and I do not have major suggestions. A minor suggestion is to change flux_type_ to something else that does not end with _ (suggestion: flux_type_ctrl). Are the new diagnostics available when no parameterization is used?

Once this is ready for more aggressive testing, I will happily test it in CESM.

[pittwolfe]

@gustavo-marques: Changed flux_type_ to flux_type_ctrl.

The diagnostics are available when no parameterization is used, although no calculations are done unless the diagnostics are requested in diag_table. If no parameterizations are active, the parameterized flux ought to be zero (need to verify), which is a reasonable behavior.

[pittwolfe]

@gustavo-marques I've done a bit more testing and everything seems to be working. You're welcome to test it in CESM.

The version of MOM6 used by CESM (we've been using CESM2.3beta16) is sufficiently different that I had to manually transfer the code modifications. The version in the repository GM_tracer_diags_20210709 is in sync with MOM6 tag NCAR_20210709, which is the version used in CESM2.3beta16.

The version in GM_tracer_diags is just a few commits behind NOAA-GFDL/MOM6.