SUSPENDED
Due to low usage, these daily forecasts were discontinued on July 14 so the CPU time could be utilized for other RASP forecasts.
RASP Archive Viewer
displays RASP BLIPMAPs for the current and previous days (one time per day only)
Updates and user comments can be viewed at the
RASP Forum
How are RASP forecasts produced ?
RUC and ETA BLIPMAP forecasts are obtained by
post-processing forecast files output from NCEP prognostic models, so
horizontal and vertical resolutions are determined by those used in
those models. But here I am running a prognostic model myself,
so am able to specify the vertical/horizontal grid (though of course
subject to limits of practicality). A WRF (Weather Research and
Forecasting) model is being initialized and marched forward in time at
30 second time intervals to produce forecasts at 3 hr
increments. Initial and boundary conditions come from the
larger-scale models run by NCEP. To increase accuracy, forecasts are produced for both a
larger-domain coarse grid (12 km) and a smaller-domain fine grid (4
km) nested inside it, but only results for the latter are
displayed. BTW, the
data needed to make such runs is available globally, so in theory
such forecasts can be made for anywhere in the world !
Rationale and Accuracy
A higher resolution model is expected to better
predict those phenomenon which are "locally forced" and influenced by
terrain. But forecasts of higher accuracy than the RUC/ETA
BLIPMAPs are not guaranteed since: (1) all else is not equal, as the
RUC/ETA model uses different algorithms which might be more correct
than those used by the WRF, (2) the RUC/ETA models use a more refined
initialization procedure, and (3) any limited-area model is subject to
"boundary condition" errors, which for a large-area model such as
RUC/ETA are very far away and of little importance but here are much
closer and may have a significant influence. The question of
which model forecast is more accurate may depend upon what parameter
is being evaluated and can only be assessed through comparison to
actual conditions.
Of course one advantage of running a model is
that one has full control over it and can change its behavior.
The WRF has many, many parameters which can be adjusted. And one
of it's claims to fame is that is is modular, allowing use of
different routines, written by different people/groups, to make the
calculations which determine, say, cloud formation - so alternate
modules can be utilized to improve model accuracy. But on the
other hand one could spend a lifetime evaluating and changing things
to improve accuracy - this is what meteorologists at weather
prediction centers do, but I don't plan to do that myself!
BTW, the WRF model is considered to be the "model
of the future" for many operational weather predictions centers and is
a candidate to replace the ETA model at NCEP within the next few
years.
Notes and Caveats:
Timeliness Issues
The Future ?
() One is not supposed to believe all the details of these
forecasts, particularly since the small-scale structure is constantly
changing yet one a few snapshots at different times are shown.
Rather, one should be looking for patterns.
() Forecasts for points close to the boundary will be less
accurate than for those located nearer the center of the domain, due
to inevitable mis-matchings between the coarse and fine grids.
In particular, predictions of max/min BL vertical velocity are very
noisy and inaccurate near the boundary (particularly where boundary
condition problems exist). To remind users of this, a dotted
line marks the "frame" outside of which coarse-fine boundary
interaction problems are most prevalent.
() The "Explicit cloud water cloudbase" estimates are based on
cloud water predicted from model equations and problematical since there
is no simple criterion for differentiating "mist" concentrations from "cloud" concentrations.
The criterion presently used is a first guess.
() The "Cu Potential" and "Sfc. LCL" predictions are based on a simple formula which considers
only water vapor at the surface
() This model does not ingest as much observational data as do the institutional models
such as RUC and ETA, hence some effects are not included: for example, soil moisture
is neglected
() While many pilots are accustomed to using the 20km-RUC BL top
to estimate a maximum soaring height in terrain, that likely works
because 20km-RUC terrain heights are usually significantly lower than
actual ones. With better defined terrain on the 4 and 1 km
resolution grid, Hcrit is likely to become the more relevant
parameter. I suggest also looking at the BL depth and BL max/min
Upward Motion parameters as indicators for where maximum lift is
likely to occur.
() The present simulation is only a first cut, since to get
things running quickly many decisions have been on the basis of whatever
was easiest. Many choices must be re-examined in light
of experience gained with the present parameters. In particular,
I expect at some later time to alter the horizontal domain to reduce
some obvious boundary problems and to alter the vertical grid such
that a larger proportion of points occurs nearer the surface.
() The "Vert. Velocity at 500mb" and "Vert. Velocity Slice at
Vert.Vel.Max" parameters attempt to forecast mt. wave events, although
strong vertical velocities resulting from deep BL convergence can also
be found in the plots. The first parameter gives a plan view of
vertical velocity at the 500mb level, a height of roughly 18,000 ft MSL
and thus often above the BL top. The second parameter is a
vertical slice taken at a point of maximum vertical velocity (as found
within a horizontal box covering the middle third of the grid at a
height of around 5000 ft AGL) and oriented parallel to the wind at
that point, as indicated by a dotted line on the plot of the first
parameter (with left-right on the slice always being left-right on the
plan view). A label above the plots gives the location and
magnitude of the found maximum value. One key indicator of a
mt. wave is its upwind tilt with height, which should be evident in
the vertical slice. Finally, a third parameter "Vert. Velocity
at 700mb" also allows evaluating vertical motion lower in
the atmosphere, around 10,000 ft MSL.
For examples of mt. wave forecasts (though at 1km resolution), see these predictions
of vertical velocity
at 18,000 ft (500mb)
and
in a vertical slice.
The forecasts are not as timely as I would
like. In particular, it woulld be best for launching pilots to
have viewed forecasts initialized from the early morning sounding data
of that day since otherwise the models depend upon soundings taken the
previous evening and are thus less accurate. But at present the
1300 PST forecasts from that data would be not available until after
noon PDT, later than I would like, and so are not being
produced. The reason, of course, is that it takes time for
sounding data to be obtained and sent to NCEP, time for NCEP to
process it and run their model and produce output files, and time for
me to download those files and run my model and plot the output
produced. But since the RASP forecasts have not yet been shown to
be useful, for now I consider forecast timeliness a secondary
issue.
And a yet-to-be-resolved conundrum is that
several changes I would like to make to improve forecast accuracy
would also significantly increase the run time and hence make the
forecasts less timely. In particular, in the interest of
providing more timely forecasts I have used a larger time step than is
desirable, which decreases forecast accuracy. The crux of the
matter is that at present these forecasts are at the edge of what is
possible and practical - the good news is that as computer power
increases in the next years the timeliness and accuracy of the
forecasts will improve.
If these forecasts prove useful, I would plan to
make the code public so that others might produce high-resolution
soaring forecasts for their own local regions. Such a
"distributed computing" concept is much more practical than trying to
have a centralized computational effort (whereas the RUC/ETA BLIPMAP
processing is only practical when done centrally since for them the
very large "native grid" files must be downloaded, vice the much
smaller files tha RASP downloads). What is required is a DSL
connection, a reasonably powerful Linux computer, and time and energy
and commitment. The forecast images could be uploaded to either
a club's webpages or to a special section of the DrJack website for
viewing by others.
However, I will be spending much time simply
creating the system and can't afford to spend additional time
shepherding people through the somewhat involved build procedure - so
people would have understand that the code comes with no support from
me other than to fix something that is found to be broken. My
present thought is that I would work with some volunteer to build a
forecast for his location and in the process create detailed
instructions describing the process. There would also be the
understanding that he would assist at least one other person with the same
process, who would in turn make the same commitment to assist one
other person, etc. - in this way the knowledge and work required could be
spread over many. Such users could also interact and help each
other using the RASP forum. But those are only my present
thoughts and the time for such an endeavor has not yet arrived.
