GFDL cloud microphysics (slow processes) #122
Conversation
…the top) - Fix long name of sinlat to match standard name
…1, add new interstitial variable frland (land_aera_fraction)
…pecified by host model's calling CMakeLists.txt
…physics (portability changes)
…gument, remove non-CCPP legacy code
…sphysics (documentation only)
…ess_of_stratiform_precipitation_amount to lwe_thickness_of_stratiform_precipitation_amount_on_dynamics_timestep
…itial%mprint and Interstitial%phys_reset require additional argument 'Model'
…P-compliant version of GFDL microphysics, change import/use statement in gfdl_fv_sat_adj (different module name)
…dlmp-slow-physics
climbfuji
force-pushed
the
gfdlmp-slow-physics
branch
from
a53931d to
e847ddf
Compare
| tem = dtp*con_p001/con_day | ||
|
|
||
| do i=1,im | ||
| rain1(i) = (rain0(i)+snow0(i)+ice0(i)+graupel0(i)) * tem |
There was a problem hiding this comment.
What happened to the lines analogous to rain0(i,1) = max(con_d00, rain0(i,1)) in GFS_physics_driver?
There was a problem hiding this comment.
Nevermind, I see that some of the interstitial code was folded into the scheme (or its "driver" routine).
There was a problem hiding this comment.
Yes, I decided to create pre and post routines that take everything not related to flipping arrays and these four lines, because checking that rainfall accumulation fields are >=0 should happen within a scheme - otherwise there is potential that other code might grab this "non-quality-controlled" data and use it.
There was a problem hiding this comment.
IMO, gfdl_cloud_microphys_post_2 is a little confusing. Why should this be directly associated with GFDL MP? I understand that there is a test for whether GFDL MP is used, but this code is embedded within the section for determining surface precipitation type. I was thinking that it might fit better with the existing GFS_calpreciptype code. Thoughts?
physics/precpd.f
Outdated
| @@ -29,7 +29,7 @@ end subroutine zhaocarr_precpd_init | |||
| !! | q | water_vapor_specific_humidity_updated_by_physics | water vapor specific humidity | kg kg-1 | 2 | real | kind_phys | inout | F | | |||
| !! | cwm | cloud_condensed_water_mixing_ratio_updated_by_physics | moist cloud condensed water mixing ratio | kg kg-1 | 2 | real | kind_phys | inout | F | | |||
| !! | t | air_temperature_updated_by_physics | layer mean air temperature | K | 2 | real | kind_phys | inout | F | | |||
| !! | rn | lwe_thickness_of_stratiform_precipitation_amount | stratiform rainfall amount on physics timestep | m | 1 | real | kind_phys | out | F | | |||
| !! | rn | lwe_thickness_of_stratiform_precipitation_amount_on_dynamics_timestep | stratiform rainfall amount on physics timestep | m | 1 | real | kind_phys | out | F | | |||
There was a problem hiding this comment.
I'm assuming that this was changed since it was multiplied by the 'frain' variable at some point. If so, the long name should be changed too. Otherwise, it's confusing.
There was a problem hiding this comment.
I am still confused by the handling of rain. I just check inside GFS_calpreciptype.F90 and there it looks like this is not the case and I should revert this change:
do i = 1, im
prec(i) = rainc(i) + frain * rain1(i)
enddo
! rain1 = rainst
|
Good point about the existing GFS_calpreciptype code. This code has not yet been updated, right? My suggestion is to keep the post_2 as a temporary measure, I can take the calpreciptype interstitial code as my next item on the todo list and merge the post_2 code into there. This way I hopefully understand the different roles of the precip variables better. |
|
I am rerunning the CCPP tests on MacOSX and Theia to make sure that reverting the standard names for rainst and using Diag%rain instead of Interstitial(nt)%rainst as the CCPP variable for rain1 doesn't break the code. On the long run, we should define two types of rainfall fields for each hydrometeor, one on dynamics timestep and one on physics timestep for consistency. |
…ame change from lwe_thickness_of_stratiform_precipitation_amount to lwe_thickness_of_stratiform_precipitation_amount_on_dynamics_timestep, because rain1/rn is on physics time step
…_of_precipitation_amount_on_dynamics_timestep as rain1, because lwe_thickness_of_stratiform_precipitation_amount_on_dynamics_timestep does not exist in FV3
See NCAR/ccpp-framework#102 for a decription of these changes.