Fix to allow use_theta_m=1 with vertical nesting and simplify rebalance options

[rsarthur]

TYPE: bug fix

KEYWORDS: vertical nesting, vert_refine_method, use_theta_m, rebalance

SOURCE: Robert Arthur and Katie Lundquist, LLNL

DESCRIPTION OF CHANGES:
Problem:

1. When vertical nesting is used with the moist theta option (use_theta_m=1), large errors occur in the vertically-
   refined domain. This is the main problem addressed in this PR.
2. Another minor issue is that rebalance option 2 is redundant, and is therefore unnecessary.

Solution:

1. Several use_theta_m flags were added to the rebalancing routines in start_em.F and module_dm.F, which are
   called when vertical nesting is used. Thus, the rebalanced pressure, inverse density, and geopotential fields are
   calculated correctly and consistently with the rest of the code, regardless of whether use_theta_m=0 or 1.
2. Rebalance option 2 has been removed. Now, rebalance must be set to 1 when vertical nesting is turned on.

LIST OF MODIFIED FILES:
Registry/Registry.EM_COMMON
dyn_em/module_initialize_real.F
dyn_em/start_em.F
external/RSL_LITE/module_dm.F
share/module_check_a_mundo.F

TESTS CONDUCTED:

1. A 4-domain nested case was completed with vertical refinement on d04. All domains were initialized from a
   wrfinput file and eta levels were not provided. Pertinent namelist options are:

input_from_file = .true., .true., .true., .true.,
e_vert = 45, 45, 45, 55,
vert_refine_method = 0, 0, 0, 2,
rebalance = 1,
hybrid_opt = 0,
use_theta_m = 0 or 1, depending on the case

Results are summarized in the plot below, which shows U at the first grid point above the surface on d04 at
various output times.

With the original code, vertical nesting works with use_theta_m=0, but not use_theta_m=1. With the updated code,
results look reasonable for use_theta_m=1 and are roughly the same as for use_theta_m=0. Similar patterns are also
seen for other variables, such as V and MU, although they are not shown here.

2. Several similar tests were also conducted, as above but with
   • d04 initialized via interpolation from d03 during runtime, rather than from wrfinput_d04
   • eta levels specified for each domain in the namelist

These tests provided qualitatively similar results to the above, showing that the fix works for a range of possible
domain setups.

3. Finally, a test was completed with use_theta_m=0, but using the updated code. This showed bit-for-bit identical
   results (using diffwrf) to the same case using the original code, confirming that previous vertical nesting functionality
   with use_theta_m=0 is maintained.

RELEASE NOTE: Vertical refinemnet now works with the moist theta option use_theta_m=1. The redundant "rebalance" option 2 was removed. The rebalance option must now be set to 1 when vertical refinement is turned on.

[weiwangncar]

@rsarthur How does vertical nesting relate to module_initialize_real.F? Is initialization of vertical nesting done in real.exe?

[rsarthur]

@weiwangncar
Yes, if input_from_file=true for a domain with vertical nesting, then vert_refine_method is used in the specification of eta levels for that domain in module_initialize_real. Rebalancing is also performed in module_initialize_real.

If input_from_file=false and vertical nesting is turned on for a given domain, then the vertically-nested domain is interpolated from the parent during runtime. In this case, the eta levels are specified using the vert_cor_vertical_nesting_* subroutines in dyn_em/nest_init_utils.F.

[weiwangncar]

@rsarthur Thanks!