Skip to content

Fix DA default gen_be_vertloc function#850

Closed
jamiebresch wants to merge 1 commit intowrf-model:release-v4.1from
jamiebresch:alpha_be_vertloc
Closed

Fix DA default gen_be_vertloc function#850
jamiebresch wants to merge 1 commit intowrf-model:release-v4.1from
jamiebresch:alpha_be_vertloc

Conversation

@jamiebresch
Copy link
Contributor

@jamiebresch jamiebresch commented Apr 1, 2019

TYPE: enhancement

KEYWORDS: WRFDA_EnVar, gen_be_vertloc, alpha_vertloc

SOURCE: Jamie Bresch (NCAR)

DESCRIPTION OF CHANGES:
To change the default function in a stand-alone utility for generating
be.vertloc.dat, an input file required when alpha_vertloc=.true. and ensdim_alpha > 0.
Old default: kscale = 10.0 * real(k) * nk_inv
New default: kscale = 5.0 + real(nk)/real(k+3)
An example of log-P method (dependent on vertical level configuration) is also provided in the code.

The old default suppresses increments at low levels above surface where vertical correlation
exists in ensemble perturbations.

LIST OF MODIFIED FILES:
M var/gen_be/gen_be_vertloc.f90

TESTS CONDUCTED:
Month-long hourly cycling over CONUS domain to discover the problem in the original default gen_be_vertloc
and to test the impact of various alpha vertical localization settings.

RELEASE NOTE: For WRFDA EnVar applications, gen_be_vertloc is fixed to allow proper increments from ensemble contributions at low levels above surface. Users are encouraged to modify the empirical 5.0 + real(nk)/real(k+3) function in the code for their own model levels and ensemble configurations.

modified:   var/gen_be/gen_be_vertloc.f90
@jamiebresch
Copy link
Contributor Author

One example of u/v/t/rh vertical correlation of an 80-member ensemble perturbations.
ep_vert_corr_d01

@jamiebresch
Copy link
Contributor Author

Correlation of several vertical localization as specified in gen_be_vertloc.f90.

gen_be_vertloc

@jjguerrette
Copy link
Contributor

@jamiebresch this definitely looks like an improvement, but it seems like the vertical correlation length scale is too large relative to the 80-member ensemble. Are the choices of 5 and 3 in the parameterization taken from GSI? Or from literature? If not, then it seems to me there needs to be an adjustment still.

@jamiebresch
Copy link
Contributor Author

@jjguerrette
The vertical localization does not increase the correlation that does not
exist in the ensemble perturbations.

I don't know how Dale Barker (the original vertloc developer) decided the
model-level based (a), (b), (c) function and kept (a) as the default.
I made up the (d) relation and it is totally empirical.
The logP method is taken from GSI. The 0.388 shown is the plot is also
a user-defined value. It can also be level-dependent rather than one
value for all levels.

I did not intend to implement a comprehensive vertical localization for WRFDA.
The main purpose is to replace the very bad default and raise the awareness
that users should look at their ensembles and decide their localization scales.

@liujake
Copy link
Contributor

liujake commented Apr 3, 2019

@jamiebresch @davegill I am Ok to put this into V4.1 release repo for users' convenience, but think it is more appropriate to categorize this as 'enhancement' instead of 'bug-fix'.

@liujake
Copy link
Contributor

liujake commented Apr 3, 2019

@jamiebresch Can you also plot default localization function at each level before/after your change?

@jjguerrette
Copy link
Contributor

While the correlations will not be increased, making the localization length scale longer than the correlation length scale defeats the purpose of doing localization. The number of ensemble members required for convergence could actually increase.

@jamiebresch
Copy link
Contributor Author

@jjguerrette Yes, I agree with your comment.
When the ensemble size is large enough, the localization does not matter much.
I don't insist on the 5 and 3 values. The kscale relation should actually be user input values.

@jamiebresch
Copy link
Contributor Author

Red: kscale = 10.0 * real(k) * nk_inv
Blue: kscale = 5.0 + real(nk)/real(k+3)
vert_corr_levels

@jjguerrette
Copy link
Contributor

Sorry, I'm not completely right on this as the new localization clearly will remove some spurious correlations from a small ensemble. However, I'm wondering whether the localization is filtering out enough of those noisy correlations? For example, at a fixed number of ensembles (40? 80?), is there a degradation to the analysis when used in a forecast?

I'm fine with this change to go in, but it would be nice to have a more rigorous analysis.

@liujake
Copy link
Contributor

liujake commented Apr 3, 2019

From the localization functions before/after change, this is a quite significant change for levels below 30. This will likely substantially affect the results. I would suggest this not going into V4.1 or develop branch before we have more evidence it is really an improvement to the forecast results.

@jamiebresch jamiebresch closed this Apr 3, 2019
@jamiebresch jamiebresch deleted the alpha_be_vertloc branch April 3, 2019 23:19
@jjguerrette
Copy link
Contributor

@jamiebresch, have you had more experience with these vertical localization lengthscales since closing the PR? I wonder if the lengthscales need to be increased for all-sky radiance experiments. It is possible the vertical correlation of hydrometeors is getting truncated.

@jjguerrette
Copy link
Contributor

Please see attached my own vertical correlations analyzed from an 80 member ensemble over Eastern 2/3 of CONUS:
be_vert_corr

@jamiebresch
Copy link
Contributor Author

@jjguerrette I have finalized the proper formulation for a physically-based log-P method for vertical localization. Dale also agrees that the new plot looks more reasonable.
vert_corr_20190416

@jjguerrette
Copy link
Contributor

That does look very nice!

@liujake
Copy link
Contributor

liujake commented Jul 12, 2019

@jamiebresch You may reopen this PR to be merged in for this logP method if you like.

@jamiebresch
Copy link
Contributor Author

Will consider open a new PR in the future for a finalized better log-P implementation.

jjguerrette pushed a commit that referenced this pull request Aug 8, 2019
…loc info (#958)

TYPE: enhancement

KEYWORDS: WRFDA, alpha_vertloc, alpha_vertloc_opt

SOURCE: Jamie Bresch (NCAR/MMM)

DESCRIPTION OF CHANGES:

PR #850 discussed about the issues in current var/gen_be/gen_be_vertloc.f90.
Instead of modifying the stand-alone var/gen_be/gen_be_vertloc.f90 utility that generates be.vertloc.dat, this PR proposes a simpler and better solution inside WRFDA.

1. A new namelist alpha_vertloc_opt is added to replace alpha_vertloc to choose how to handle
vertical localization for EnVar applications.
alpha_vertloc_opt=1, the behavior is the same as before, except that the new code now gives proper error message when be.vertloc.dat does not exist.
alpha_vertloc_opt=2 (default, recommended), let WRFDA calculate logP-based vertical localization. be.vertloc.dat will be written out.
alpha_vertloc_opt = 0, no vertical localization.
alpha_vertloc_opt  is only used when ensdim_alpha>0, so the alpha_vertloc_opt setting does not matter when ensdim_alpha=0.
2. frame/module_configure.F is modified to notify users about the obsolete alpha_vertloc option.
3. var/README.namelist is updated.

LIST OF MODIFIED FILES:
M       Registry/registry.var
M       frame/module_configure.F
M       var/README.namelist
M       var/build/depend.txt
A       var/da/da_setup_structures/da_get_alpha_vertloc.inc
M       var/da/da_setup_structures/da_setup_be_nmm_regional.inc
M       var/da/da_setup_structures/da_setup_be_regional.inc
M       var/da/da_setup_structures/da_setup_structures.f90

TESTS CONDUCTED:
A case to test the new code works as expected.

RELEASE NOTE: For EnVar DA applications, logical alpha_vertloc namelist switch is replaced by new integer option alpha_vertloc_opt. See var/README.namelist.
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.

3 participants