-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sm jul302020 #486
Sm jul302020 #486
Conversation
…into SM_Mar032020
… Whole Atmosphere Model
…e physics routines
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One tiny request for change, otherwise this looks good to me!
@@ -598,7 +590,7 @@ subroutine GFS_rrtmg_pre_run (Model, Grid, Sfcprop, Statein, & ! input | |||
qc_mp (i,k) = tracer1(i,k,ntcw)/(1.-qvs) | |||
qi_mp (i,k) = tracer1(i,k,ntiw)/(1.-qvs) | |||
qs_mp (i,k) = tracer1(i,k,ntsw)/(1.-qvs) | |||
nc_mp (i,k) = nt_c*orho(i,k1) | |||
nc_mp (i,k) = nt_c*orho(i,k) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for fixing this bug.
endif | ||
enddo | ||
endif | ||
endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SMoorthi-emc @dustinswales Do you agree that the block in lines 297-333 is a repetition of the block in lines 257-295 (which is to be executed if use_GP_jacobian, an RRTMGP-specific flag, is .false.
)? If so, please delete lines 297-333 and we can close issue #485 when the code is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dom, I have removed these duplicate code, which happened while merging.
I guess RRTMGP does not take into account fractional grid or ice/water fractions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this. Yes, I agree that RRTMGP has not been implemented for or tested with the fractional grid or ice/water fractions. Something to tackle for @dustinswales in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SMoorthi-emc @climbfuji
Thanks for removing this excess code.
In GP the surface state is implicit within the Jacobian of the upwelling/downwelling LW, so there's no need to condition the flux adjustment factor on the surface.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dustin,
Does RRTMGP takes into account fluxes over land, water and ice within a grid box through Jacobian?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SMoorthi-emc
Yes, this is my understanding.
@RobertPincus Can you chime in here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SMoorthi-emc @dustinswales RRTMGP assumes uniform but spectrally-varying surfaces under each grid cell for the radiation calculation. Does that answer the question?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I don't understand how you know the temp over land, ice, and water and ice fraction spectrally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dustinswales Can you point @SMoorthi-emc to where the surface temperature is set for RRTMGP ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SMoorthi-emc
In GFS_surface_composites.F90/.meta the tsfc/"surface_skin_temperature" is conditioned on surface type, land/ice/ocean.
@@ -604,7 +613,7 @@ | |||
[min_lakeice] | |||
standard_name = lake_ice_minimum | |||
long_name = minimum lake ice value | |||
units = ??? | |||
units = frac |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
@@ -324,7 +324,7 @@ subroutine micro_mg_init( & | |||
|
|||
!----------------------------------------------------------------------- | |||
|
|||
dcs = micro_mg_dcs * 1.0e-6 | |||
dcs = micro_mg_dcs * 1.0e-6_r8 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is ok to use _r8
here, given that the existing definition for the floating point kind is r8
. Suggests that this was implemented with double precision in mind and signals that anyone trying to run this in single precision need to be cautious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally still think that is is confusing to use _r8 when it is customary to reserve that for double precision. If one pays attention, they can see that it is set to kind_phys above, but as you know, not everyone is so observant. I also think that we are taking a leap assuming that your interpretation (that leaving in r8 sends a message to future developers) is obvious. A comment about it where r8 is set to kind_phys could clarify things though: "Although this scheme was developed with double precision in mind, the real kind is set to a variable to be consistent with other physics and to be easily modifiable in one place" or something like that.
endif | ||
enddo | ||
endif | ||
endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this. Yes, I agree that RRTMGP has not been implemented for or tested with the fractional grid or ice/water fractions. Something to tackle for @dustinswales in the future.
srflag(i) = 0. ! clu: default srflag as 'rain' (i.e. 0) | ||
if (tsfc(i) >= 273.15) then | ||
srflag(i) = zero ! clu: default srflag as 'rain' (i.e. 0) | ||
if (tsfc(i) >= 273.15_kind_phys) then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is one parameter defined in GFS_typedefs.F90: real(kind=kind_phys) :: tcr = 273.16d0
Should tcr be used here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, @shansun6. I see the local variable is 273.15
, tcr
is 273.16
. Further down, t850
is compared to a local 273.16
value - @SMoorthi-emc wouldn't it be better to follow @shansun6 suggestion and use tcr
in both places? Any reason why the two values differ by one hundreds of a degree Kelvin?
Will this change the answer for the regression test baselines?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shan, I think there is a reason why this number is 273,15. I did not change this number, only added "kind_phys".
if (rain(i) > rainmin) then | ||
tem1 = max(zero, (rain(i)-rainc(i))) * sr(i) | ||
tem2 = one / rain(i) | ||
if (t850(i) > 273.16_kind_phys) then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar here: should line 313 be replaced by if (t850(i) > tcr)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be changed, but I would leave for the next edition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine by me.
else | ||
cice(i) = zero | ||
cice(i) = zero | ||
flag_cice(i) = .false. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Line 85 is not necessary because of line 79.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure about that. It is just resetting "flag_cice" if it is "true" and "cice < min_seaice"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry - spoke too soon. I took it back. Line 85 should be there. -Shan
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes made to routines that I am familiar with are all good. Very nice work, Moorthi! -Shan
real(kind=kind_phys), parameter :: a4 = 35.86 | ||
real(kind=kind_phys), parameter :: zero = 0.0_kind_phys | ||
real(kind=kind_phys), parameter :: one = 1.0_kind_phys | ||
real(kind=kind_phys), parameter :: rhoh2o = 1000.0_kind_phys |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This constant already exists physcons as rhowater.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All I did was to add kind_phys to what already was there. Yes, we could do a lot more cleanup.
When I was doing some of these changes, the reason was to get restart reproducibility, for which precision was important.
real(kind=kind_phys), parameter :: one = 1.0_kind_phys | ||
real(kind=kind_phys), parameter :: rhoh2o = 1000.0_kind_phys | ||
real(kind=kind_phys), parameter :: a2 = 17.2693882_kind_phys | ||
real(kind=kind_phys), parameter :: a3 = 273.16_kind_phys |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As already pointed out, 273.15 and 273.16 both already exist in physcons as con_t0c and con_ttp, respectively.
physics/wv_saturation.F
Outdated
@@ -9,12 +9,12 @@ | |||
!! This module contain some utility functions for saturation vapor pressure. | |||
module wv_saturation | |||
#ifdef GEOS5 | |||
use MAPL_ConstantsMod, r8 => MAPL_R8 | |||
use MAPL_ConstantsMod, kp => MAPL_kp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this going to cause an issue if GEOS5 is ever set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch Grant. this happened becasue I changed "_r8" to "_kp".
I don't think there is any "MAPL_kp". I could change this back now or leave it for the future. We are really not using this option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest to either change it back to avoid that someone runs into an issue in a few years time and the knowledge about this issue-to-fix is gone, or to create an issue on the same ccpp-physics GitHub repo so that the next commit can fix this.
Hi Moorthi,
I realized this myself before seeing your email - sorry about the false
alarm. This is actually a fairly important line.
Shan
…On Mon, Aug 10, 2020 at 9:11 AM SMoorthi-emc ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In physics/GFS_surface_composites.F90
<#486 (comment)>:
> else
- cice(i) = zero
+ cice(i) = zero
+ flag_cice(i) = .false.
I am not sure about that. It is just resetting "flag_cice" if it is "true"
and "cice < min_seaice"
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#486 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALORMVQTGO3UDNJHSXE5SELSAAE23ANCNFSM4PY6EKFA>
.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, it's good to go as-is if it passes RTs, although I left some comments that could be addressed in the future. Most of them are related to code that existed before this PR, but were just made more obvious by the changes in this PR.
@@ -9,7 +9,7 @@ | |||
!! This module contain some utility functions for saturation vapor pressure. | |||
module wv_saturation | |||
#ifdef GEOS5 | |||
use MAPL_ConstantsMod, kp => MAPL_kp | |||
use MAPL_ConstantsMod, kp => MAPL_R8 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't line 17 (use machine, only : kp => kind_phys
) be inside #ifdef NEMS_GFS
? Like, for example, in aer_cloud.F or cldwat2m_micro.F
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, moved.
I would like this pull request to replace the pull request "Sm jul232020 #149". this is the latest version after merging with rrtmgp update.