standard name for general heating rate?

[gold2718]

Is it okay to add a standard name for any generic heating rate produced by a scheme? Something simple like heating_rate?

[grantfirl]

What is wrong with tendency_of_air_temperature...?

[gold2718]

It is a slightly different quantity:

tendency_of_air_temperature = heating_rate_due_to_x / specific_heat_of_dry_air_at_constant_pressure

[grantfirl]

Ok, sure. I always took them to be synonymous, apparently in error. In case I'm not the only one who has had this misconception, would it be too much to ask to maybe define it in the rules or in the long name (like you did in your comment)? So, units of heating_rate would be J kg-1 s-1?

[gold2718]

So, units of heating_rate would be J kg-1 s-1?

Yes

I wonder about having names such as heating_rate_due_to_<x> or tendency_of_air_temperature_due_to_<x> vs. heating_rate or tendency_of_air_temperature.

If I want to have a generic interstitial scheme such as update_air_temperature, I would need input arguments tendency_of_air_temperature and air_temperature. With all the scheme-specific tendency standard names, this seems to not be feasible. How are you currently handling state updates?

[dudhia]

If the air temperature tendency is several tendencies, the update interstitial could take each in turn or another interstitial could give a total tendency followed by a single update call. I don't think of this as limiting in any way.

…

On Thu, Sep 9, 2021 at 12:31 PM goldy ***@***.***> wrote: So, units of heating_rate would be J kg-1 s-1? Yes I wonder about having names such as heating_rate_due_to_<x> or tendency_of_air_temperature_due_to_<x> vs. heating_rate or tendency_of_air_temperature. If I want to have a generic interstitial scheme such as update_air_temperature, I would need input arguments tendency_of_air_temperature and air_temperature. With all the scheme-specific tendency standard names, this seems to not be feasible. How are you currently handling state updates? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77EL75K4P3L7P4FOGC3UBD4ONANCNFSM5DVTWBDA> . 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>.

[gold2718]

the update interstitial could take each in turn

How would you write the metadata for that?

another interstitial could give a total tendency followed by a single update call

How would you write the metadata for that?

[grantfirl]

So, units of heating_rate would be J kg-1 s-1?

Yes

I wonder about having names such as heating_rate_due_to_<x> or tendency_of_air_temperature_due_to_<x> vs. heating_rate or tendency_of_air_temperature.

If I want to have a generic interstitial scheme such as update_air_temperature, I would need input arguments tendency_of_air_temperature and air_temperature. With all the scheme-specific tendency standard names, this seems to not be feasible. How are you currently handling state updates?

I don't see a problem with having a generic heating rate or tendency if necessary. For the UFS, the first half of the suites use process-split and each scheme accumulates its temperature tendency in the tendency_of_air_temperature_due_to_model_physics variable. That tendency is applied in a state-updater interstitial. All schemes afterward update the state directly using the time-split method. All of the tendency_of_air_temperature_due_to_<x> besides the "model_physics" one are purely diagnostic in the UFS.

[grantfirl]

BTW, "tendency_of_air_temperature_due_to_model_physics" was already an existing CF variable, so we thought fit to use it for the accumulator variable for the process-split physics. The "...due_to_model_physics" part might be superfluous, but we wanted to use as many existing CF variables as possible and not add more.

[dudhia]

I guess the state updater interstitial is not generic in its inputs and is tied to a particular physics like radiation for example because its metadata would require that input?

…

On Thu, Sep 9, 2021 at 1:16 PM grantfirl ***@***.***> wrote: So, units of heating_rate would be J kg-1 s-1? Yes I wonder about having names such as heating_rate_due_to_<x> or tendency_of_air_temperature_due_to_<x> vs. heating_rate or tendency_of_air_temperature. If I want to have a generic interstitial scheme such as update_air_temperature, I would need input arguments tendency_of_air_temperature and air_temperature. With all the scheme-specific tendency standard names, this seems to not be feasible. How are you currently handling state updates? I don't see a problem with having a generic heating rate or tendency if necessary. For the UFS, the first half of the suites use process-split and each scheme accumulates its temperature tendency in the tendency_of_air_temperature_due_to_model_physics variable. That tendency is applied in a state-updater interstitial. All schemes afterward update the state directly using the time-split method. All of the tendency_of_air_temperature_due_to besides the "model_physics" one are purely diagnostic in the UFS. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77HSKH7W3TYXQH63MFDUBEBZRANCNFSM5DVTWBDA> . 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>.

[grantfirl]

The UFS state updater interstitial was actually one of the few interstitials that was generic (until someone put an if-statement in there regarding a specific MP scheme). It simply took in the accumulated process-split tendencies from whatever physics updated those variables prior to the state updater being called and updates the state variables for use in the immediately following time-split scheme in the SDF. It should work for any SDF that works like: [all process-split schemes, all time-split schemes].

[dudhia]

Is that in the ccpp-physics directory? Could you point me to it?

…

On Thu, Sep 9, 2021 at 1:28 PM grantfirl ***@***.***> wrote: The UFS state updater interstitial was actually one of the few interstitials that was generic (until someone put an if-statement in there regarding a specific MP scheme). It simply took in the accumulated process-split tendencies *from whatever physics updated those variables prior to the state updater being called* and updates the state variables for use in the immediately following time-split scheme in the SDF. It should work for any SDF that works like: [all process-split schemes, all time-split schemes]. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77CYQRF3MEA3PX6TRO3UBEDFBANCNFSM5DVTWBDA> . 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>.

[grantfirl]

Look for the module GFS_suite_stateout_update in https://github.com/NCAR/ccpp-physics/blob/main/physics/GFS_suite_interstitial.F90

[ligiabernardet]

@gold2718 This issue seemed to have branched off on various discussions. Returning to the topic discussed in the title, I believe there is agreement that a standard name for heating_rate can be added if a scheme and/or host model needs it. This statement is valid for any new standard name, that is, if new names are needed to represent new variables, they should be added to the dictionary. Unless you (or others) are planning to add the heating rate soon, I think we can close this issue. Please let us know how you'd like to proceed.