Merge May 16 NCAR main branch to gsl/develop#153
Conversation
…g calcnfromq from running, which creates number concentration from the initial condition hydrometeor mass
…rious points of very small mass with large reflectivity were showing up, perhaps because of the very large time step in UFS (40s). This helps eliminate those.
…t cleaner. Changes to calcnfromq to set droplet number as 9 micron radius droplets, and then deplete CCN if turned on. Also set masses to zero if less than qxmin.
…er mixing ratios masses are transferred to water vapor. Also added second estimate for graupel number conc. and take minimum. Added air density limit in setvtz and nssl_2mom_gs to limit fall speed or rhovt. Added limit on Bigg freezing to only act if freezing radius is 8mm or less.
…d flag for nssl_ccn_on - Updataed microphysics - Radiation (rrtmg) includes calculated rain radius. Test code to compute radii in the subroutine, but something not right with incoming number concentrations - Renamed mp_nsslg to mp_nssl
…ine instead of using physcons module
…n, cloud ice, snow, graupel, and hail. Graupel and hail have predicted bulk density via the particle volume. Hail can be deactived. Simple CCN concentration can be predicted, either as the count of unactivated or activated nuclei. (Mansell et al. 2010, JAS)
- Split NSSL conditional in GFS_rrtmg_pre.F90 from Thompson for now - Text comments in radiation_clouds.f
…g calcnfromq from running, which creates number concentration from the initial condition hydrometeor mass
| ! If rain/snow present, use GFDL MP cloud-fraction... | ||
| if (tracer(iCol,iLay,i_cldrain)>1.0e-7 .OR. tracer(iCol,iLay,i_cldsnow)>1.0e-7) then | ||
| cld_frac(iCol,iLay) = tracer(iCol,iLay,i_cldtot) | ||
| endif |
There was a problem hiding this comment.
This MYNN portion (lines 183 to about 190 and the associated endif) should be removed.
There was a problem hiding this comment.
According to Sam's comments below, we aren't supposed to make changes, but as soon as we are allowed to make changes, this part of the code will need to be removed.
There was a problem hiding this comment.
Is this a critical bug that needs to be fixed in the community repository? Or can we just change it in gsl/develop and worry about the community in a couple months?
There was a problem hiding this comment.
It will only cause problems when we start testing our suite with RRTMGP, so no, it's not immediately urgent. It may take considerable time to go through all of the radiation-related changes and find a clean fix.
| endif | ||
| enddo | ||
| enddo | ||
| end subroutine cloud_mp_MYNN |
There was a problem hiding this comment.
We haven't started testing RRTMGP yet, but I'm sure this code/module will need to be revisited. This seems to be a partial duplication of SGSCloud_RadPre and I'm not certain yet about the order of calls. This concern is not just for the MYNN but also for GF. We need to have this code in one module only.
There was a problem hiding this comment.
Same comment here: It will only cause problems when we start testing with RRTMGP. It looks like the organization/improvement changes they made to the radiation code were just a first step.
|
We should not add any code changes. This PR needs to mark a point in the branch history where everything worked on all platforms, and matched the authoritative repositories. GSL does not have the ability to test on all platforms, so our only recourse is to not change anything in this PR, unless absolutely necessary. |
|
|
||
| LOGICAL, INTENT(IN) :: mix_chem,fire_turb | ||
| LOGICAL, INTENT(IN) :: mix_chem,fire_turb,rrfs_smoke |
There was a problem hiding this comment.
Here and below, I don't think we need rrfs_smoke because this smoke functionality simply leverages the chem mixing routine, so if rrfs_smoke is set to true in the namelist, then mix_chem should be set to true somewhere upstream of the MYNN. That is, the MYNN doesn't need to even know about this parameter.
There was a problem hiding this comment.
These changes are necessary to run on Cheyenne with the gnu compiler. If you want to try reducing the number of changes without causing the model to crash, they you're welcome to do so... if you have a Cheyenne account.
| @@ -159,7 +161,8 @@ SUBROUTINE mynnedmf_wrapper_run( & | |||
| & icloud_bl, do_mynnsfclay, & | |||
| & imp_physics, imp_physics_gfdl, & | |||
| & imp_physics_thompson, imp_physics_wsm6, & | |||
| & chem3d, frp, mix_chem, fire_turb, nchem, ndvel, & | |||
| & chem3d, frp, mix_chem, rrfs_smoke, fire_turb, nchem, ndvel, & | |||
There was a problem hiding this comment.
same comment as in module_bl_mynn.F90, we shouldn't need both rrfs_smoke and mix_chem. The MYNN doesn't need to know the specific application, it only needs to know that the chem mixing routines are to be used.
There was a problem hiding this comment.
These changes are necessary to run on Cheyenne with the gnu compiler. If you want to try reducing the number of changes without causing the model to crash, they you're welcome to do so... if you have a Cheyenne account.
There was a problem hiding this comment.
Then there must be a bug in the smoke implementation part of the MYNN changes because it should only take one flag to activate/use that portion of the code. That was definitely a rushed implementation that needs a revision.
There was a problem hiding this comment.
It was. I had an hour to get it working.
joeolson42
left a comment
There was a problem hiding this comment.
The only critical change I see is the removal of a block of code in a rrtmgp module (see comments). The rest of my comments are just as much questions as requests. The overwhelming majority of the changes I see are welcomed.
@joeolson42 Are you asking me to change something in this PR? If so, what? |
|
@SamuelTrahanNOAA Sam, the only change I'm referring to is commented on above, In physics/GFS_rrtmgp_cloud_mp.F90, there is a block of code which I had removed from an RRTMG module but it was apparently copied into this RRTMGP module before our code was merged with the community repo. |
|
@joeolson42 I'm stll not sure what you want me to remove. Is it lines 162 through 211 of physics/GFS_rrtmgp_cloud_mp.F90? |
|
Just the mynn portion. I think the GF portion is harmless but probably not needed. That should be tested to be sure. Lines 183-190 need to be deleted. |
|
@joeolson42 Like this? |
|
@SamuelTrahanNOAA that's correct. |
|
@joeolson42 Do you expect the results of any tests to change? |
|
It should change the results for any suite that runs both MYNN-EDMF and RRTMGP, but I don't think we have been testing that combination yet. |
|
In that case, I won't change it in this PR. I'm going to do another PR in a day or two, to add the regression tests we need to debug other problems. I can add your changes at that time. If you have any more changes to fix the other issues you mentioned, please give them to me as soon as possible. Keep in mind though, that the code does have to work on Cheyenne gnu, so you can't do this: or it'll crash on some versions of the gnu compiler. |
|
This is what you have to do instead: That's required by the CCPP coding standards because the gnu compiler (and apparently others) won't accept a null pointer to an optional argument with specified bounds. |
a MERRA2 bug fixed from RRFS
This PR will update gsl/develop to the latest NCAR main as of May 16.
Also merges Joe's changes from #143