Rename CCPP_interstitial (to GFDL_interstitial)

[climbfuji]

Description

I would like to rename CCPP_interstitial into something more meaningful for the fv3atm atmospheric model. The term is confusing, because fv3atm has GFS_interstitial for the GFS (slow/traditional physics), and CCPP_interstitial for the FV3 dycore (fast/tightly coupled physics). Both of them are interstitial data types required by CCPP and they are defined in a module called CCPP_typedefs.F90.

For now, I changed it to GFDL_interstitial but I am not 100% happy with this name and I would welcome suggestions for a better name. This PR shows the small extent of these changes.

Related, I would like to consider renaming the CCPP variable cdata_tile to something more meaningful, for example cdata_dycore? There are two other cdata variables in fv3atm, cdata_block (when blocked data is passed) and cdata_domain (when all blocks are passed as one contiguous data).

Fixes NOAA-EMC/fv3atm#507.

How Has This Been Tested?

Tested with the ufs-weather-model regression tests, see ufs-community/ufs-weather-model#1130

Checklist:

Please check all whether they apply or not

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• [n/a] I have commented my code, particularly in hard-to-understand areas
• [n/a] I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[climbfuji]

@junwang-noaa @bensonr Would you be able to give me some feedback on the proposed name change for the CCPP interstitial data container? Thanks very much!

[junwang-noaa]

I am thinking maybe slowPhys_interstitial (or GFSSlowPhys_interstitial) and fastPhys_interstitial? It's not clear to me what GFS_interestitial and GFDL_insterstitial mean.

Also I agree cdata_dycore is the data used in dycore, it's easier to understand than cdata_tile.

[lharris4]

I don't understand this syntax here. What is going on?

[climbfuji]

This association was done so that we didn't have to change the entire code and replace cappa with CCPP_interstitial%cappa everywhere. This was especially important when IPD and CCPP coexisted in the UFS, as we had to switch between the two builds.

Previously, in the IPD, and still the case in the dev/gfdl branch (I think), cappa is a local (module) variable in fv_dynamics.F90. In the CCPP implementation, it is part of the DDT currently called CCPP_interstitial. When CCPP was implemented first as a dynamic build option, this was the only way to pass cappa to the saturation adjustment in CCPP. Later, the dynamic build was phased out. It would be possible to rearrange things a bit, although I don't think we can use cappa as a local variable in fv_dynamics.F90 as it is for the dev/gfdl branch. It could be a module variable in separate Fortran module.

@bensor and I talked a while ago about a possible refactoring of the physics implementations with the goal to have a generic interface to call physics in the FV3 dycore, and then the two backends GFDL physics and CCPP physics. Unfortunately, we haven't made any progress on that. But this would be a good opportunity to revisit the CCPP implementation.

[lharris4]

Hi, Dom. So ccpp_associate is some sort of dynamic data type? Thanks, Lucas

…

On Mon, Apr 4, 2022 at 11:34 AM Dom Heinzeller ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In model/fv_dynamics.F90 <#181 (comment)> : > @@ -299,11 +299,11 @@ subroutine fv_dynamics(npx, npy, npz, nq_tot, ng, bdt, consv_te, fill, real :: time_total integer :: seconds, days - ccpp_associate: associate( cappa => CCPP_interstitial%cappa, & This association was done so that we didn't have to change the entire code and replace cappa with CCPP_interstitial%cappa everywhere. This was especially important when IPD and CCPP coexisted in the UFS, as we had to switch between the two builds. Previously, in the IPD, and still the case in the dev/gfdl branch (I think), cappa is a local (module) variable in fv_dynamics.F90. In the CCPP implementation, it is part of the DDT currently called CCPP_interstitial. When CCPP was implemented first as a dynamic build option, this was the only way to pass cappa to the saturation adjustment in CCPP. Later, the dynamic build was phased out. It would be possible to rearrange things a bit, although I don't think we can use cappa as a local variable in fv_dynamics.F90 as it is for the dev/gfdl branch. It could be a module variable in separate Fortran module. @bensor <https://github.com/bensor> and I talked a while ago about a possible refactoring of the physics implementations with the goal to have a generic interface to call physics in the FV3 dycore, and then the two backends GFDL physics and CCPP physics. Unfortunately, we haven't made any progress on that. But this would be a good opportunity to revisit the CCPP implementation. — Reply to this email directly, view it on GitHub <#181 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMUQRVFKIB47BJNNVWCQSQDVDMDYLANCNFSM5RFZPVCA> . You are receiving this because you commented.Message ID: ***@***.***>

[climbfuji]

Ahhhh, no, that’s just a label for the “associate" statement like you can do for “if”, “do” etc.

…

On Apr 4, 2022, at 11:49 AM, lharris4 ***@***.***> wrote: Hi, Dom. So ccpp_associate is some sort of dynamic data type? Thanks, Lucas On Mon, Apr 4, 2022 at 11:34 AM Dom Heinzeller ***@***.***> wrote: > ***@***.**** commented on this pull request. > ------------------------------ > > In model/fv_dynamics.F90 > <#181 (comment)> > : > > > @@ -299,11 +299,11 @@ subroutine fv_dynamics(npx, npy, npz, nq_tot, ng, bdt, consv_te, fill, > real :: time_total > integer :: seconds, days > > - ccpp_associate: associate( cappa => CCPP_interstitial%cappa, & > > This association was done so that we didn't have to change the entire code > and replace cappa with CCPP_interstitial%cappa everywhere. This was > especially important when IPD and CCPP coexisted in the UFS, as we had to > switch between the two builds. > > Previously, in the IPD, and still the case in the dev/gfdl branch (I > think), cappa is a local (module) variable in fv_dynamics.F90. In the > CCPP implementation, it is part of the DDT currently called > CCPP_interstitial. When CCPP was implemented first as a dynamic build > option, this was the only way to pass cappa to the saturation adjustment > in CCPP. Later, the dynamic build was phased out. It would be possible to > rearrange things a bit, although I don't think we can use cappa as a > local variable in fv_dynamics.F90 as it is for the dev/gfdl branch. It > could be a module variable in separate Fortran module. > > @bensor <https://github.com/bensor> and I talked a while ago about a > possible refactoring of the physics implementations with the goal to have a > generic interface to call physics in the FV3 dycore, and then the two > backends GFDL physics and CCPP physics. Unfortunately, we haven't made any > progress on that. But this would be a good opportunity to revisit the CCPP > implementation. > > — > Reply to this email directly, view it on GitHub > <#181 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AMUQRVFKIB47BJNNVWCQSQDVDMDYLANCNFSM5RFZPVCA> > . > You are receiving this because you commented.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#181 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5C2RLGR2ED4JZK55RFIZ3VDMTT7ANCNFSM5RFZPVCA>. You are receiving this because you authored the thread.

[lharris4]

OK. Thanks. On Mon, Apr 4, 2022 at 1:51 PM Dom Heinzeller ***@***.***> wrote:

…

Ahhhh, no, that’s just a label for the “associate" statement like you can do for “if”, “do” etc. > On Apr 4, 2022, at 11:49 AM, lharris4 ***@***.***> wrote: > > > Hi, Dom. So ccpp_associate is some sort of dynamic data type? > > Thanks, > Lucas > > On Mon, Apr 4, 2022 at 11:34 AM Dom Heinzeller ***@***.***> > wrote: > > > ***@***.**** commented on this pull request. > > ------------------------------ > > > > In model/fv_dynamics.F90 > > < #181 (comment) > > > : > > > > > @@ -299,11 +299,11 @@ subroutine fv_dynamics(npx, npy, npz, nq_tot, ng, bdt, consv_te, fill, > > real :: time_total > > integer :: seconds, days > > > > - ccpp_associate: associate( cappa => CCPP_interstitial%cappa, & > > > > This association was done so that we didn't have to change the entire code > > and replace cappa with CCPP_interstitial%cappa everywhere. This was > > especially important when IPD and CCPP coexisted in the UFS, as we had to > > switch between the two builds. > > > > Previously, in the IPD, and still the case in the dev/gfdl branch (I > > think), cappa is a local (module) variable in fv_dynamics.F90. In the > > CCPP implementation, it is part of the DDT currently called > > CCPP_interstitial. When CCPP was implemented first as a dynamic build > > option, this was the only way to pass cappa to the saturation adjustment > > in CCPP. Later, the dynamic build was phased out. It would be possible to > > rearrange things a bit, although I don't think we can use cappa as a > > local variable in fv_dynamics.F90 as it is for the dev/gfdl branch. It > > could be a module variable in separate Fortran module. > > > > @bensor <https://github.com/bensor> and I talked a while ago about a > > possible refactoring of the physics implementations with the goal to have a > > generic interface to call physics in the FV3 dycore, and then the two > > backends GFDL physics and CCPP physics. Unfortunately, we haven't made any > > progress on that. But this would be a good opportunity to revisit the CCPP > > implementation. > > > > — > > Reply to this email directly, view it on GitHub > > < #181 (comment) >, > > or unsubscribe > > < https://github.com/notifications/unsubscribe-auth/AMUQRVFKIB47BJNNVWCQSQDVDMDYLANCNFSM5RFZPVCA > > > . > > You are receiving this because you commented.Message ID: > > ***@***.***> > > > — > Reply to this email directly, view it on GitHub < #181 (comment)>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AB5C2RLGR2ED4JZK55RFIZ3VDMTT7ANCNFSM5RFZPVCA >. > You are receiving this because you authored the thread. > — Reply to this email directly, view it on GitHub <#181 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMUQRVBGNC25MDFSTMKICILVDMTZDANCNFSM5RFZPVCA> . You are receiving this because you commented.Message ID: ***@***.***>

[junwang-noaa]

@laurenchilutti We are now working on Dom's PR, may I ask if this PR is ready for commit?

[laurenchilutti]

@junwang-noaa We are waiting on 2 more reviews. Once its approved I can merge it in.

@bensonr @lharris4 Can you please leave a review on this? Thanks.

[lharris4]

Looks fine to me.

[laurenchilutti]

@junwang-noaa This PR is now ready for commit.

[climbfuji]

Thanks for the reviews. Please merge this PR, regression testing is complete.

[climbfuji]

Thanks!