Add new PBL diagnostic variables dkt and dku #607
Conversation
…elated to hwrf_physics.
Cleanup trailing white space for some hwrf physics related source code
…s_20200619 Update support/HAFS from NCAR dtc/hwrf-physics 2020/06/19
…t it call the progcld6 instead of progcld5.
…ync_master_20200703
…ync_master_20200703
…s-community/ccpp-physics into feature/sync_master_20200703
…ync_master_20200703
physics/gfdl_sfc_layer.meta. (Dom)
*Add dkt as a diagnostic variable for satmedmfvdifq.F. Contributors: Andrew Hazelton, Chunxi Zhang, Bin Liu
bd89cbc to
8c44643
Compare
…iables, so that they will not be conflicted with other similar variables in GFS_typedefs.meta. Contributors: Chunxi Zhang and Bin Liu
physics/moninedmf.meta
Outdated
| @@ -420,14 +420,23 @@ | |||
| intent = inout | |||
| optional = F | |||
| [dkt] | |||
| standard_name = atmosphere_heat_diffusivity | |||
| standard_name = atmosphere_heat_diffusivity_from_gfspbl | |||
There was a problem hiding this comment.
Please remove _from_gfspbl here and also for [dku]. Same in physics/satmedmfvdifq.meta and in GFS_typedefs.meta. There is no reason why these variables should be specific to GFS PBL.
There was a problem hiding this comment.
@climbfuji We actually were using the names without adding "_from_gfspbl" in the dkt/dku stand_names originally, However, the model build failed due to the complaining that there are duplicated standard names of "atmosphere_heat_diffusivity" in ccpp/data/GFS_typedefs.meta.
As you can see, there is already a dkt under the GFS_interstitial_type section with a standard name of "atmosphere_heat_diffusivity". After looking into it a little more, we saw some examples on how to use different names for the same/similar variables in this GFS_typedefs.meta file, for example:
standard_name = instantaneous_atmosphere_heat_diffusivity
standard_name = atmosphere_heat_diffusivity_background
standard_name = atmosphere_heat_diffusivity_background_maximum
standard_name = atmosphere_heat_diffusivity_from_shoc
standard_name = atmosphere_heat_diffusivity_for_mynnpbl
standard_name = atmosphere_heat_diffusivity
With that, we introduced the
standard_name = atmosphere_heat_diffusivity_from_gfspbl
for dkt (did the same for dku). After that the build worked fine. Agree that, this is not an elegant way and sometime confusing to use different standard_names for the same variable. It would be nice to standardize or unify this from the model and ccpp interface side. Please let us know if you have any comments/suggestions. Thanks!
There was a problem hiding this comment.
@climbfuji We actually were using the names without adding "_from_gfspbl" in the dkt/dku stand_names originally, However, the model build failed due to the complaining that there are duplicated standard names of "atmosphere_heat_diffusivity" in ccpp/data/GFS_typedefs.meta.
As you can see, there is already a dkt under the GFS_interstitial_type section with a standard name of "atmosphere_heat_diffusivity". After looking into it a little more, we saw some examples on how to use different names for the same/similar variables in this GFS_typedefs.meta file, for example:
standard_name = instantaneous_atmosphere_heat_diffusivity
standard_name = atmosphere_heat_diffusivity_background
standard_name = atmosphere_heat_diffusivity_background_maximum
standard_name = atmosphere_heat_diffusivity_from_shoc
standard_name = atmosphere_heat_diffusivity_for_mynnpbl
standard_name = atmosphere_heat_diffusivity
With that, we introduced the
standard_name = atmosphere_heat_diffusivity_from_gfspbl
for dkt (did the same for dku). After that the build worked fine. Agree that, this is not an elegant way and sometime confusing to use different standard_names for the same variable. It would be nice to standardize or unify this from the model and ccpp interface side. Please let us know if you have any comments/suggestions. Thanks!
Oh, I see. Not your fault at all, just terrible precedence. In this case, I suggest to leave the PR as-is, let's clean this up afterwards.
There was a problem hiding this comment.
Yeah, some confusion about what was going on with these similarly-named variables is why I made a new one "dkudiagnostic" for momentum diffusivity, but that's obviously not the best solution memory-wise. Definitely would be good if we can help clean this up in the future hopefully.
There was a problem hiding this comment.
@climbfuji, With some further discussions and code digging with @ChunxiZhang-NOAA, it looks like our current solution for diagnostic dkt variable will probably break the the existing interstitial dkt usage in physics/moninedmf.f[meta] and in ccpp/data/GFS_typedefs.F90[meta]. Currently, we were thinking of the following two potential solutions:
- A. Using dkt_diag and dku_diag (atmosphere_heat_diffusivity_diag and atmosphere_momentum_diffusivity_diag) for the the diagnostic output so that they are not conflict with other usages (interstitial, coupling, etc.);
- B. Currently only outputting dku (atmosphere_momentum_diffusivity) as a new diagnostic variable (which should not be conflicted with other dku usage at this moment), while dropping off the proposed dkt diagnostic output.
Appreciate it if you could provide any insight/recommendation on how to move forward with this change. Thanks!
There was a problem hiding this comment.
@climbfuji Yes, this is also a good solution. I searched out the usage of "Interstitial%dkt" inside ufs-weather-model. These are the locations the Interstitial%dkt was used:
grep -ir "Interstitial%dkt" *
FV3/ccpp/data/GFS_typedefs.F90: allocate (Interstitial%dkt (IM,Model%levs-1))
FV3/ccpp/data/GFS_typedefs.F90: Interstitial%dkt = clear_val
FV3/ccpp/data/GFS_typedefs.F90: write (0,*) 'sum(Interstitial%dkt ) = ', sum(Interstitial%dkt )
FV3/ccpp/physics/physics/GFS_debug.F90: call print_var(mpirank, omprank, blkno, Grid%xlat_d, Grid%xlon_d, 'Interstitial%dkt ', Interstitial%dkt )
So, if we move the dkt into the Diag%dkt section. Then the above will be the places need to be replaced by Diag%dkt, right? Of course, in this case the dkt and dku can then use the names of atmosphere_heat_diffusivity and atmosphere_momentum_diffusivity. Do you think this will work? Thanks!
There was a problem hiding this comment.
I think so, yes. The whole point moving it from Interstitial% to Diag% is to make it persistent so that it can be written out. In GFS_debug.F90, it will need to go from module GFS_interstitialtoscreen to GFS_diagtoscreen, but that should be pretty much self-explanatory in the file.
There was a problem hiding this comment.
Thanks @climbfuji! I have just made and pushed the changes into this branch and in the FV3atm side as well. Please help to check/review the changes when you get a chance. Thanks!
There was a problem hiding this comment.
Ok, let's get started with testing this today, your PR will go next after the current LAM post commit.
There was a problem hiding this comment.
Ok. Just synced this branch with the latest master to get it ready for model level RT.
…ard_names for dkt/dku back to atmosphere_heat/momentum_diffusivity.
62b53a2 to
28c815a
Compare
|
Testing with ufs-weather-model completed and passed. |
|
In a follow-up PR, we will change the dimensions (including metadata) of these arrays to the full |
* Change ccpp-physics branch to fix_tq2m_diagnoahmp
Add new PBL diagnostic variables dkt and dku (atmosphere heat and momentum diffusivity)
Contributors: @ChunxiZhang-NOAA, @AndrewHazelton, @BinLiu-NOAA
This PR addresses ccpp-physics issue #606 .
Related PRs:
ufs-community/ufs-weather-model/pull/505
NOAA-EMC/fv3atm/pull/269