Using dynamics tendencies in CCPP

[grantfirl]

Recently, @lisa-bengtsson and @ligiabernardet were discussing the need for a couple of physics schemes within the CCPP to use tendencies of the state variables due to the dynamics. The GF scheme has already been doing this by calculating these terms from within the physics, particularly saving the state at the end of physics in cu_gf_driver_post and calculating dynamics tendencies by subtracting the state saved at the end of the previous physics timestep from the state at the beginning of the current timestep (in cu_gf_driver_pre).

Now that there is a second scheme (that happens to be deep convection) in need of these tendencies, it is no longer appropriate to calculate them in GF-specific interstitial schemes. The next obvious place to calculate these would be in the generic deep convection interstitial schemes, but this will not work since GFS_DCNV_generic_post needs to be called immediately after deep convection in order to calculate diagnostic tendencies from that scheme. Other schemes that change the state (this is the time-split section of the GFS-based suite), namely microphysics, are called afterward.

So, what are our options? I see a couple:

1. As @lisa-bengtsson suggested, one could create a new interstitial scheme(s) to save the end-of-physics state and another to calculate the dynamics tendency at any point before convection is called -- it doesn't necessarily matter where this calculation happens because the only other pieces of information that you need is the beginning-of-physics state (which is never modified within physics) and the timestep.
2. Make use of the timestep_init and timestep_finalize phases of the GFS_DCNV_generic_pre/post schemes to do these calculations. This is desirable because timestep_finalize will always be called after all run phases, so as long as no other timestep_finalize physics phases are modifying the state (which they shouldn't), then it will capture the end-of-physics state. The beginning-of-physics state should be known in the timestep_initialize phase as well, so there should be everything that one needs. This would not require any additional schemes, modifying any SDFs, or repeating any code in the scheme-specific interstitials.

The big caveat with any approach of this type (calculating dynamics tendencies within physics as a "residual") is that it is possible for more than the dynamics to change the state between the end-of-physics and the beginning of the next physics timestep. In particular, when the GFDL MP scheme is used, it is split into a "slow physics" part and a "fast physics" part called directly from the dycore. The "statein" DDT (what the physics sees as the beginning of timestep state) is calculated in between the calls to fast physics and slow physics. This means that when using the GFDL MP scheme and do_sat_adj = T, the dynamics tendencies will include a potentially large fraction of the microphysics tendencies. The effect of this "error" on schemes that need dynamics tendencies only is unknown. The fast physics portion of the GFDL MP saves the tendencies produced (albeit on the Lagrangian surfaces prior to remapping to the levels used in physics), so one could potentially subtract this off to retrieve the dynamics tendencies in this case, but this isn't a solution to the larger problem that calculating dynamics tendencies as a residual from within physics is risky/problematic.

In my opinion, the best solution would be for the dycore to provide the advective tendencies on physics levels to the physics when needed (perhaps when a flag that is associated with the scheme that needs them is set). Such functionality would not only benefit the physics schemes that need these terms, but they could also be used as forcing for the SCM when saved to output as a diagnostic.

[lisa-bengtsson]

Hi Grant, thank you for starting this thread, I agree with you that dynamics tendencies from the dycore (after the vertical remapping, to include also vertical advection) would be desirable as you mention there are many uses.

However, it may not be straight forward. For example, for my specific need, I'm interested in the moisture flux convergence. A while back I reached out to Lucas Harris to ask if I could simply use the "residual" as you call it for this (e.g if this would include the advection (vertical, horizontal) and divergence term, this was his response:

"Do you need the 3D moisture flux convergence, or just the column-integrated value? The former is a bit tricky since it would require two steps:

1. After exiting fv_tracer2d(), compute the difference in moisture mass in a grid cell ( q(:,:,:,sphum)*delp ) from the value before the first call to dyn_core was made. This is the total change in water vapor mass along a Lagrangian surface; call it dQ, which has units of kg.
2. Perform a vertical remapping of dQ/delp (call it dq) onto the Eulerian surfaces, using the same method for remapping as for q (same kord_tr and using mapn_tracer). You will need to divide by delp, since the remapping assumes the input is specific humidity and not absolute mass.

You will then have a 3D field of dq due to the dynamics. You could get an estimate of the 3D dQ by simply taking the difference before and after calling fv_dynamics() but it would be less accurate since we have a mass-based coordinate which depends on the time-varying surface pressure"

Following this, Xi Chen further explained: "That's exactly right. As Lucas pointed out, the vertical integration of the change of q*delp represents the total horizontal flux for each model column at machine accuracy.

3D budget is much trickier. FV3 implements a vertical Lagrangian coordinate, which is "floating" with the imaginary impenetrable layer interfaces. There are multiple dynamical steps on the Lagrangian layers between the remap process Lucas described. Therefore, after each dynamical step, the vertical location of each model control volume changes. The layers do not follow constant z or p. We can still close the budget of horizontal moist (mass) fluxes and the change of q*delp between dynamics steps at machine accuracy, except the fluxes are defined with "floating" layers."

For my purposes, the "residual" value is satisfactory, so I did not try the approach described above. I also don't know if it is applicable for U and V, but it seems to me that we would need some help from someone with detailed knowledge of the FV3 dycore to go this route. Thanks again.

[grantfirl]

@dudhia This discussion from Lisa may be of interest to you and May Wong, considering our discussion last night.

[dudhia]

Yes, thanks.

…

On Thu, Mar 17, 2022 at 12:24 PM Grant Firl ***@***.***> wrote: @dudhia <https://github.com/dudhia> This discussion from Lisa may be on interest to you and May Wong, considering our discussion last night. — Reply to this email directly, view it on GitHub <#868 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77HCNIBE4XXMSDPIFKTVAN2ERANCNFSM5PSYYVFQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>