Adding the MAD-WRF model

[davegill]

TYPE: New feature

KEYWORDS: MAD-WRF, MADCast, WRF-Solar, cloud initialization, cloud advection/diffusion, nudging

SOURCE: Pedro Jimenez, Jared Lee, and Jimy Dudhia (NCAR), and Greg Thompson (JCSDA)

DESCRIPTION OF CHANGES:
Problem: There is room for improvement in the short range shortwave irradiance predictions

Solution:
MAD-WRF is a solar irradiance nowcasting system that combines:

1. the benefits of data assimilation and the philosophy of advecting cloud properties of MADCast, and
2. the cloud physics of WRF-Solar.

The initial cloud field can be enhanced based on relative humidity and the model can impose the cloud mask and the cloud top / base height from available earth observations. The hydrometeor content is advected and diffused as tracers, and the resolved hydrometeors are nudged towards these tracers at the beginning of the simulation to facilitate the cloud spin up. This results in improved solar irradiance prediction in the short-range (the first hours). There is an option to run MAD-WRF with just advecting and diffusing the hydrometeors.

We extensively tested MAD-WRF performance using an implementation in an older version of WRF. Our results show the improved performance at the beginning of the simulation.

The following technical description follows the README.madwrf file in the doc directory. There are two options to run MAD-WRF:

1. madwrf_opt = 1: The initial hydrometeors are advected and diffused with the model dynamics without accounting for any microphysical processes.

   • The user should set mp_physics = 96 and use_mp_re = 0 in the physics block of the WRF namelist.

2. madwrf_opt = 2: There is a set of hydrometeor tracers that are advected and diffused with the model dynamics.

   • At initial time the tracers are equal to the standard hydrometeors.
   • During the simulation the standard hydrometeors are nudged towards the tracers.
   • The namelist variable madwrf_dt_nudge sets the temporal period for hydrometeor nudging [min]
   • The namelist madwrf_dt_relax sets the relaxation time for hydrometeor nudging [s]

MAD-WRF has an option to enhance the cloud initialization. To turn on (off) the cloud initialization set the namelist variable madwrf_cldinit to 1 (0)

By default the model enhances the cloud analysis based on the analyzed relative humidity. The user can enhance the cloud initialization by providing additional variables to Metgrid via the WPS intermediate format. These variables are the cloud mask (CLDMASK), the cloud top height (CLDTOPZ [m asl]), the brightness temperature (BRTEMP, e.g. GOES-R ABI channel 13) and the cloud base height (CLDBASEZ [m agl]). These are the combinations of variables allowed in MAD-WRF (see the README.madwrf file in the doc subdirectory for further details).

1. Cloud mask (CLDMASK variable):

   • Remove clouds if clear (cldmask = 0)

2. Cloud mask (CLDMASK variable) + brightness temperature (BRTEMP variable) sensitive to hydrometeor content (e.g. GOES-R channel 13):

   • Remove clouds if clear (cldmask = 0)
   • Reduce / extend cloud top heights to match observations
   • Add clouds over clear sky regions (cldmask = 1)

3. Cloud top height (CLDTOPZ variable) with 0 values over clear sky regions

   • Remove clouds if clear (cldmask = 0)
   • Reduce / extend cloud top heights to match observations
   • Add clouds over clear sky regions (cldmask = 1)

4. Either 2 or 3 + the cloud base height (CLDBASEZ variable)

   • Remove clouds if clear (cldmask = 0)
   • Reduce / extend cloud top / base heights to match observations

The following lines should be added to the metgrid table:

========================================
name=CLDMASK
        interp_option=nearest_neighbor
        flag_in_output=FLAG_CLDMASK
========================================
name=CLDBASEZ
        interp_option=nearest_neighbor
        flag_in_output=FLAG_CLDBASEZ
========================================
name=CLDTOPZ
        interp_option=nearest_neighbor
        flag_in_output=FLAG_CLDTOPZ
========================================
name=BRTEMP
        interp_option=nearest_neighbor
        flag_in_output=FLAG_BRTEMP
========================================

LIST OF MODIFIED FILES:
M Registry/Registry.EM
M Registry/Registry.EM_COMMON
M Registry/Registry.NMM
M Registry/Registry.tladj
M Registry/registry.chem
A doc/README.madwrf
M dyn_em/depend.dyn_em
M dyn_em/module_big_step_utilities_em.F
M dyn_em/module_initialize_real.F
M dyn_em/solve_em.F
M main/depend.common
M phys/Makefile
A phys/module_madwrf.F
M phys/module_microphysics_driver.F
M phys/module_physics_init.F
M run/README.namelist
M share/module_check_a_mundo.F
M share/module_optional_input.F

TESTS CONDUCTED:

1. We are currently running a demonstration of the model (operations tab in https://ral.ucar.edu/projects/mad-wrf). The following figure show the MAE as a function of the lead time calculated with MAD-WRF, WRF-Solar and MAD-WRF run in MADCast mode. These results are from our MAD-WRF implementation in an older version of WRF and will be updated with results using the code in this develop branch.

2. The jenkins tests are all passing.

RELEASE NOTE: Adding the MAD-WRF model to improve solar irradiance nowcasting (https://ral.ucar.edu/projects/mad-wrf).

[davegill]

@dudhia @pedro-jm

This is a replacement for PR #1370

[davegill]

@pedro-jm
There seems to be a sentence that ended abruptly in the PR description:

The user can enhance the cloud initialization by providing additional variables to metgrid via the WPS intermediate for mat:

[davegill]

@pedro @dudhia @weiwangncar

The user can enhance the cloud initialization by providing additional variables to metgrid

The fields are: CLDMASK, CLDBASEZ, CLDTOPZ, BRTEMP.

Where do these come from? Do we suggest an input file source? Do we need a Vtable?

[pedro-jm]

@pedro @dudhia @weiwangncar

The user can enhance the cloud initialization by providing additional variables to metgrid

The fields are: CLDMASK, CLDBASEZ, CLDTOPZ, BRTEMP.

Where do these come from? Do we suggest an input file source? Do we need a Vtable?

Thanks for your help with the PR.

These fields come from observations. For example, I am using cloud mask, cloud top height and brightness temperature from GOES satellites, and the cloud base height from METAR observations. The README.madwrf file in the doc directory documents the different combinations of variables allowed. This comes after the sentence that ended abruptly in your comment above. After the sentence comes the description of the combination of variables that MAD-WRF can handle. Once we resolve the current conflicts I can clarify a bit the description in the README.madwrf file.

No need for Vtable since these obs come via the WPS intermediate format since they are not in grib format. I put in the description of the PR above what should be added to the Metgrid table so the logic that in Real can use the flags from the met_em files to incorporate the variables in the analysis.

[pedro-jm]

@pedro-jm
There seems to be a sentence that ended abruptly in the PR description:

The user can enhance the cloud initialization by providing additional variables to metgrid via the WPS intermediate for mat:

@davegill
I enhanced the description in the PR description. If something still is not clear let me know. I will enhance the README.madwrf file after resolving these conflicts.

[davegill]

Latest jenkins is all PASS

Please find result of the WRF regression test cases in the attachment. This build is for Commit ID: 173a0b4d3322d8c76b53adcbad593455387a3f9b, requested by: davegill for PR: https://github.com/wrf-model/WRF/pull/1417. For any query please send e-mail to David Gill.

    Test Type              | Expected  | Received |  Failed
    = = = = = = = = = = = = = = = = = = = = = = = =  = = = =
    Number of Tests        : 19           18
    Number of Builds       : 48           46
    Number of Simulations  : 163           161        0
    Number of Comparisons  : 103           102        0

    Failed Simulations are: 
    None
    Which comparisons are not bit-for-bit: 
    None

[davegill]

@pedro-jm @dudhia
Please use this fork branch for the MAD-WRF effort:
#1417

The conflicts are resolved in this PR. I am going to close #1370.

[davegill]

@dudhia @pedro-jm @weiwangncar
Jimy and Wei,
I think MAD-WRF is ready for a review:

1. the conflicts are resolved
2. the jenkins tests are OK
3. the file list in the PR matches the github count (no longer 18 vs 220)

Please make sure that you use PR #1417. We have closed the previous PR.

[dudhia]

This commit has a version cldfra3_madwrf that is related to cldfra3 in the radiation driver and these should be merged and put in a cldfra3 module (like in MPAS) either for this release or the next one.