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

After testing with UFS/GFS/FV-3, some tuning knob changes to Thompson-MP and icloud3 (cloud fraction) scheme #1626

Merged
merged 3 commits into from
Jan 20, 2022

Conversation

gthompsnWRF
Copy link
Contributor

@gthompsnWRF gthompsnWRF commented Jan 8, 2022

TYPE: enhancement

KEYWORDS: microphysics, clouds, cloud fraction, Thompson microphysics

SOURCE: Greg Thompson (UCAR/Joint Center for Satellite Data Assimilation)

DESCRIPTION OF CHANGES:
The purpose of these changes is to produce better cloud coverage and radiation amounts per tuning done with
GFS global model and comparisons to observations.

Problem:
The Thompson-MP code (from ccpp-physics) has been used within UFS/GFS/FV-3 global model for multiple
day simulations. Anning Cheng and Ruiyu Sun (NCEP/EMC) have performed most of the simulations and
analysis and iterated with me to make adjustments to the Thompson-MP. At first, EMC found that high
clouds were not present enough, particularly in the tropics. Once switching to a larger upper limit of cloud
ice before it becomes snow, the cloud amounts improved but some clouds and radiation balances were still
not matching results from FV3's GFDL microphysics (which had already been tuned to observations).
Therefore an effort to account for subgrid-scale clouds using the cloud fraction scheme (icloud=3) was
adopted to GFS and tested with various parameter settings.

Solution:
The biggest change is in how cloud ice converts to snow at a threshold size of 300 microns (up from 200
microns) and for rimed snow to convert to graupel (changed from 250 to 350 microns). A change to allowed
max size of ice means that the fall velocity constant for ice was changed to keep it aligned with snow at the
same cut-over size (of 300 microns). In addition, the cloud fraction scheme (icloud=3) can further improve
the clouds and radiation together with Thompson-MP due to the overall under-prediction of clouds. The
icloud3 option was also making far too many clouds when compared to observations so its tuning knobs
were adjusted until attaining the following overall improvements compared to cloud and radiation global
climatologies that EMC uses: cloud amounts of low, middle, high, and total cloud coverage, longwave
radiation outgoing at top-of-atmosphere, and shortwave radiation reaching the ground.

ISSUE:
There are corresponding issues or pull requests in the ccpp-physics repo,
778
781
809

LIST OF MODIFIED FILES:
M module_mp_thompson.F
M module_radiation_driver.F
M module_ra_rrtmg_lw.F
M module_ra_rrtmg_lwf.F
M module_ra_rrtmg_sw.F
M module_ra_rrtmg_swf.F

TESTS CONDUCTED:

  1. A series of tests in GFS including 5, 7, 16, and 30-day long simulations compared to known cloud and
    radiation climatologies. The plots attached here in this comment were created by Anning Cheng. The numbers
    at the top of each panel represent global 3-day (days 3, 4, 5) average.

The first plot is the high/mid/low/total cloud amount. The tunings in this PR reduced the high cloud amount
from over 55% down to the low 40s, which matches observations of global cloud coverage pretty well. And,
another comparison is without the cloud fraction scheme, the mid-level clouds (and low/high) are simply less
than observations, which is something well published in IPCC reports of global model clouds, especially the
Southern Ocean and east sides of ocean basins (low stratus).
gfnl_cf_20190611

The next plot's panel (a) shows the outgoing longwave radiation. The target value global average is about
240 W/m2. Without the cloud fraction scheme and changes to D0s and D0g, the result would be
too much outgoing longwave since it will not contain enough clouds at lower temperatures. Also, the older
version of the cloud fraction scheme with its excessive amount of high clouds would make the outgoing
radiation closer to 225 W/m2. So the tuning of the scheme brings the results closer to observations.

gfnl_prcp_20190611

Lastly, the final plot shows the downward longwave reaching the ground (panel c) and downward shortwave
reaching the ground (panel d).

gfnl_sfc_SWLW_20190611

  1. Jenkins tests are passing.

RELEASE NOTE: Update of the Thompson microphysics scheme and cloud fraction scheme (icloud=3) to match the observations better. The modifications include updates to RRTMG LW and SW, and RRTMG fast LW and SW.

@gthompsnWRF gthompsnWRF requested review from a team as code owners January 8, 2022 19:27
@davegill
Copy link
Contributor

davegill commented Jan 8, 2022

@gthompsnWRF
Greg,
Would you add your affiliation please.

@davegill
Copy link
Contributor

davegill commented Jan 8, 2022

@weiwangncar @dudhia @gthompsnWRF
Folks,
These are mostly just some tweaks to constants. Typical of Greg, this is a very tidy set of mods to review.

@davegill
Copy link
Contributor

davegill commented Jan 8, 2022

@dudhia @weiwangncar
So, do we want this to go to v4.3.3 or to the develop branch for eventual v4.4. The mods do seem small enough for the v4.3.3 branch

@weiwangncar
Copy link
Collaborator

@davegill I'd say this should go to 4.4. It could potentially change the results quite a bit.
@gthompsnWRF Do you have any plots to show the differences, or impact of the change?

@davegill davegill changed the base branch from release-v4.3.3 to develop January 8, 2022 23:51
@gthompsnWRF
Copy link
Contributor Author

@gthompsnWRF Greg, Would you add your affiliation please.

got it

@gthompsnWRF
Copy link
Contributor Author

@davegill I'd say this should go to 4.4. It could potentially change the results quite a bit. @gthompsnWRF Do you have any plots to show the differences, or impact of the change?

I think Wei is right in putting this into v4.4. Results will change for sure - that's pretty much the point to get better cloud prediction so the changes of the D0s variable alone were far larger than I had anticipated for sure. Credit is due here to Ruiyu Sun for trying this when I was skeptical it would be so impactful.

@weiwangncar: I can put some snapshots of results done with GFS model since those simulations were done for me by EMC, otherwise, I would have to run a before/after simulation with WRF to show the increase in upper level cloud ice. Those listed PRs do have a lot of graphics and even full powerpoint files with tons of graphics that I created while testing things. Those led up to these changes. Also, I would need to get the most recent final graphics when changing the cloud fraction scheme through numerous tuning knob changes to get results to match the targets of the variables I listed in description.

@weiwangncar
Copy link
Collaborator

@gthompsnWRF Some plots from GFS tests are ok for us to get a glance at what kind of change is expected. Thanks.

@gthompsnWRF
Copy link
Contributor Author

The plots attached here in this comment were created by Anning Cheng. The numbers at the top of each panel represent global 3-day (days 3, 4, 5) average.

The first plot is the high/mid/low/total cloud amount. The tunings in this PR reduced the high cloud amount from over 55% down to the low 40s, which matches observations of global cloud coverage pretty well. And, another comparison is without the cloud fraction scheme, the mid-level clouds (and low/high) are simply less than observations, which is something well published in IPCC reports of global model clouds, especially the Southern Ocean and east sides of ocean basins (low stratus).
gfnl_cf_20190611

The next plot's panel (a) shows the outgoing longwave radiation. The target value global average is about 240 W/m2. Without the cloud fraction scheme and changes to D0s and D0g, the result would be too much outgoing longwave since it will not contain enough clouds at lower temperatures. Also, the older version of the cloud fraction scheme with its excessive amount of high clouds would make the outgoing radiation closer to 225 W/m2. So the tuning of the scheme brings the results closer to observations.

gfnl_prcp_20190611

Lastly, the final plot shows the downward longwave reaching the ground (panel c) and downward shortwave reaching the ground (panel d). I will fill in the global average target numbers when Anning lets me know those numbers.
gfnl_sfc_SWLW_20190611

@dudhia
Copy link
Collaborator

dudhia commented Jan 12, 2022

I agree this is a change for V4.4. It is a substantial change and not a bug fix.

@dudhia
Copy link
Collaborator

dudhia commented Jan 12, 2022

@gthompsnWRF I think for global radiation budgets the main constraints are outgoing longwave and shortwave which should be about 240 W/m2 and 100 W/m2 for annual global climatology.

modified:   module_ra_rrtmg_lwf.F
modified:   module_ra_rrtmg_swf.F
@davegill
Copy link
Contributor

@weiwangncar @dudhia
Folks,
I added in the changes to RRTMG fast for LW and SW.

Copy link
Collaborator

@weiwangncar weiwangncar left a comment

Choose a reason for hiding this comment

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

Will see how the long simulation tests will show.

@davegill davegill merged commit 9dc68ca into wrf-model:develop Jan 20, 2022
@gthompsnWRF
Copy link
Contributor Author

@weiwangncar @dudhia Folks, I added in the changes to RRTMG fast for LW and SW.

Thanks for doing this Dave - I was going to circle back around to it, just didn't have a chance yet. Yes, it is best to include same mod in the 'fast' copies of RRTMG. And this value of 0.99 can easily be tuned further if sensitivity testing shows it worthwhile. Mike Iacono and I are working on a NOAA-JTTI project together where this could come into play.

@gthompsnWRF
Copy link
Contributor Author

Will see how the long simulation tests will show.

Please keep me posted. Anning Cheng has now run with these code mods for 35 day long global simulation, BTW.

davegill added a commit that referenced this pull request Jan 24, 2022
TYPE: bug fix

KEYWORDS: netcdfpar, Error

SOURCE: internal

DESCRIPTION OF CHANGES:
IMPORTANT: Without these mods, every commit since the parallel netcdf4 IO mods will fail the DA
build test in the regression test. For example, at least these commits:
```
fed10f4 Adding the WRF-Solar EPS model (#1547)
0bda5e0 Fix 4dvar build failure after commit 8b5bfe5 (#1652)
8b5bfe5 Thompson AA enhancements: BC aerosol, biomass burning emissions, and … (#1616)
9dc68ca After testing with UFS/GFS/FV-3, some tuning knob changes to Thompson-MP and icloud3 (cloud fraction) scheme (#1626)
96fd889 Update HONO, TERP, and CO2 emissions (#1644)
64fb190 SFCLAY=1, add shallow water roughness calculation (#1543)
609c2fc New module firebrand_spotting for WRF-Fire (#1540)
75bfe6d MYNN PBL clouds in photolysis option 4 (TUV) (#1622)
f8c4b13 Fix runtime error when using sf_surface_mosaic = 1 with use_wudapt_lcz = 0 (#1638)
b511c70 Run-time option for climate GHG for radiation (#1625)
8194c66 Bug fix for configuration option INTEL:HSW/BDW (#1645)
16c9287  bug fixes for radar_rf_opt=2 (#1642)
a82ce24 Sync with NoahMP Github version with all NoahMP updates since v4.3 (#1641)
7b642cc Bug fix for TAMDAR T VarBC (#1632)
92fd706 fix WRFDA build for Parallel netcdf-4 IO (#1634)
```
Problem:
With PR #1552 "Parallel netcdf-4 IO option" (SHA1 3cd4713), when then code was built without
the new parallel NetCDF4 compression, the build log had an `Error`. 
```
> grep Error compile.log
Fatal Error: Cannot open module file ‘wrf_data_ncpar.mod’ for reading at (1): No such file or directory
make[2]: [diffwrf] Error 1 (ignored)
make[2]: [diffwrf] Error 1 (ignored)
wrf_io.f:117: Error: Can't open included file 'mpif.h'
make[2]: [wrf_io.o] Error 1 (ignored)
Fatal Error: Cannot open module file ‘wrf_data_ncpar.mod’ for reading at (1): No such file or directory
make[2]: [field_routines.o] Error 1 (ignored)
make[2]: [libwrfio_nfpar.a] Error 127 (ignored)
make[2]: [libwrfio_nfpar.a] Error 1 (ignored)
```
The problem was related to constructing the object files in the io_netcdfpar directory. When the 
option is not selected at compile time, then we do not care about errors in the directory that will 
never be used.

Solution:
If the NETCDFPAR option is not selected at compile time, then SKIP going into the io_netcdfpar
directory all together.

LIST OF MODIFIED FILES:
m Makefile
m arch/Config.pl
m arch/configure.defaults
m configure

TESTS CONDUCTED:
1. Without the NETCDFPAR parameter set, the build for the io_netcdfpar directory is bypassed:
```
          cd ../io_netcdfpar ; \
          echo SKIPPING make -i -r NETCDFPARPATH="/glade/u/apps/ch/opt/netcdf/4.7.3/gnu/9.1.0" \

          cd ../io_netcdfpar ; \
          echo SKIPPING make -i -r NETCDFPARPATH="/glade/u/apps/ch/opt/netcdf/4.7.3/gnu/9.1.0" \
```

2. When the NETCDFPAR env variable is set, the build includes the io_netcdfpar directory:
          cd ../io_netcdfpar ; \
           make -i -r NETCDFPARPATH="/glade/u/apps/ch/opt/netcdf/4.8.0/gnu/9.1.0" \

          cd ../io_netcdfpar ; \
           make -i -r NETCDFPARPATH="/glade/u/apps/ch/opt/netcdf/4.8.0/gnu/9.1.0" \
```

3. Jenkins tests are all PASS.
vlakshmanan-scala pushed a commit to scala-computing/WRF that referenced this pull request Apr 4, 2024
…-MP and icloud3 (cloud fraction) scheme (wrf-model#1626)

TYPE: enhancement

KEYWORDS: microphysics, clouds, cloud fraction, Thompson microphysics

SOURCE:  Greg Thompson (UCAR/Joint Center for Satellite Data Assimilation)

DESCRIPTION OF CHANGES:
The purpose of these changes is to produce better cloud coverage and radiation amounts per tuning done with 
GFS global model and comparisons to observations.

Problem:
The Thompson-MP code (from ccpp-physics) has been used within UFS/GFS/FV-3 global model for multiple 
day simulations.  Anning Cheng and Ruiyu Sun (NCEP/EMC) have performed most of the simulations and 
analysis and iterated with me to make adjustments to the Thompson-MP.  At first, EMC found that high 
clouds were not present enough, particularly in the tropics.  Once switching to a larger upper limit of cloud 
ice before it becomes snow, the cloud amounts improved but some clouds and radiation balances were still 
not matching results from FV3's GFDL microphysics (which had already been tuned to observations).  
Therefore an effort to account for subgrid-scale clouds using the cloud fraction scheme (icloud=3) was 
adopted to GFS and tested with various parameter settings.

Solution:
The biggest change is in how cloud ice converts to snow at a threshold size of 300 microns (up from 200 
microns) and for rimed snow to convert to graupel (changed from 250 to 350 microns).  A change to allowed 
max size of ice means that the fall velocity constant for ice was changed to keep it aligned with snow at the 
same cut-over size (of 300 microns).  In addition, the cloud fraction scheme (icloud=3) can further improve 
the clouds and radiation together with Thompson-MP due to the overall under-prediction of clouds.  The 
icloud3 option was also making far too many clouds when compared to observations so its tuning knobs 
were adjusted until attaining the following overall improvements compared to cloud and radiation global 
climatologies that EMC uses:  cloud amounts of low, middle, high, and total cloud coverage, longwave 
radiation outgoing at top-of-atmosphere, and shortwave radiation reaching the ground.

ISSUE:  
There are corresponding issues or pull requests in the ccpp-physics repo, 
[778](NCAR/ccpp-physics#778)
[781](NCAR/ccpp-physics#781)
[809](NCAR/ccpp-physics#809)

LIST OF MODIFIED FILES: 
M  module_mp_thompson.F
M  module_radiation_driver.F
M  module_ra_rrtmg_lw.F
M  module_ra_rrtmg_lwf.F
M  module_ra_rrtmg_sw.F
M  module_ra_rrtmg_swf.F

TESTS CONDUCTED: 
1. A series of tests in GFS including 5, 7, 16, and 30-day long simulations compared to known cloud and 
radiation climatologies. The plots attached here in this comment were created by Anning Cheng. The numbers 
at the top of each panel represent global 3-day (days 3, 4, 5) average.

The first plot is the high/mid/low/total cloud amount.  The tunings in this PR reduced the high cloud amount 
from over 55% down to the low 40s, which matches observations of global cloud coverage pretty well.  And, 
another comparison is without the cloud fraction scheme, the mid-level clouds (and low/high) are simply less 
than observations, which is something well published in IPCC reports of global model clouds, especially the 
Southern Ocean and east sides of ocean basins (low stratus).
![gfnl_cf_20190611](https://user-images.githubusercontent.com/35609171/149175845-585914ce-84d4-4d72-a7e2-e96a5cb9d228.png)

The next plot's panel (a) shows the outgoing longwave radiation.  The target value global average is about 
240 W/m2.  Without the cloud fraction scheme and changes to ```D0s``` and ```D0g```, the result would be 
too much outgoing longwave since it will not contain enough clouds at lower temperatures.  Also, the older 
version of the cloud fraction scheme with its excessive amount of high clouds would make the outgoing 
radiation closer to 225 W/m2.  So the tuning of the scheme brings the results closer to observations.

![gfnl_prcp_20190611](https://user-images.githubusercontent.com/35609171/149176400-41f8b655-3d58-4cc4-adb0-6f6037beed52.png)

Lastly, the final plot shows the downward longwave reaching the ground (panel c) and downward shortwave 
reaching the ground (panel d). 

![gfnl_sfc_SWLW_20190611](https://user-images.githubusercontent.com/35609171/149177060-964ce8bd-02dc-4359-ad5d-37502b2d0f70.png)

2. Jenkins tests are passing.

RELEASE NOTE: Update of the Thompson microphysics scheme and cloud fraction scheme (icloud=3) to match the observations better. The modifications include updates to RRTMG LW and SW, and RRTMG fast LW and SW.
vlakshmanan-scala pushed a commit to scala-computing/WRF that referenced this pull request Apr 4, 2024
TYPE: bug fix

KEYWORDS: netcdfpar, Error

SOURCE: internal

DESCRIPTION OF CHANGES:
IMPORTANT: Without these mods, every commit since the parallel netcdf4 IO mods will fail the DA
build test in the regression test. For example, at least these commits:
```
fed10f4 Adding the WRF-Solar EPS model (wrf-model#1547)
0bda5e0 Fix 4dvar build failure after commit 8b5bfe5 (wrf-model#1652)
8b5bfe5 Thompson AA enhancements: BC aerosol, biomass burning emissions, and … (wrf-model#1616)
9dc68ca After testing with UFS/GFS/FV-3, some tuning knob changes to Thompson-MP and icloud3 (cloud fraction) scheme (wrf-model#1626)
96fd889 Update HONO, TERP, and CO2 emissions (wrf-model#1644)
64fb190 SFCLAY=1, add shallow water roughness calculation (wrf-model#1543)
609c2fc New module firebrand_spotting for WRF-Fire (wrf-model#1540)
75bfe6d MYNN PBL clouds in photolysis option 4 (TUV) (wrf-model#1622)
f8c4b13 Fix runtime error when using sf_surface_mosaic = 1 with use_wudapt_lcz = 0 (wrf-model#1638)
b511c70 Run-time option for climate GHG for radiation (wrf-model#1625)
8194c66 Bug fix for configuration option INTEL:HSW/BDW (wrf-model#1645)
16c9287  bug fixes for radar_rf_opt=2 (wrf-model#1642)
a82ce24 Sync with NoahMP Github version with all NoahMP updates since v4.3 (wrf-model#1641)
7b642cc Bug fix for TAMDAR T VarBC (wrf-model#1632)
92fd706 fix WRFDA build for Parallel netcdf-4 IO (wrf-model#1634)
```
Problem:
With PR wrf-model#1552 "Parallel netcdf-4 IO option" (SHA1 3cd4713), when then code was built without
the new parallel NetCDF4 compression, the build log had an `Error`. 
```
> grep Error compile.log
Fatal Error: Cannot open module file ‘wrf_data_ncpar.mod’ for reading at (1): No such file or directory
make[2]: [diffwrf] Error 1 (ignored)
make[2]: [diffwrf] Error 1 (ignored)
wrf_io.f:117: Error: Can't open included file 'mpif.h'
make[2]: [wrf_io.o] Error 1 (ignored)
Fatal Error: Cannot open module file ‘wrf_data_ncpar.mod’ for reading at (1): No such file or directory
make[2]: [field_routines.o] Error 1 (ignored)
make[2]: [libwrfio_nfpar.a] Error 127 (ignored)
make[2]: [libwrfio_nfpar.a] Error 1 (ignored)
```
The problem was related to constructing the object files in the io_netcdfpar directory. When the 
option is not selected at compile time, then we do not care about errors in the directory that will 
never be used.

Solution:
If the NETCDFPAR option is not selected at compile time, then SKIP going into the io_netcdfpar
directory all together.

LIST OF MODIFIED FILES:
m Makefile
m arch/Config.pl
m arch/configure.defaults
m configure

TESTS CONDUCTED:
1. Without the NETCDFPAR parameter set, the build for the io_netcdfpar directory is bypassed:
```
          cd ../io_netcdfpar ; \
          echo SKIPPING make -i -r NETCDFPARPATH="/glade/u/apps/ch/opt/netcdf/4.7.3/gnu/9.1.0" \

          cd ../io_netcdfpar ; \
          echo SKIPPING make -i -r NETCDFPARPATH="/glade/u/apps/ch/opt/netcdf/4.7.3/gnu/9.1.0" \
```

2. When the NETCDFPAR env variable is set, the build includes the io_netcdfpar directory:
          cd ../io_netcdfpar ; \
           make -i -r NETCDFPARPATH="/glade/u/apps/ch/opt/netcdf/4.8.0/gnu/9.1.0" \

          cd ../io_netcdfpar ; \
           make -i -r NETCDFPARPATH="/glade/u/apps/ch/opt/netcdf/4.8.0/gnu/9.1.0" \
```

3. Jenkins tests are all PASS.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants