Skip to content
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

Merged
merged 52 commits into from
Aug 13, 2020
Merged

Sm jul302020 #486

merged 52 commits into from
Aug 13, 2020

Conversation

SMoorthi-emc
Copy link
Collaborator

I would like this pull request to replace the pull request "Sm jul232020 #149". this is the latest version after merging with rrtmgp update.

Copy link
Collaborator

@climbfuji climbfuji left a 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)
Copy link
Collaborator

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
Copy link
Collaborator

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator

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.

Copy link
Collaborator

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.

Copy link
Collaborator Author

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?

Copy link
Collaborator

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?

Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator

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 ?

Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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.

Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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?

Copy link
Collaborator

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?

Copy link
Collaborator Author

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
Copy link
Collaborator

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)?

Copy link
Collaborator Author

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.

Copy link
Collaborator

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.
Copy link
Collaborator

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.

Copy link
Collaborator Author

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"

Copy link
Collaborator

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

Copy link
Collaborator

@ShanSunNOAA ShanSunNOAA left a 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
Copy link
Collaborator

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.

Copy link
Collaborator Author

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
Copy link
Collaborator

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.

@@ -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
Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator

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.

@ShanSunNOAA
Copy link
Collaborator

ShanSunNOAA commented Aug 10, 2020 via email

Copy link
Collaborator

@grantfirl grantfirl left a 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
Copy link
Collaborator

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, moved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants