miscellaneous changes from NRL #798

grantfirl · 2021-12-07T18:07:08Z

DRAFT

collected other NRL changes from https://github.com/michalakes/ccpp-physics/tree/jm-nrl-32bitfp-24cc09e
viewed changes between the branch above and commit 24cc09e of ccpp-physics
applied changes OTHER THAN precision-related changes
CREDIT to @michalakes

TODO: Which of these changes should get merged into main?

…tfp-24cc09e

grantfirl · 2021-12-07T18:10:38Z

Replaces #772 along with #797

grantfirl · 2021-12-09T20:01:11Z

CMakeLists.txt

@@ -66,6 +66,20 @@ foreach(typedef_module ${TYPEDEFS})
    list(APPEND MODULES_F90 ${CMAKE_CURRENT_BINARY_DIR}/${typedef_module})
 endforeach()

+# This is a hack because I don't know how to get the pre_build to add these


specific to NRL (all current changes in CMakeLists.txt)

grantfirl · 2021-12-09T20:02:06Z

physics/GFS_rad_time_vary.fv3.F90

@@ -15,7 +15,8 @@ module GFS_rad_time_vary
 !> \section arg_table_GFS_rad_time_vary_timestep_init Argument Table
 !! \htmlinclude GFS_rad_time_vary_timestep_init.html
 !!
-      subroutine GFS_rad_time_vary_timestep_init (                                     &
+      subroutine GFS_rad_time_vary_timestep_init (nthrds, blksz, lrseeds, &


All changes in this file seem specific to NRL to me.

I think these changes make the random number generator _not specific to FV3. The random number generation has always been grid specific and this generalizes it.

grantfirl · 2021-12-09T20:02:33Z

physics/GFS_rad_time_vary.fv3.meta

@@ -7,6 +7,34 @@
 [ccpp-arg-table]
  name = GFS_rad_time_vary_timestep_init
  type = scheme
+[nthrds]


All changes in this file correspond to NRL-specific changes in the corresponding Fortran.

grantfirl · 2021-12-09T20:04:11Z

physics/GFS_rrtmg_pre.F90

@@ -16,7 +16,7 @@ end subroutine GFS_rrtmg_pre_init
 !!
      ! Attention - the output arguments lm, im, lmk, lmp must not be set
      ! in the CCPP version - they are defined in the interstitial_create routine
-      subroutine GFS_rrtmg_pre_run (im, levs, lm, lmk, lmp, n_var_lndp,        &
+      subroutine GFS_rrtmg_pre_run (im, levs, lm, lmk, lmp, lextop, ltp, n_var_lndp,        &


Are the changes in this file related to a bugfix or are they specific to NRL?

I think these may be NRL/NEPTUNE-specific.

I think they are bug fixes when using lextop=.true. @matusmartini can comment more.

I remember those, yes. It would be really good to get the lextop bugfixes in. The UFS doesn't use the capability and there are no regression tests that cover it.

Yes, we use this capabilty with success for several suites and maintain it so it does not break our warm restart tests. I added a capability to have lextop as a namelist control flag so it can be turned on/off.

grantfirl · 2021-12-09T20:04:46Z

physics/GFS_rrtmg_setup.F90

@@ -46,7 +44,7 @@ subroutine GFS_rrtmg_setup_init (                          &
          si, levr, ictm, isol, ico2, iaer, ntcw,             &
          num_p3d, npdf3d, ntoz, iovr, isubc_sw, isubc_lw,    &
          icliq_sw, crick_proof, ccnorm,                      &
-          imp_physics,                                        &
+          imp_physics, ltp,                                   &


Are the changes in this file related to a bugfix or are they specific to NRL?

I am checking with our developers. They appear to be NRL-specific, but I'll let you know.

These are related to using lextop=.true.

grantfirl · 2021-12-09T20:05:13Z

physics/gcycle.F90

@@ -209,6 +209,7 @@ subroutine gcycle (me, nthrds, nx, ny, isc, jsc, nsst, tile_num, nlunit,
 !
      enddo
 !
+#if 0


specific to NRL (all changes in this file)

grantfirl · 2021-12-09T20:05:51Z

physics/iounitdef.f

@@ -57,7 +57,7 @@ module module_iounitdef            !
      integer, parameter :: NISIGI2 = 12
      integer, parameter :: NISFCI  = 14
      integer, parameter :: NICO2TR = 15
-      integer, parameter :: NICO2CN = 102
+      integer, parameter :: NICO2CN = 113 ! CCE (Cray) forbids 100-102 20211112 JM


all changes in this file specific to NRL

The change at line 60 is not NRL-specific. You will run into this problem with Fortran unit numbers when you compile with the Cray CCE compiler.

grantfirl · 2021-12-09T20:07:12Z

physics/module_bl_mynn.F90

@@ -950,7 +950,7 @@ SUBROUTINE  mym_length (                     &
        alp2 = 0.65
        alp3 = 3.0
        alp4 = 20.
-        alp5 = 0.4
+        alp5 = 1.2


Are all changes in this file specific to NRL or should they be merged? @michalakes @joeolson42

The change on line 1066 is a bug fix. Communicated this to @joeolson42 and he concurred.

This looks like an older version of the MYNN. Almost all of these parameters have been changed since we spoke about this. Also, some free-atmospheric testing against LES has happened since then and the results show improvements with alp5 decreased, not increased. Here's an example:

We may need to add a new mixing length option if you really want these values added.

I'm not sure we want a different option in there for parameters (however, it would be nice if these were controlled through a namelist since they will be model dependent). The only thing that I was making a point about was the bug on line 1066 that was communicated via email on 19 Feb 2021 and response on 22 Feb confirming that it was a bug.

grantfirl · 2021-12-09T20:07:46Z

physics/module_mp_thompson.F90

@@ -1318,7 +1318,7 @@ SUBROUTINE mp_gt_driver(qv, qc, qr, qi, qs, qg, ni, nr, nc,     &
            m = RSHIFT(ABS(rand_perturb_on),1)
            if (MOD(m,2) .ne. 0) rand2 = rand_pert(i,1,j)*2.
            m = RSHIFT(ABS(rand_perturb_on),2)
-            if (MOD(m,2) .ne. 0) rand3 = 0.25*(rand_pert(i,1,j)+ABS(min_rand))
+            if (MOD(m,2) .ne. 0) rand3 = 0.25*(rand_pert(i,1,j)+ABS(min_rand)) !TODO min_rand used before set 2021112 JM


Commenting out write statements specific to NRL?

grantfirl · 2021-12-09T20:08:18Z

physics/physcons.F90

@@ -35,7 +35,7 @@
 !! constants for GCM models.
          module physcons                
 !
-  use machine, only: kind_phys, kind_dyn
+  use machine


Do we really want to remove specificity of what we need from the machine module?

I remember that the only cluse was causing a compile-time issue, but I would need to go back to recover the details.

grantfirl · 2021-12-09T20:08:42Z

physics/samfdeepcnv.f

@@ -1616,6 +1616,13 @@ subroutine samfdeepcnv_run (im,km,itc,ntc,cliq,cp,cvap,           &
                ktcon1(i) = k
                flg(i) = .false.
              endif
+!NRL MNM: Limit overshooting not to be deeper than the actual cloud


changes in this file are specific to NRL

As explained for sascnvn.F in my comment below, this is to prevent potential negative humidity in rare instances.

grantfirl · 2021-12-09T20:08:56Z

physics/sascnvn.F

@@ -1008,6 +1008,13 @@ subroutine sascnvn_run(
                ktcon1(i) = k
                flg(i) = .false.
              endif
+!NRL MNM: Limit overshooting not to be deeper than the actual cloud


changes in this file are specific to NRL

This was a while back but if I remember correctly, it was to prevent negative QV resulting from overly deep overshooting mostly for relatively shallow updrafts with extremely deep overshoots. This change was before the parameter aafac was reduced from 10% to 5%, which helped but did not eliminate all of the negative values.

Digging through my notes with examples of updrafts with negative QV concentrations:
Cloud base at 1.4 km above ground, level of neutral buoyancy ~3.5 km, with overshooting top is at 18 km!
More points found with cloud base at ~0.6 km, level of neutral buoyancy ~2.5 km, with overshooting top at ~16 km!

The reason for the negative QV’s because of the approximations made in SAS:

First, the moisture content of the rising parcel if it was saturated (qrch) is approximated as the sum of saturated moisture (qeso) and a term that is directly proportional to buoyancy. Generally, overshooting layers are negatively buoyant, and so the sum of the two can < 0 if large buoyancies are present.
Second, the convective overshooting level is estimated as the level where (0.1 * A_ktcon) < 0, where A_ktcon is the cloud work function at the level of neutral buoyancy (ktcon). The 0.1 is a tunable parameter (aafac) independent of the first approximation.

Moreover, there is no check that would stop this from happening in the overshooting layers. There is only a check on negative cloud mass flux (eta) in imfdeepcnv=2, but it only scans levels below the level of neutral buoyancy. There should strictly be a check for negative qrch also in overshooting layers in both options of imfdeepcnv 1 and 2. After playing around with both options 1 and 2 of SAS convection, I see several tuning knobs that can result in increased number of updrafts with negative qrch (all of them near the overshooting cloud top). The most important tuning parameter is the critical thickness of the calculated convection (cthk), which determines whether the convection is deep enough, otherwise it is inhibited. In option 1, this threshold is set to 150 hPa. In option 2, this threshold is increased to 200 hPa. Doing an experiment with the cthk increased to 200 hPa in option 1, eliminates most of the negatively moist parcels. And vice versa, decreasing cthk to 150 hPa in option 2, introduces a few negatively moist parcels. Similar result can be achieved by tuning the aafac parameter.

michalakes · 2021-12-17T16:57:04Z

physics/GFS_rad_time_vary.fv3.F90

@@ -55,24 +60,50 @@ subroutine GFS_rad_time_vary_timestep_init (

         if (lsswr .or. lslwr) then

-           !--- call to GFS_radupdate_timestep_init is now in GFS_rrtmg_setup_timestep_init
+           nblks = size(blksz)


This update and those below that allow the seeds to be supplied by the host model appear to be NRL/NEPTUNE-specific. These for NEPTUNE, but are there any issues for other codes? (I'm not sure how to determine that other than asking other groups to review.)

michalakes · 2021-12-17T17:01:10Z

physics/GFS_rrtmg_pre.F90

@@ -37,11 +37,10 @@ subroutine GFS_rrtmg_pre_run (im, levs, lm, lmk, lmp, n_var_lndp,        &
        clouds9, cldsa, cldfra, faersw1, faersw2, faersw3, faerlw1, faerlw2,   &
        faerlw3, alpha, errmsg, errflg)

-      use machine,                   only: kind_phys
+      use machine,                   only: kind_phys, r8=>kind_dbl_prec


Can the definition of r8. Not used in this routine. Was probably added during debugging and forgot to remove.

michalakes · 2021-12-17T17:01:38Z

physics/GFS_rrtmg_pre.F90

@@ -16,7 +16,7 @@ end subroutine GFS_rrtmg_pre_init
 !!
      ! Attention - the output arguments lm, im, lmk, lmp must not be set
      ! in the CCPP version - they are defined in the interstitial_create routine
-      subroutine GFS_rrtmg_pre_run (im, levs, lm, lmk, lmp, n_var_lndp,        &
+      subroutine GFS_rrtmg_pre_run (im, levs, lm, lmk, lmp, lextop, ltp, n_var_lndp,        &


I think these may be NRL/NEPTUNE-specific.

michalakes · 2021-12-17T17:07:02Z

physics/GFS_rrtmg_setup.F90

@@ -46,7 +44,7 @@ subroutine GFS_rrtmg_setup_init (                          &
          si, levr, ictm, isol, ico2, iaer, ntcw,             &
          num_p3d, npdf3d, ntoz, iovr, isubc_sw, isubc_lw,    &
          icliq_sw, crick_proof, ccnorm,                      &
-          imp_physics,                                        &
+          imp_physics, ltp,                                   &


I am checking with our developers. They appear to be NRL-specific, but I'll let you know.

michalakes · 2021-12-17T17:11:13Z

physics/iounitdef.f

@@ -57,7 +57,7 @@ module module_iounitdef            !
      integer, parameter :: NISIGI2 = 12
      integer, parameter :: NISFCI  = 14
      integer, parameter :: NICO2TR = 15
-      integer, parameter :: NICO2CN = 102
+      integer, parameter :: NICO2CN = 113 ! CCE (Cray) forbids 100-102 20211112 JM


The change at line 60 is not NRL-specific. You will run into this problem with Fortran unit numbers when you compile with the Cray CCE compiler.

michalakes · 2021-12-17T17:16:45Z

physics/physcons.F90

@@ -35,7 +35,7 @@
 !! constants for GCM models.
          module physcons                
 !
-  use machine, only: kind_phys, kind_dyn
+  use machine


I remember that the only cluse was causing a compile-time issue, but I would need to go back to recover the details.

grantfirl · 2022-08-18T18:41:09Z

This is closed in favor of an up-to-date version (#952) that only has the changes not already merged and/or still needed

miscellaneous changes from NRL fork michalakes and branch jm-nrl-32bi…

06708b4

…tfp-24cc09e

This was referenced Dec 7, 2021

Single precision suite-4 from NEPTUNE -- branch jm-nrl-32bitfp-24cc09e -> main #772

Closed

NRL single-precision changes #797

Closed

grantfirl commented Dec 9, 2021

View reviewed changes

michalakes reviewed Dec 17, 2021

View reviewed changes

grantfirl force-pushed the misc_NRL_changes branch from 1cebb6b to 06708b4 Compare January 13, 2022 18:57

grantfirl closed this Aug 18, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

miscellaneous changes from NRL #798

miscellaneous changes from NRL #798

grantfirl commented Dec 7, 2021

grantfirl commented Dec 7, 2021 •

edited

Loading

grantfirl Dec 9, 2021 •

edited

Loading

grantfirl Dec 9, 2021

areinecke Dec 17, 2021

grantfirl Dec 9, 2021

grantfirl Dec 9, 2021

michalakes Dec 17, 2021

areinecke Dec 17, 2021

climbfuji Dec 17, 2021

matusmartini Jan 15, 2022

grantfirl Dec 9, 2021

michalakes Dec 17, 2021

areinecke Dec 17, 2021

grantfirl Dec 9, 2021 •

edited

Loading

grantfirl Dec 9, 2021

michalakes Dec 17, 2021

grantfirl Dec 9, 2021

areinecke Dec 17, 2021

joeolson42 Dec 17, 2021

areinecke Dec 17, 2021

grantfirl Dec 9, 2021

grantfirl Dec 9, 2021

michalakes Dec 17, 2021

grantfirl Dec 9, 2021

matusmartini Jan 15, 2022

grantfirl Dec 9, 2021

matusmartini Jan 15, 2022

michalakes Dec 17, 2021

michalakes Dec 17, 2021

michalakes Dec 17, 2021

michalakes Dec 17, 2021

michalakes Dec 17, 2021

michalakes Dec 17, 2021

grantfirl commented Aug 18, 2022

miscellaneous changes from NRL #798

miscellaneous changes from NRL #798

Conversation

grantfirl commented Dec 7, 2021

grantfirl commented Dec 7, 2021 • edited Loading

grantfirl Dec 9, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

grantfirl Dec 9, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

grantfirl commented Aug 18, 2022

grantfirl commented Dec 7, 2021 •

edited

Loading

grantfirl Dec 9, 2021 •

edited

Loading

grantfirl Dec 9, 2021 •

edited

Loading