Skip to content

Merge May 16 NCAR main branch to gsl/develop#153

Merged
SamuelTrahanNOAA merged 257 commits into
NOAA-GSL:gsl/developfrom
SamuelTrahanNOAA:gsl/merge-community-to-develop
May 18, 2022
Merged

Merge May 16 NCAR main branch to gsl/develop#153
SamuelTrahanNOAA merged 257 commits into
NOAA-GSL:gsl/developfrom
SamuelTrahanNOAA:gsl/merge-community-to-develop

Conversation

@SamuelTrahanNOAA
Copy link
Copy Markdown
Collaborator

@SamuelTrahanNOAA SamuelTrahanNOAA commented May 18, 2022

This PR will update gsl/develop to the latest NCAR main as of May 16.

Also merges Joe's changes from #143

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

Choose a reason for hiding this comment

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

This MYNN portion (lines 183 to about 190 and the associated endif) should be removed.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

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?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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.

@SamuelTrahanNOAA
Copy link
Copy Markdown
Collaborator Author

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.

Comment thread physics/module_sf_ruclsm.F90

LOGICAL, INTENT(IN) :: mix_chem,fire_turb
LOGICAL, INTENT(IN) :: mix_chem,fire_turb,rrfs_smoke
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

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, &
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Collaborator

@joeolson42 joeolson42 May 18, 2022

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

It was. I had an hour to get it working.

Copy link
Copy Markdown
Collaborator

@joeolson42 joeolson42 left a comment

Choose a reason for hiding this comment

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

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.

@SamuelTrahanNOAA
Copy link
Copy Markdown
Collaborator Author

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?

@joeolson42
Copy link
Copy Markdown
Collaborator

@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.

@SamuelTrahanNOAA
Copy link
Copy Markdown
Collaborator Author

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

@joeolson42
Copy link
Copy Markdown
Collaborator

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.
Then remove ".or. do_mynnedmf" from line 182.
Then remove the "endif" on line 195.

@SamuelTrahanNOAA
Copy link
Copy Markdown
Collaborator Author

@joeolson42 Like this?

          do iLay = 1, nLev
             do iCol = 1, nCol
                !
                ! SGS clouds present, use cloud-fraction modified to include sgs clouds.
                !
                if (imfdeepcnv==imfdeepcnv_gf .and. kdt>1) then
                  ! If no convective cloud condensate present, use GFDL MP cloud-fraction....
                  if (qci_conv(iCol,iLay) <= 0.) then
                    cld_frac(iCol,iLay) = tracer(iCol,iLay,i_cldtot)
                  endif
                !
                ! No SGS clouds, use GFDL MP cloud-fraction...
                !
                else
                   cld_frac(iCol,iLay) = tracer(iCol,iLay,i_cldtot)
                endif
             enddo
          enddo

@joeolson42
Copy link
Copy Markdown
Collaborator

@SamuelTrahanNOAA that's correct.

@SamuelTrahanNOAA
Copy link
Copy Markdown
Collaborator Author

@joeolson42 Do you expect the results of any tests to change?

@joeolson42
Copy link
Copy Markdown
Collaborator

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.

@SamuelTrahanNOAA
Copy link
Copy Markdown
Collaborator Author

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:

   real(kind_phys), intent(inout), optional :: varname(ims:ime,jms:jme)

or it'll crash on some versions of the gnu compiler.

@SamuelTrahanNOAA
Copy link
Copy Markdown
Collaborator Author

This is what you have to do instead:

    real(kind_phys), intent(inout) :: varname(:,:)

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.

@SamuelTrahanNOAA SamuelTrahanNOAA merged commit 7f8b211 into NOAA-GSL:gsl/develop May 18, 2022
zhanglikate referenced this pull request in zhanglikate/ccpp-physics Mar 1, 2024
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.