Parameter  [info]	CURRENT 4km FORECAST
Sfc. Temperature (F)	1000 PST	1300 PST	1600 PST
Sfc. Sun (W/m2)	1000 PST	1300 PST	1600 PST
Sfc. Heat Flux (W/m2)	1000 PST	1300 PST	1600 PST
BL Depth (ft)	1000 PST	1300 PST	1600 PST
BL Top (ft)	1000 PST	1300 PST	1600 PST
Height of Critcal Updraft Strength (ft)	1000 PST	1300 PST	1600 PST
Thermal Updraft Velocity (W*) (ft/min)	1000 PST	1300 PST	1600 PST
Buoyancy/Shear Ratio	1000 PST	1300 PST	1600 PST
Sfc. Wind (kt)	1000 PST	1300 PST	1600 PST
BL Wind (kt)	1000 PST	1300 PST	1600 PST
BL max/min Upward Motion (cm/s)	1000 PST	1300 PST	1600 PST
BL max Relative Humidity (%)	1000 PST	1300 PST	1600 PST
Cu Potential (ft)	1000 PST	1300 PST	1600 PST
Cu Cloudbase (Sfc.LCL) (MSL ft)	1000 PST	1300 PST	1600 PST
Explicit Cloud Water Cloudbase (AGL ft)	1000 PST	1300 PST	1600 PST
Vertical Velocity at 700mb (cm/s)	1000 PST	1300 PST	1600 PST
Vertical Velocity at 500mb (cm/s)	1000 PST	1300 PST	1600 PST
Vert.Velocity Slice at Vert.Vel.Max (cm/s)	1000 PST	1300 PST	1600 PST
Model Topography	12 km Domain	4 km Domain

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, in this case from the ETA model.  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.  After the prededing forecasts are complete, the model is re-initialized from the 1000 PST 4km forecasts and a 4km/1.3km nested-grid forecast run for 3 hours to produce a 1300 PST 1km forecast.  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!  TW, 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: 
()  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 fact that these forecasts are only a snapshot in time of a fairly noisy field should be particularly emphasized for the 1 km resolution forecasts, as forecasts for, say, 30 minutes before or after 1300 PST would look different.  At this point it's difficult to figure whether they will really add anything, but one never knows til one tries. 
()  The "Vert. Velocity at 850mb" 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 850mb level, a height of roughly 5000 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 750mb" has been added to evaluate vertical motion even higher in the atmosphere, around 10,000 ft MSL. 
()  Because the intrinsic short-term time variability of the atmosphere at scales as small as 1 km makes evaluations based on a single-time forecast uncertain, I have added loops of parameter forcasts for times near 1300 PST to aid assessment of short-term forecast variations with time.  A limitation of the present implementaion is that colors can represent slightly different values at different times, but the relative maxima are readily apparent. 

Timeliness Issues  
      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 are not available until after 8 AM PST (which will be 9 in the summer), later than I would like. 
      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.  NCEP model output becomes available a bit over 2 hours after sounding release time and downloading takes around 10 mins - I have no control over things up to that point.  My model run time depends on many factors, notably the speed of the computer CPU and the size of the domain modelled.  At present the run time is around 2 hours to produce forecasts at 1300 PST plus another 5 minutes for plotting.  This is slower than it might be because I have chosen to produce forecasts for two different locations instead of just a single one, which increases the run time by about 50%, and because the computer I am using (2.4Ghz dual Xeon) is not the fastest available.  On a faster computer running only a single location the 1300 PST forecasts could be made available around 40-60 minutes earlier.  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.

The Future ? 
     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 two others with the same process, who would in turn make the same commitment to assist two others, 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.