Add Noah-MP output variable QRAINXY

[cenlinhe]

TYPE: no impact

KEYWORDS: Noah-MP, output variable

SOURCE: Cenlin He (NCAR/RAL)

DESCRIPTION OF CHANGES:
Change local Noah-MP variable QRAINXY (rain rate on the ground after canopy interception) to be one of the
available standard output variables from Noah-MP. The variable is promoted to state in the Registry and now part
of the NoahMP package. For both NMM and ARW, the field is initialized to zero. For both NMM and ARW, the routine
that calls the physics schemes is modified to thread the new field into the argument list.

LIST OF MODIFIED FILES:
M Registry/Registry.EM_COMMON
M Registry/Registry.NMM
M Registry/registry.noahmp
M dyn_em/module_first_rk_step_part1.F
M dyn_em/start_em.F
M dyn_nmm/module_PHYSICS_CALLS.F
M dyn_nmm/start_domain_nmm.F
M phys/module_physics_init.F
M phys/module_sf_noahmpdrv.F
M phys/module_sf_noahmplsm.F
M phys/module_surface_driver.F
M wrftladj/module_physics_init_ad.F
M wrftladj/module_physics_init_tl.F
M wrftladj/start_em_ad.F
M wrftladj/start_em_tl.F

TESTS CONDUCTED:

1. Conducted compilation and official em_real simulation tests with successful results in Cheyenne
2. Jenkins tests OK

RELEASE NOTE: Change local Noah-MP variable QRAINXY (rain rate on the ground after canopy interception) to Noah-MP output variable.

[cenlinhe]

This is a PR separated from the original PR #1345.

[davegill]

@weiwangncar @dudhia @liujake
Folks,
Here are the files modified for this PR:

LIST OF MODIFIED FILES:
M Registry/Registry.EM_COMMON
M Registry/Registry.NMM
M Registry/registry.noahmp
M dyn_em/module_first_rk_step_part1.F
M dyn_em/start_em.F
M dyn_nmm/module_PHYSICS_CALLS.F
M dyn_nmm/start_domain_nmm.F
M phys/module_physics_init.F
M phys/module_sf_noahmpdrv.F
M phys/module_sf_noahmplsm.F
M phys/module_surface_driver.F
M wrftladj/module_physics_init_ad.F
M wrftladj/module_physics_init_tl.F
M wrftladj/start_em_ad.F
M wrftladj/start_em_tl.F

The whole reason for using phy_init is to initialize the qrainxy to zero. This variable is allocated due to the registry, and is therefore initialized to zero. If we do not need to modify phy_init, then we do not need to call start. Then the required mods look like this:

LIST OF MODIFIED FILES:
M Registry/Registry.EM_COMMON
M Registry/Registry.NMM
M Registry/registry.noahmp
M dyn_em/module_first_rk_step_part1.F
M dyn_nmm/module_PHYSICS_CALLS.F
M phys/module_sf_noahmpdrv.F
M phys/module_sf_noahmplsm.F
M phys/module_surface_driver.F

Is anyone REALLY going to use NoahMP with NMM? If we put a stop in check_a_mundo for that, make variables optional, add an ifdef in the surface driver, then we have these required mods:

LIST OF MODIFIED FILES:
M Registry/Registry.EM_COMMON
M Registry/registry.noahmp
M dyn_em/module_first_rk_step_part1.F
M phys/module_sf_noahmpdrv.F
M phys/module_sf_noahmplsm.F
M phys/module_surface_driver.F

To me, the following looks like the legitimate set of files to change when we are promoting a local variable to be state:

1. Change the registry file
2. rk first step, since the variable is de-referenced
3. the surface driver, to add the new variable in the arg list
4. the specific scheme

We should have been watching the original NoahMP mods more closely. While the mods in this PR indeed will give correct results and are now required, we have made the developers job much more difficult to update this scheme.

Additionally, the registry.noahmp file has about 100 2d arrays that are declared as input from the real program. Those are never initialized via a physics routine call, and they do not come in from metgrid. They are added to the wrfinput file with a bunch of zeros due to the default initialization during allocation. As soon as the wrf model allocates the space for these variables, they are again set to zero values, then the unnecessary input is input and we reset the allocated zeros to input zeros, and then we finally go into phy_init and re-reset the zeros to zeros.

For brand new schemes that come in, we need to provide much more guidance. The result of our previous laissez-faire attitude is that follow-on developers have a much more confusing task to make simple modifications.

[dudhia]

Is this really just the instantaneous rate (mm/s)? I thought accumulation would be more useful.

[cenlinhe]

Is this really just the instantaneous rate (mm/s)? I thought accumulation would be more useful.

Yes, this is the instantaneous rate (mm/s). The accumulation variable is not ready for use in the model and needs extra work to include the calculations, which could be included in the future release.

[dudhia]

@davegill Are you referring to them all being i02 so that they are considered part of input stream 2? We need to check if that is needed. Also your point about not needing these in the phy_init and start_em part is a good one, but this is just done to be the same as rainxy. We could clean up some of this later.