RRTMGP in CCPP #400
RRTMGP in CCPP #400
Conversation
…implemented (in progress).
…draw_samples, Cleaned up aerosol increment, Passing random number to RRTMGP cloud sampling.
…sted SW aerosol band ordering in GFS_rrtmgp_pre.F90.
…ieces from suite-level to scheme level.
…oud_microphysics().
…ysics into rrtmgp-dev2-no-mpi_bcast
dustinswales
requested review from
climbfuji,
grantfirl,
JulieSchramm and
llpcarson
as code owners
There was a problem hiding this comment.
Dustin, I am sending this your way after checking the changes for the non-RRTMGP files and only quickly looking at the RRTMG files. Can you please revert the non-necessary changes in the non-RRTMGP files? We try to minimize such changes in order to facilitate distributed and parallel development. Every now and then, there will be a cleanup PR that does nothing else but making formatting and coding style changes. We need to address the issue with the personal repository for holding the RRTMGP code, though. I will need to take more time to look at your RRTMPG code and understand what it does, but at least I wanted to give you a quick feedback. Thanks!
| l_fluxeslw2d = present(flxprf_lw) | ||
|
|
||
| ! ####################################################################################### | ||
| ! What is vertical ordering? |
There was a problem hiding this comment.
Note: in the future, this will become part of the metadata (the vertical ordering). But we don't have it yet, unfortunately.
| @@ -0,0 +1,33 @@ | |||
| module rrtmgp_aux | |||
There was a problem hiding this comment.
I am not sure what the purpose of this scheme is, but if it is needed only for debugging, then it should probably reside in the developer's fork, not in the official repository.
There was a problem hiding this comment.
Yeah this piece of code is somewhat orphaned.
All calls to RRTMGP routines are wrapped in a call to the function check_error_msg() in rrtmgp_aux.F90.
I can remove this or put it in a more appropriate place.
There was a problem hiding this comment.
If you just need the check_error_msg() helper routine, you could simply remove the CCPP-schemes and keep it as a simple Fortran module to import by the RRTMGP code.
|
I started typing this answer last Friday and it never finished ... It seems that in order to merge this and use it, we need corresponding PRs for fv3atm (to define any variables that are needed for running rrtmgp, and to add the suite definition file(s)), and for ufs-weather-model (to add a regression test). |
|
@climbfuji |
|
This PR was replaced by #413. |
…ather-model (NCAR#400) * Enable running regional telescopic nesting configuration under the ufs-weather-model framework. Enable outputting a grid from the write grid component, which is larger than the native computation grid of the nested/regional domain. a. Remove the limitation of the output grid being completely inside the model native compuation grid. b. Mask out the output grid points outside the computation grid with missing values.
This PR contains the implementation of the RTE-RRTMGP radiation scheme within the CCPP infrastructure.
About RTE-RRTMGP
The rte-rrtmgp source code is managed externally, https://github.com/RobertPincus/rte-rrtmgp, where there is extensive documentation (manuscript, wiki, conventions, etc...)
About RTE-RRTMGP in CCPP
The rte-rrtmgp source code is accessed within CCPP using a submodule, .gitmodules
The code is checked out into physics/rte-rrtmgp/
Within the rte-rrtmgp repository a dtc/ccpp branch has been created, identical to the master branch, with the only difference being the addition of . meta files. These .meta files are required by the CCPP infrastructure in order to use DDTs defined within rte-rrtmgp as interstitial fields
within CCPP.
Implementation (both retrieve this current repo)
in DTC-SCM
https://github.com/dustinswales/gmtb-scm-1/tree/rrtmgp-dev2
in FV3
https://github.com/dustinswales/fv3atm/tree/rrtmgp-dev
For both implementations a few modest changes to the host-model were made:
a) Add rte-rrtmgp source information to CCPP rebuild configuration file (ccpp/config/ccpp_prebuild_config.py).
b) Add new rrtmgp namelist fields (SCM: scm/src/GFS_typedefs.F90; UFS: FV3/gfsphysics/GFS_layer/GFS_typedefs.F90)
c) Declare new rrtmgp scheme/suite level interstitial fields in GFS_typedefs.F90 (and .meta)
For testing in the SCM, the provided test cases were used. In UFS/FV3, I started with the dtc-ccpp regression tests.
Organization of RRTMGP radiation scheme, snippet of physics suite file:
GFS_suite_interstitial_rad_reset
GFS_rrtmgp_pre
GFS_rrtmgp_sw_pre
rrtmgp_sw_gas_optics
rrtmgp_sw_aerosol_optics
rrtmgp_sw_cloud_optics
rrtmgp_sw_cloud_sampling
rrtmgp_sw_rte
GFS_rrtmgp_sw_post
rrtmgp_lw_pre
rrtmgp_lw_gas_optics
rrtmgp_lw_aerosol_optics
rrtmgp_lw_cloud_optics
rrtmgp_lw_cloud_sampling
rrtmgp_lw_rte
GFS_rrtmgp_lw_post
To make the “scheme level” code (e.g. rrtmgp_* routines) as model agnostic as possible only flat model fields are passed as interstitial data. The only exception are rrtmgp DDTs.
SCM results
scm_GvGP_twpice.pdf
UFS results
*There is an issue with the downward LW at the surface in FV3 that is not present in the SCM. This is being explored further.
** MPI_BCAST() is not working in UFS and been commented out. This is not an issue in the SCM, but needs to be sussed out in UFS.