Multiple cumulative bucket periods for total and convective precipitation

[matusmartini]

Description of Changes:

Currently the accumulation period for clearing diagnostics can be specified by a single value in fhzero for all cumulative diagnostics (physics tendencies, radiative fluxes, and precipitation amounts). This PR implements multiple diagnostic reset periods for total totprcpb and convective cnvprcpb preciptitation variables by combining different accumulation amounts into an additional dimension with number_of_diagnostic_buckets. More bucket diagnostics (e.g., snow, ice, freezing ice, graupel) could be added to this list.

Note this PR does not affect the accumulation of physics tendencies or radiative fluxes.

This PR also removes unused bucket-related variables. No need to pass fhzero and cnvprcpb as arguments in GWD and SCNV schemes, respectively.

Tests Conducted:

None, but used in NEPTUNE.

Dependencies:

At minimum, this update will require following changes in https://github.com/NOAA-EMC/ufsatm

In ccpp/data/GFS_typedefs.meta, adding:

[number_of_diagnostic_buckets]
  standard_name = number_of_diagnostic_buckets
  long_name = number of diagnostic buckets
  units = count
  dimensions = ()
  type = integer

And adding the second dimension:

dimensions = (horizontal_dimension,number_of_diagnostic_buckets)

for totprcpb and cnvprcpb.

In NEPTUNE, we also added a new namelist parameter fhzero_precip to specify accumulations (e.g., 3, 6, 12, 24 hours):

[fhzero_precip]
  standard_name = period_of_precipitation_bucket_reset
  long_name = hours between clearing of precipitation buckets
  units = h
  dimensions = (number_of_diagnostic_buckets)
  type = real
  kind = kind_phys

and GFS_diag_type-bound procedure diag_bucket_zero.

Documentation:

None.

Issue:

None, but a related issue is ESCOMP/ESMStandardNames#130 if standard_name needs bucket length information as part of the diagnostics name.

[climbfuji]

Thanks @matusmartini !

[grantfirl]

@matusmartini @climbfuji I'm wondering if this would be better targeted to ufs/dev. Diagnostics and their buckets are generally more of a host-controlled thing. While it certainly has tentacles into the physics code as evidenced here, perhaps it would be better served to have an associated UFSATM PR to go with this to discuss with other developers that are interested in the diagnostics piece.

[climbfuji]

I agree that a discussion should include CCPP users and developers from all organizations, perhaps best at the Wedneday CCPP physics meetings. However, the development workflow that was laid out in the past clearly has each organization contribute its changes back to the authoritative repository. The changes will then be propagated to the other models.

[grantfirl]

I agree that a discussion should include CCPP users and developers from all organizations, perhaps best at the Wedneday CCPP physics meetings. However, the development workflow that was laid out in the past clearly has each organization contribute its changes back to the authoritative repository. The changes will then be propagated to the other models.

Understood RE: dev workflow. It just seems like there is a larger question here with respect to handling diagnostics that is larger than just physics, hence my confusion on how best to proceed with this particular PR.

Adding one more diagnostic bucket is simple enough, and, if UFS devs don't care to have different fhzero values, then that is easy enough to set the new value from the existing one in GFS_typedefs. However, there may be a question as to whether a particular host requiring different diagnostics (that have a need to be calculated within the physics code) have separate interstitials.

If this really is a one-time change (or very infrequent), then keeping the same interstitials for UFS/NEPTUNE is probably still the best course, but if NRL envisions more differences between UFS and NEPTUNE diagnostics, at what point would it make sense to carry different interstitials?

[climbfuji]

I agree that a discussion should include CCPP users and developers from all organizations, perhaps best at the Wedneday CCPP physics meetings. However, the development workflow that was laid out in the past clearly has each organization contribute its changes back to the authoritative repository. The changes will then be propagated to the other models.

Understood RE: dev workflow. It just seems like there is a larger question here with respect to handling diagnostics that is larger than just physics, hence my confusion on how best to proceed with this particular PR.

Adding one more diagnostic bucket is simple enough, and, if UFS devs don't care to have different fhzero values, then that is easy enough to set the new value from the existing one in GFS_typedefs. However, there may be a question as to whether a particular host requiring different diagnostics (that have a need to be calculated within the physics code) have separate interstitials.

If this really is a one-time change (or very infrequent), then keeping the same interstitials for UFS/NEPTUNE is probably still the best course, but if NRL envisions more differences between UFS and NEPTUNE diagnostics, at what point would it make sense to carry different interstitials?

There is also Steve's comment in the ESM Standard Names repo about climate models that may want to CHANGE frequency of accumulations during long runs ... and a long time ago we discussed that CCPP should provide a diagnostics module (which it doesn't yet, and may not for some time). IMO it would be nice to discuss this at one of the next CCPP Physics meetings. If this might be useful for the UFS, then we can proceed with adding it to the same set interstitial scheme. Otherwise, we reconsider what the best course of action is?

[dustinswales]

@matusmartini Thanks for these changes.

I view the bucket interval, and in general accumulating diagnostics, as a host/interstitial issue. So this solution works for me since you are accumulating outside of the primary scheme and emptying the buckets on the host side.

My only suggestion would be to change number_of_diagnostic_buckets to something like number_of_time_intervals.
In the future, I could see us using number_of_time_intervals to share variables which are updated between physics groups (e.g all of the radiation fields needed by the physics!). Currently we have two copies of every field, since the radiation and physics are on different time steps. Sorry for the tangent :)

[climbfuji]

@matusmartini Thanks for these changes.

I view the bucket interval, and in general accumulating diagnostics, as a host/interstitial issue. So this solution works for me since you are accumulating outside of the primary scheme and emptying the buckets on the host side.

My only suggestion would be to change number_of_diagnostic_buckets to something like number_of_time_intervals. In the future, I could see us using number_of_time_intervals to share variables which are updated between physics groups (e.g all of the radiation fields needed by the physics!). Currently we have two copies of every field, since the radiation and physics are on different time steps. Sorry for the tangent :)

The buckets are for diagnostic purposes only. Are you suggesting to combine data for diagnostics with interstitial data (that isn't really interstitial, because it crosses groups). The latter would likely be allocated and managed by capgen instead of the host model?

[grantfirl]

After thinking about this some more, I'll approve these changes as-is because the actual code changes are completely transparent to the host except for the need to define number_of_diagnostic_buckets. If UFS/SCM doesn't want/need to worry about additional buckets, they don't have to, but they will now have that option. So, this can go in as-is, IMO.

In this context though, these changes are quite limited (only 2 of the many diagnostic variables). It is clear to me that there is an obvious need for a more thorough diagnostic solution. Rather than every host having to do their own bucket management, I really like the idea of the CCPP framework providing a solution, although I don't think that there are funds/time to add this ATM.

If one were to extend the idea presented in this PR, it would look something like the following:

• Modify EVERY cumulative diagnostic variable to use the new number_of_diagnostic_buckets dimension.
• Physics schemes basically just add to the cumulative variables for all buckets.
• It is up to the host (somehow) to manage the various buckets. UFS does this as part of CCPP_driver, calling bucket clearing routines defined in GFS_typedefs for the Diag DDT. This works but could be more general, since it's kinda hard-coded as to which variables get cleared.
• In the future, the CCPP could do most(all?) of the bucket management via autogeneration and the host could simply control it by defining what the buckets are.

[dustinswales]

@matusmartini Thanks for these changes.
I view the bucket interval, and in general accumulating diagnostics, as a host/interstitial issue. So this solution works for me since you are accumulating outside of the primary scheme and emptying the buckets on the host side.
My only suggestion would be to change number_of_diagnostic_buckets to something like number_of_time_intervals. In the future, I could see us using number_of_time_intervals to share variables which are updated between physics groups (e.g all of the radiation fields needed by the physics!). Currently we have two copies of every field, since the radiation and physics are on different time steps. Sorry for the tangent :)

The buckets are for diagnostic purposes only. Are you suggesting to combine data for diagnostics with interstitial data (that isn't really interstitial, because it crosses groups). The latter would likely be allocated and managed by capgen instead of the host model?

@climbfuji
I was more so just thinking out loud about having some kind of "time interval" associated with variables.
For diagnostics variables it would work as described in this PR. Another way to leverage the time interval could be for fields that are used across groups, but use different timesteps. Just a thought.

[dustinswales]

If one were to extend the idea presented in this PR, it would look something like the following:

• Modify EVERY cumulative diagnostic variable to use the new number_of_diagnostic_buckets dimension.
• Physics schemes basically just add to the cumulative variables for all buckets.
• It is up to the host (somehow) to manage the various buckets. UFS does this as part of CCPP_driver, calling bucket clearing routines defined in GFS_typedefs for the Diag DDT. This works but could be more general, since it's kinda hard-coded as to which variables get cleared.
• In the future, the CCPP could do most(all?) of the bucket management via autogeneration and the host could simply control it by defining what the buckets are.

@grantfirl I agree, but with a slight twist.
Diagnostic fields are intent(out) from all primary schemes (Probably should be optional as well for portability), and accumulation/bucket-emptying occurs only in interstitial schemes (or host).

[grantfirl]

@matusmartini @climbfuji This is combined into #1178 for testing