Regional Reanalysis Questions and Answers
Partial Index
- tropopause definition
- winds are different from Eta/NAM/WRF
- where is the snowfall
- categorical rain doesn't agree with accumulations
- no assimilation of surface land temperatures
- surface drag, surface wind stress, Cd, friction velocity
- zero 30 m winds
- creation of land-water masks, and topography
- soil moisture output
Note: The answers to many questions can be found in Office Note 438,
the NCEP Eta Post Processor, which has many details about how many
items are defined in the model. You can access that document here.
How is the tropopause defined?
From Office Note 438: The post processor can generate the following
tropopause level fields: pressure, temperature (ambient and potential),
horizontal winds, and vertical wind shear. The greatest difficulty was
coding an algorithm to locate the tropopause above each mass point. The
procedure used in the Eta post processor is based on that in the NGM.
Above each mass point a surface-up search is made for the first
occurrence of three adjacent layers over which the lapse rate is less
than a critical lapse rate. In both the NGM and Eta model the critical
lapse rate is 2 K/km. The midpoint (in log pressure) of these two
layers is identified as the tropopause. A lower bound of 500 mb is
enforced on the tropopause pressure. If no two layer lapse rate
satisfies the above criteria the model top is designated the
tropopause. Very strong horizontal pressure gradients result from this
algorithm. Horizontal averaging over neighboring grid points prior to
or during the tropopause search might minimize this effect. To date,
this alternative has not been coded. It might be more accurate to
describe the current algorithm as one locating the lowest tropopause
fold above 500 mb.
Linear interpolation in log pressure from the model layers above and
below the tropopause provides the temperature. Recall that velocity
points are staggered with respect to mass points. Winds at the four
velocity points surrounding each mass point are averaged to provide a
mass point wind. These mass point winds are used in the vertical
interpolation to tropopause level. Vertical differencing between
horizontal wind field above and below the tropopause provides an
estimate of vertical wind shear at the tropopause.
Why do the wind fields seem incompatible with operational Eta/NAM/WRF winds?
RR winds are written so that they are earth-relative. That means that a vector
that is due east on the RR grid is due east on the earth. The operational
NCEP forecasts, all use grid-relative winds. For lat-lon and Gaussian grids, the grid-relative
and earth-relative winds are the same. But for the Lambert conformal and polar stereographic
grids, one needs a rotation to convert from grid-relative to earth relative. This can
cause problems as codes designed to read the operational grids usually apply a rotation
to convert the winds to earth relative. However, we felt that it would be easier to convert
the winds to earth relative rather than teach people to rotate the winds. BTW if
you would like to convert grid-relative winds to earth-relative,
use this code.
Why is the snowfall missing from the RR archive? How can I calculate
snowfall?
Unfortunately, there is no straightforward way to obtain the snowfall
from NARR output. Regretably, no procedures were instituted in NARR to
accumulate the precipitation into a separate field of snowfall when the
precipitation was deemed to be non-liquid. We are presently
investigating candidate procedures to accurately but indirectly infer
the accumulated snowfall from other NARR output fields, and we will
post a description of a suitable procedure if we can determine one. In
the meantime, we remind users that snowfall is not needed to compute
the land surface water budget, though it is needed to compute the water
budget of just the snowpack itself. Hence the water budget of the
snowpack itself cannot be analyzed from the NARR output at this time.
In this context, we warn users NOT to assume that the NARR 3-hour
forecast of snowpack state is an accumulated 3-hour snowfall (it is
not). To steer users clear of the latter erroneous assumption, we offer
the following specifics. The standard NARR output at each 3-hour
analysis time consists of the large "Merged A" file and the small
"Merged B" file. Both files contain a field named WEASD, which is the
instantaneous state of the water equivalent snowpack on the ground --
in units of millimeters, or equivalently Kg/m**2). In the Merged A
file, the WEASD field is the instantaneous snowpack state of the
ANALYSIS, at the analysis time (time of the filename). In the Merged B
file, the WEASD field is the instantaneous snowpack state of the 3-hour
FORECAST, valid 3-hours AFTER the analysis time (time of the filename).
For completeness here, we now explain the purpose of the WEASD forecast
field in the Merged B file. During any given 24-hour interval, the NARR
assimilation consists of eight analysis times. These eight analysis
times are linked by eight 3-hour forecasts. For example, the starting
point for the 03Z NARR analysis is the 3-hour NARR forecast from the
previous 00Z NARR analysis. (By "starting point" we mean the reference
or "background" field into which observations are assimilated.) In the
case of the snowpack state, of the eight analysis times per day, only
the 00Z analysis in NARR assimilates external snowpack information.
Hence only at the 00Z valid time is the analysis of the snowpack state
different from the 3-hour forecast of snowpack state from the previous
analysis time (in this case 21Z). At all other analysis times besides
00Z, the analysis of snowpack state is taken from (and thus is
identical to) the 3-hour forecast of snowpack state from the previous
analysis. The amount of the snowpack analysis increment at the 00Z
analysis time must be included in the land surface water budget. This
daily 00Z snowpack analysis increment is calculated by taking the 00Z
WEASD analysis of the Merged A file of 00Z and substracting from it the
3-hour WEASD forecast from the Merged B file of the prior 21Z. This
latter surface water budget application is the purpose of carrying the
3-hour WEASD forecast record in the Meged B file.
Why are sometimes the categorical precipitation flags set to
no precipitation when the accumulated precipitation is larger than 0?
RR includes flags that type the precipitation into liquid, snow,
ice pellets and freezing rain. It was noted that not all the
(0-3 hour) accumulated precipitation was typed. The problem is
that the flags are instantaneous and the precipitation is accumulated.
So some regions with accumulated precipitation will not have any
precipitation when the precipitation flags are set.
Why is the snowfall larger than the total precipitation at times?
The ETA code is structured in such a way that the accumulated
WEASD is offset by one physical time step. Consequently the snowfall
can exceed the total precipitation in some isolated areas. This is
a problem with the operational ETA model (6/2003).
Why does the RR not assimilate surface temperatures over land?
Land surface temperature observations cannot be assimilated
successfully in the 3DVAR scheme used for the regional reanalysis.
The background error contains implicit synoptic scale balance
information, but knows nothing about boundary layer dynamics.
Because of large diurnal variation of temperature over land,
which exists at any time of year, observation - background
residuals are regularly quite large. The balance relationship
in the 3DVAR erroneously connects these large surface residuals
to the wind field, which has a relatively large vertical correlation
length (around 250-300mb). As a result, the large surface residuals
have an undesirable impact on lower-tropospheric temperatures
and lower- to mid-tropospheric winds, instead of being limited to
the boundary layer. Newer versions of 3DVAR with more
sophisticated background error definition will eventually
eliminate this problem, but no mature version existed at the time the
reanalysis was started.
Why does one observe discontinuities in the precipitation field
occasionally on coastlines or near the Canadian border?
The analyzed precipitation used for precipitation assimilation comes
from four sources. Over the continental United States, the analysis comes
from a gage dataset and is analyzed onto a 1/8-degree grid using the
PRISM mountain mapper and a least-squares distance weighting scheme.
Over Mexico and Canada, the analysis comes from gage datasets analyzed onto
1-degree grids. Neither of those datasets has PRISM or a least-squares
weighting scheme. Over the rest of the domain, the CMAP dataset is used.
CMAP is a combination of gage and satellites, analyzed onto a 1-degree grid.
Despite an attempt at a smooth blending, we still see discontinuities
between the different datasets, especially around coastlines and borders
of countries.
Why does there appear to be a diurnal variation in snowcover?
It has been a well-known problem for several years or more, but less so in RR
than in current ops Eta, and much less so than before the major Eta/Noah
land-surface upgrade in July 2001. Specifically, going back to before July 2001,
about HALF of the magnitude of the fast snowmelt bias in the Eta was solved with
the major Eta/Noah land-surface upgrade in July 2001. Of the remaining bias,
about half of that was solved in the RR snow albedo and snow fraction upgrades
put into the RR shortly before the RR production phase. The remaining fast
snowmelt bias in the RR is due I feel to the high bias in solar insolation in the
Eta and RR. The Eta/RR has a high solar insolation bias because the Eta-RR solar
radiation fails to attenuate enough radiation through cloud cover -- a problem
quite substantial in the high cloudiness regime of winter season.
So, the Eta/RR has a widespread tendency to melt off snow cover too fast
during the day (not always, depends on air temperature and solar insolation), and
then the daily update of the snow cover from the external snow cover analysis
tends to put the snow cover back. Part of the problem also is the unreliability
of the snow cover product itself (from USAF), which can persist as unchanged snow
cover that is actually changing under obscuring cloud cover (because the visible
satellite imagery used by the USAF product cannot see the snow cover change if
obscuring cloud cover is present).
We worked hard to minimize the "saw-tooth" nature of this daily
melt/analysis-replacement tendency by replacing the direct insertion of the USAF
daily snowdepth analysis with a "poorman" assimilation, in which the model
background snowdepth state was not changed if it was a factor of two within the
daily ingested USAF snowdepth product.
Why does it appear that the coastline has shrinked when masked plots are produced?
The land/sea mask was defined over land and water, so you get a cleaner
representation. Items such as soil bottom temperature with masked
points over the water, has a shrinked land mass because Grads needs 4
points to surround a point to make it land.
Why is 2-m pressure sometimes higher than the surface pressure?
The 2-m pressure interpolated using nearest neighbor, while the surface
pressure uses bilinear interpolation. By the way, there is a surface
pressure interpolated using nearest neighbor as well.
Why does the climatological 2-m temperature and latent heat flux
over the Gulf of California seem to have discontinuties on the month
boundaries?
The sea-surface temperatures (SST) over the Gulf of California were
interpolated using an algorithm developed by David Stensrud. The value
of the SST is set to the mean surface value near Guaymas (Ripa and
Marionone, 1989, Quart. J. Roy. Meteor. Soc., 115, 887-913).
The problem is that there was a bug which set the daily SST value to
the climatological value from the first of the month. The routine is
meant to interpolate between the first of the month and the first of
the next month, but that interpolation was not done thanks to the bug,
making the SST from the last of the month to the first of the month
inconsistent with each other. This bug was corrected before the NARR
began 1 January 2004, but 1979-2003 was run with the bug in place.
(Where is/what is wrong) with the surface drag, Cd, wind stress, friction velocity?
We store data in GRIB as integers multiplied by a preset scaling factor.
This allows considerable control over the precision of the numbers and the
resulting size of the GRIB fiel. We spent considerable time modifying the precision
of the GRIB files in order to save disk space for the on-line archives as well as to
make sure the data had enough precision for most applications. However,
we goofed when it came to the surface stress/friction velocity/Cd.
For the surface CD, we didn't save the data with enough precision.
The surface stress was also not saved with enough precision and the stress
was removed from the data sent to NCDC and others. Our error makes
estimating the friction velocity more difficult.
Why are 30-m winds around coastlines sometimes exactly zero?
We have identified the problem to have been caused by a code error in
the following manner. 30 m winds were derived on the model's native
E-grid using the same algorithm as that used to obtain the 10 m winds
(wgrib abbreviations also UGRD, VGRD, merged files record #s 293, 294).
Both of these sets of winds are calculated by the Eta code at mass
points, using the algorithm based on mid-layer winds at the four
neighboring wind points.
If the Eta bottom layer depth is greater than 30 m, the 30 m winds thus
obtained are left as is. But if it is less, a linear vertical
interpolation in z is performed between the lowest layer wind, and the
wind of the layer above, to obtain the 30 m winds. In doing this, our
code erroneously was not interpolating the winds derived for the mass
point, but was doing the interpolation using values at a neighboring
wind point, the one to the east or to the west of the mass point.
Given that the lowest Eta layer of our RR code is thinner than 30 m,
this means that all our 30 m winds at Eta points with bottom elevation
at sea level are affected by the code error. But the error is minor, we
believe for most purposes negligible, if this neighboring wind point
carries a "live" wind, wind that is greater than zero. The error will
not be negligible if this wind is forced to be zero by blocking
resulting from one or more of the three neighboring topography points.
This will happen if one of these points has its ground topography
defined at the nearest interface above sea level, or still higher.
At some of these points with the lowest wind that is used for the
vertical interpolation blocked and equal to zero, also the wind above
will happen to be blocked and equal to zero. At these points, resulting
30 m wind will be zero also. Preferred places for this to happen are
coastlines with non-negligible topography.
The native grid winds are interpolated to the Lambert grid, used for
the "AWIPS" and also "merged" files. The 30 m wind interpolation being
nearest neighbor, some of these erroneous zeros will arrive to the
Lambert grid as zeros as well. Some might not be used and thus will not
affect the merged file values.
But note that some of the AWIPS grid values with 30 m winds different
from zero will be wrong too, if the lowest layer wind used for the
linear vertical interpolation was a blocked wind, and the wind above
not. These wrong winds will tend to be smaller in magnitude than they
ought to be.
Thus, 30 m winds over land points with topography - nearest neighbor
interpolated - above sea level are not affected by the error. But
points at sea level elevation might have 30 m winds wrong, either
zeros, or different from zero.
We are generating code to identify Lambert points with erroneous 30 m
winds, and will post the result on our web page. We are also generating
correct code to be used in R-CDAS. Finally, we will consider possible
remedial actions re NARR files we have.
Why are the units of fluxes, given by the Grib decoder I use, kg/m, and not kg/m/s?
What wgrib decoder, version v1.8.0.9f says (other decoders?), is that
eight various fields that are water vapor and condensate fluxes, have
units [kg/m]. This does not look right, because fluxes have units
[kg/m/s]. The reason for the discrepancy is that variables in these
fields are in fact not fluxes, transports (kg) across unit distance,
per second, but are transports in 3 hours. Note the "0-3hr acc" in
wgrib printout. Thus, the units kg/m are correct. At the time of this
writing, we are in the process of changing wgrib to refer to those
variables as transports, as opposed to fluxes.
As to the data prepared for Global Reanalysis, is the NARR using
the data files prepared for the NCEP/NCAR ("R1") or for the NCEP/DOE
("R2") reanalysis?
Neither one, strictly speaking. After R1 was completed, two
pre-processing errors were identified which afflicted the R1 datasets
post-1979. By that we mean the errors were made in converting original
sources (from NCAR for instance) into NCEP reanalysis formats (i.e.
PREPBUFR). The problems consisted of about 10 years of mis-located
PAOBs (Australian bogused sea level pressure data, SH only), and about
10 years when some mainly Scandinavian radiosonde stations were
systematically not included.
For the R2 reanalysis, the causes of these errors were corrected, and
the reanalysis formatted datasets were re-made from the same original
sources. Subsequently, it was found that supplemental sig-level winds
from some ECMWF decoded radiosondes which had been included in R1, Aug
1989 through Oct. 1991, were left out of the R2 data. These were added
to the R2 data for NARR data preparation.
How are the NARR topography and land/water masks created?
A: The NARR topography and land/water masks are created in the same way
as those of the then operational Eta model, following the procedure as
follows.
Each model grid box is split into 2 x 2 subboxes, and terrain elevation
read off terrain data (USGS 30 s data where available), collecting
values and percentages of water that happen to fall within each of the
subboxes. Using these, mean subbox elevation and percentage of water is
obtained. Subsequently, for each grid box, mean and silhouette
elevations are calculated. Silhouette elevation is calculated by
looking at each pair of subboxes as seen from two directions
perpendicular to sides of the box, amounting to four pairs total, each
time taking the higher value, and subsequently averaging these four
higher values.
Following this, nine-point Laplacian of the mean orography is
calculated for every box. Where the Laplacian is positive, mean is used
for the box elevation. Where it is negative, silhouette is used
(Mesinger, Bull. Amer. Meteor. Soc., 1996, p. 2646-2647).
Subsequently, an effort is made to minimize closing up of significant
valleys and mountain passes that may have happened within the
silhouette part of the so obtained topography. This is done by looking
for points for which in at least in one of the four possible directions
the average elevation of three nearest neighbors in that direction,
centered on the point considered, is less than both the average
elevation of the three nearest points on one side of these three
points, and also of the three nearest neighbors on the other side of
the three points. If so, irrespective of the sign of the Laplacian, the
mean elevation is used for that point. Points are declared water if
more than 50 percent of their area is covered by water according to the
topography data read.
This is followed by rounding off to reference interface elevation, and
elimination of "windless" points created as a result. Land points that
have winds at all four of their vertices blocked are raised as needed
to reach the lowest unblocked wind. Isolated water points, or water
points that have only one of their nearest neighbors water and are at
sea level, are also raised to reach the lowest wind, and are declared
land. Otherwise, land is removed at one of the water point's four
corners, to free one of the blocked winds. The corner chosen for land
removal is one that has the smallest three-point averaged elevation.
Elevation of water points above sea level is checked for presence of
neighboring water points with a different elevation, and, if so,
elevation of all neighboring water points is made equal.
Why does the change in precipitable water not exactly match the sum
of moisture convergence and evaporation, minus precipitation?
There are a number of reasons why this does not happen, why the "water
budget" cannot be "closed" using the terms mentioned above, and even
using all of the NARR fields available. The most obvious reason is the
"analysis increment", change in the total water of the atmospheric
column (precipitable water, PWAT) resulting form the 3D-Var analysis
step. Note that the analysis increment has been monitored and is
obtainable from NARR files, since both PWAT entering the 3D-Var at the
end of the 3 hr forecast, and PWAT out of the 3D-Var are available,
within fields of the merged files B and A, respectively.
Yet other budget terms that have been monitored and are available are
water vapor and water condensate increments (WVINC, WCINC) that are
made within the precipitation assimilation during the 3-h forecasts in
between the consecutive 3D-Var steps. Note that, for example, if the
precipitation analysis being assimilated at a grid point shows
precipitation, and the model at that location does not have enough
moisture for precipitation according to its precipitation schemes,
moisture is added to the model to achieve consistency (Lin et al. 1999).
Note also that moisture convergence in NARR consists of two fields,
water vapor flux convergence and water condensate flux convergence,
that need to be added to obtain the total moisture convergence.
But even if all of these NARR fields are accounted for the budget will
not exactly close for several reasons. One is the difference between
the local column moisture change resulting from the model's moisture
horizontal advection scheme, and the change that apparently should take
place due to the column̢۪s moisture flux convergence. Namely, the
model's moisture horizontal advection scheme (Janjic 1997) involves
non-local moisture adjustments aimed at achieving several objectives
(e.g., Mesinger and Jovic 2002, NCEP Office note 439, available online
at http://wwwt.emc.ncep.noaa.gov/officenotes). These adjustments
redistribute moisture horizontally. However, since conserving the total
moisture is one of the objectives pursued by these adjustments they
should not have much impact on area-averaged budget calculations. The
same kind of an impact has the horizontal diffusion of moisture.
Finally, interpolation from the model's native grid to the Lambert
output grid is yet another reason preventing the exact closure of the
budget. To reduce the contribution of this interpolation to the
resulting residual, moisture flux convergence has been carefully
calculated and vertically integrated on the model's native grid, and
only subsequently interpolated to the Lambert grid. Thus, users should
take care to use this NARR native grid calculated moisture flux
convergence (WVCONV, WCCONV), as opposed to calculating the moisture
flux convergence on the Lambert grid themselves using the interpolated
velocity and moisture fields, and thus needlessly introducing errors in
their budget calculations additional to those that cannot be avoided.
How many soil layers are there? At what part of the layers are the temperature and moisture valid?
All four NARR soil layers (0-10, 10-40, 40-100, 100-200 cm layer thicknesses) are available in the standard NARR output at NCDC. For each soil layer, three prognostic soil states are available in the records of the grib file: 1) soil temperature at the mid-point of the soil layer, 2) total soil moisture (sum of liquid plus frozen soil moisture), and 3) liquid soil moisture (that part of the total soil moisture that is not frozen). Substracting the amount of liquid soil moisture from the total soil moisture yields the amount of frozen soil moisture (soil ice content).
All three soil state variables above are considered valid at the mid-point of the soil layer. Units of soil temperature is Kelvin. Units of soil moisture is volumetric fraction (fraction of unit volume of soil that is occupied by soil moisture -- typical saturation value of volumetric soil moisture is 0.45, except for sandy soils the saturation value is more typically around 0.35). Super-cooled liquid water can and does easily exist in the soil state, so even at sub-freezing temperatures the NARR soil states contain some liquid soil moisture (water), but the amount of such liquid soil moisture relative to the total soil moisture decreases as the soil temperature falls further and further below the freezing point.