Adding field from CCPP radiation routines in UFS MRW history files #697
Replies: 6 comments 9 replies
-
Adding 3-D variables to history files largely increases the size of model output, which is a concern for operation. In principle, only model prognostic variables should be included in history files. For the version running with GFDL MP, cloud fraction has already been included in history files. |
Beta Was this translation helpful? Give feedback.
-
Can you use the cldfra array, which is computed in
ufs-weather-model/FV3/ccpp/physics/physics/GFS_rrtmg_pre.F90
do k = 1, LMK
do i = 1, IM
clouds1(i,k) = clouds(i,k,1)
clouds2(i,k) = clouds(i,k,2)
clouds3(i,k) = clouds(i,k,3)
clouds4(i,k) = clouds(i,k,4)
clouds5(i,k) = clouds(i,k,5)
clouds6(i,k) = clouds(i,k,6)
clouds7(i,k) = clouds(i,k,7)
clouds8(i,k) = clouds(i,k,8)
clouds9(i,k) = clouds(i,k,9)
* cldfra(i,k) = clouds(i,k,1)*
enddo
enddo
…On 7/14/2021 4:20 PM, JohnMHenderson wrote:
I would like to add the cloud fraction used by the radiation
computations to the UFS MRW dyn*nc output files via the write
component for eventual pickup by UPP. A couple of years ago, I added a
field for conversion by UPP to the FV3-SAR by (in part) modifying
atmos_cubed_sphere/driver/fvGFS/fv_nggps_diag.F90. Before I coded this
time, I wanted to gauge the community's impression of the best
approach. Of concern is the general availability of fields in
fv_nggps_diag.F90 that are computed deep inside CCPP, instead of being
computed by routines found in atmos_cubed_model.
Specifically, how do I access the array "clouds" that is computed via
a call to progclduni (subroutine is located in
ccpp/physics/physics/radiation_cloud.f) from
ccpp/physics/physics/GFS_rrtmg_pre.F90?:
|call progclduni (plyr, plvl, tlyr, tvly, ccnd, ncndl, & ! --- inputs
Grid%xlat, Grid%xlon, Sfcprop%slmsk, dz,delp, & IM, LMK, LMP, cldcov,
& effrl, effri, effrr, effrs, Model%effr_in, & clouds, cldsa, mtopa,
mbota, de_lgth) ! --- outputs |
Any guidance would be much appreciated.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#697>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALQ75MOWCPM57TUO4BI24VLTXXWR3ANCNFSM5AMFESNQ>.
|
Beta Was this translation helpful? Give feedback.
-
Note that the 3D cloud fraction can be output to the history files by
adding this line to the diag_table:
"gfs_phys", "cldfra", "cldfra", "fv3_history2d", "all",
.false., "none", 2
In the FV3-SAR (FV3-LAM now), the UPP reads in this 3D cloud fraction field.
Eric
…On 7/14/2021 4:20 PM, JohnMHenderson wrote:
I would like to add the cloud fraction used by the radiation
computations to the UFS MRW dyn*nc output files via the write
component for eventual pickup by UPP. A couple of years ago, I added a
field for conversion by UPP to the FV3-SAR by (in part) modifying
atmos_cubed_sphere/driver/fvGFS/fv_nggps_diag.F90. Before I coded this
time, I wanted to gauge the community's impression of the best
approach. Of concern is the general availability of fields in
fv_nggps_diag.F90 that are computed deep inside CCPP, instead of being
computed by routines found in atmos_cubed_model.
Specifically, how do I access the array "clouds" that is computed via
a call to progclduni (subroutine is located in
ccpp/physics/physics/radiation_cloud.f) from
ccpp/physics/physics/GFS_rrtmg_pre.F90?:
|call progclduni (plyr, plvl, tlyr, tvly, ccnd, ncndl, & ! --- inputs
Grid%xlat, Grid%xlon, Sfcprop%slmsk, dz,delp, & IM, LMK, LMP, cldcov,
& effrl, effri, effrr, effrs, Model%effr_in, & clouds, cldsa, mtopa,
mbota, de_lgth) ! --- outputs |
Any guidance would be much appreciated.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#697>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALQ75MOWCPM57TUO4BI24VLTXXWR3ANCNFSM5AMFESNQ>.
|
Beta Was this translation helpful? Give feedback.
-
Add the following line to your diag_table and see if the output looks
correct. It's the 3D cloud fraction. It's computed at the end of the
GFS_rrtmg_pre.F90 after the call to all of the progcld subroutines. I've
used it for the GFDL and Thompson mp schemes.
"gfs_phys", "cldfra", "cldfra", "fv3_history2d", "all",
.false., "none", 2
Eric
…On 7/16/2021 6:44 PM, JohnMHenderson wrote:
Yes, this gets to the heart of my question - how best can I access the
clouds array computed in GFS_rrtmg_pre.F90 or a new variable, cldfra,
that is a subset? Would I propagate this new variable through
fv_diagnostics.F90 to be picked up by diag_table (this approach didn't
allow for pickup via UPP in my earlier LAM work) or, as I mentioned,
fv_nggps_diag.F90? Or, more conveniently, is the full clouds array
already accessible to either/both of these routines, negating the need
to define a new variable starting in
atmos_cubed_sphere/model/fv_arrays.F90? I had seen a comment by Jun
Wang
(https://forums.ufscommunity.org/threads/adding-new-diagnostic-output
<https://forums.ufscommunity.org/threads/adding-new-diagnostic-output>)
stating that use of fv_nggps_diag.F90 was needed for mods to dynf*.nc
or phyf*.nc.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#697 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALQ75MM75EBJKWWCO3GCXMDTYCY5TANCNFSM5AMFESNQ>.
|
Beta Was this translation helpful? Give feedback.
-
Sorry to hear that it's not in the UFS MRW repo. I'm not familiar with
that. I will say it is in the latest NCAR/ccpp-physics repo:
https://github.com/NCAR/ccpp-physics/blob/main/physics/GFS_rrtmg_pre.F90
Eric
…On 7/19/2021 3:25 PM, JohnMHenderson wrote:
The 'cldfra' array is not currently in GFS_rrtmg_pre.F90 obtained from
the UFS MRW repo:
...
. call progcld5 (plyr,plvl,tlyr,qlyr,qstl,rhly,tracer1, & ! --- inputs
Grid%xlat,Grid%xlon,Sfcprop%slmsk,dz,delp, &
ntrac-1, ntcw-1,ntiw-1,ntrw-1, &
ntsw-1,ntgl-1, &
im, lmk, lmp, Model%uni_cld, &
Model%lmfshal,Model%lmfdeep2, &
cldcov(:,1:LMK),Tbd%phy_f3d(:,:,1), &
Tbd%phy_f3d(:,:,2), Tbd%phy_f3d(:,:,3), &
clouds,cldsa,mtopa,mbota, de_lgth) ! --- outputs
|endif ! end if_imp_physics |
! endif ! end_if_ntcw
|do k = 1, LMK do i = 1, IM clouds1(i,k) = clouds(i,k,1) clouds2(i,k)
= clouds(i,k,2) clouds3(i,k) = clouds(i,k,3) clouds4(i,k) =
clouds(i,k,4) clouds5(i,k) = clouds(i,k,5) clouds6(i,k) =
clouds(i,k,6) clouds7(i,k) = clouds(i,k,7) clouds8(i,k) =
clouds(i,k,8) clouds9(i,k) = clouds(i,k,9) enddo enddo |
! mg, sfc-perts
! --- scale random patterns for surface perturbations with
...
I was intending to add a similar line, but was hoping to get an
understanding of what (and where) other code is required. Unless I'm
mistaken, it would take more than a single line in diag_table.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#697 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALQ75MOGYSAZVYHN47EFXRDTYR33XANCNFSM5AMFESNQ>.
|
Beta Was this translation helpful? Give feedback.
-
John - Here are a few steps that should allow you to implement a solution similar to what Eric did in the latest/develop code, but using the MRW App version which you've been using. There have been substantial code re-organizations inbetween these versions, so it's a bit complicated. Starting with the code for the MRW App,
|
Beta Was this translation helpful? Give feedback.
-
I would like to add the cloud fraction used by the radiation computations to the UFS MRW dyn*nc output files via the write component for eventual pickup by UPP. A couple of years ago, I added a field for conversion by UPP to the FV3-SAR by (in part) modifying atmos_cubed_sphere/driver/fvGFS/fv_nggps_diag.F90. Before I coded this time, I wanted to gauge the community's impression of the best approach. Of concern is the general availability of fields in fv_nggps_diag.F90 that are computed deep inside CCPP, instead of being computed by routines found in atmos_cubed_model.
Specifically, how do I access the array "clouds" that is computed via a call to progclduni (subroutine is located in ccpp/physics/physics/radiation_cloud.f) from ccpp/physics/physics/GFS_rrtmg_pre.F90?:
Any guidance would be much appreciated.
Beta Was this translation helpful? Give feedback.
All reactions