1. Summary of project objectives and description of project participants
The project tasks could be divided into four categories in order to facilitate discussion. These tasks are
1. Automation of data access and graphics generation.
2. Preparation of a web page to facilitated wide and easy access to the model
data.
3. Repackaging of information that had already been available to the NWS.
4. Development of new model output products.
The UCD staff felt that the first 3 items were of highest priority. Due in part to issues outside our control, it took far longer than anticipated to complete the first 3 tasks. Accordingly, only one new item was created (maps of actual model topography). We conclude that at least a tripling of the support would likely have resulting in a much more useful product for the NWS. As it was, the UCD PI doubled the support by drawing from outside resources to accomplish the many tasks we completed.
Some details:
Task 1
Web pages presenting MAS model output for California and enlarged regions were to be created. (The prior output was graciously provided through the efforts of Dr. Jinwon Kim at LLNL. That output consisted of black and white vector graphics. While appreciated by the NWS, those graphics did not show the details present in the model output and were hard to interpret. Also, these files were difficult to access (the UCD PI never had access). And, the UCD PI understood that the ability to run the MAS model at LLNL was in danger of being discontinued.) To solve this problem the UCD staff had to implement a variety of automated procedures to obtain MAS model output and generate graphics files. The staff also had to design and implement Fortran programs and Unix scripts for this purpose from scratch. This work is "hidden" from the user; it nonetheless takes much skill and time. We were eventually able to successfully complete this task #1.
Task 2
Available products were to be displayed in an attractive format that allowed easy grasp of the "larger picture" in terms of a time and space sequence. The web pages were also designed from scratch. The UCD staff entered the project with a working knowledge of HTML, including forms and tables. Nonetheless, it takes time to decide upon a pleasing and attractive format. After several prototypes, in consultation with the person in charge of running the MAS model, we chose a "matrix" format over thumbnails. We also implemented short "GIF movies" to animate the data sequences. We consider the current format to be a success, though the addition of more data products may require a reworking of the welcome page. So, we feel that this task #2 was successfully completed.
Task 3
We implemented these products: surface temperature and 4 types of precipitation: total, liquid, frozen, and convective. The UCD PI understands that most or all of these products may have been available before. So, this task #3 was also successful.
Task 4
Additional products were to be prepared as time permitted. These included corresponding maps of the topography used by the model, to facilitate interpretation of the diagrams. Also proposed were: (a) a forecast meteogram for a grid point near Sacramento, (b) wind vectors (or streamlines) at or near a bottom level in the model and (c) displays of a measure(s) of current and past model performance. Of these, only the model topography field was completed. While it would be easy to implement the wind presentation, the UCD staff needed to work on other tasks (as mandated by the support funds being tapped). We recommend that such additional items be funded by a future partners or other COMET project. Understandably, the NWS is disappointed in this result, but the reality is that the funds did not match the scope of the project.
Personnel included:
Student Cris Castello developed the procedures and code (HTML & UNIX) to
display the MAS model products on the web pages. Prof. R. Grotjahn, who supervised
Mr. Castello on a daily basis, provided computer resources (gratis) for this
project, and provided additional funds to support the student beyond that provided
by COMET. Mr. Scott Cunningham, who provided feedback regarding the utility
of various formats and data choices for display on the web.
2. Description of research/development accomplishments
An initial web site has been prepared having these features:
A. Showing the region of interest and enlargements of two subregions
B. Has web pages for topography, surface temperature, and 4 types of precipitation
C. Choices of all images available are displayed in a matrix (HTML table) format
D. Color shading to facilitate visualizing the fields shown
E. Using contrasting colors
F. Using a white line to denote the location of freezing temperatures
Illustrations of the web pages using a test dataset from the MAS model are best seen by proceeding to the MAS model forecasts welcome page at this URL: http://www-atm.ucdavis.edu/~mascast/masmain.html
Of the additional items proposed, we only had time to prepare topography figures.
1.3. Publications
The primary product is the web site. The URL is: http://www-atm.ucdavis.edu/~mascast/masmain.html
If another project were funded as a continuation of this one, it would be desirable to document the procedures that we followed in a report or conference presentation.
2. SUMMARY OF UNIVERSITY/NWS EXCHANGES
2.1 Related work by the University
An (unpaid) undergraduate student intern tried to redo calculations that were made several years ago in a Sacramento NWS office report. The calculations were composites of various data fields (primarily seal level pressure and geopotential heights) for several types of significant weather events in Sacramento. (Examples include instances of heavy rain, strong winds, persistent fog, etc.) The stated goals were to improve upon the (of necessity) low quality graphics of the original document and possibly extend the work.
2.2. Related work by the NWS:
The NWS Sacramento SOO has served as a resource for the University by providing information and guidance for this project. He has sent 4 email messages with questions and suggestions for improving the web site. We also had one meeting.
The NWS Sacramento SOO also contributed to regularly scheduled courses. He gave a lecture in course ATM 30 during January 1998 on radar usage. He also led a tour of the local WSR-88D (near Dixon, CA) during November 1998.
3. SUMMARY OF BENEFITS AND PROBLEMS ENCOUNTERED
3.1 Benefits to University
a. We have a better understanding of the needs of NWS forecasters. For example, it is useful to them to see the amount and distribution of precipitation in various categories (such as: frozen vs. liquid, convective or not). See the web page for current examples.
b. It has provided a way for us to develop a working relationship with the local office. This led to the student intern described in answer to question #2, above.
c. The forecasting course taught at UCD has improved by knowing a bit more about the practical aspects of NWS local operations and needs.
3.2 Benefits to the NWS
This project is producing the infrastructure that will enable experimental model output to be easily accessed by the forecaster. This process will be documented so that other model output can be similarly distributed and displayed.
In response to a request by the UCD PI, the NWS partner provided the answers
(in capitals) listed below:
1. Has ease of access improved?
a. Using the web ----------------------------> YES
b. Seeing a "matrix" of the plots -------------> YES
c. Speed of access --------------------------> YES
2. Has ease of interpretation improved? Due to:
a. Color shading -----------------------------> YES
b. Grouping of plots -------------------------> YES
c. Other issues...? ---------------------------> ZOOMED VIEWS OF NRN &
SRN CA ARE QUITE USEFUL
3. Do the current product meet, miss, or exceed what the project promised? ----------------> MEETS
While the last question is gratifying to UCD staff, please note other comments in section 3.4 below. The local NWS office has added a link on its web page to the web pages we created in this project.
3.3. Problems encountered on the University side and their resolution
a. The project was to display products from a mesoscale forecast model. Running the model is outside the scope of this project. Other individuals have been developing a procedure to run that model here at UC Davis. Resolutions: (a) Since we did not have operational output from that model, we developed our web pages using output from a case study.
b. Operational implementation of our plotting procedures depended upon the work schedule of an individual not listed here, who was charged with setting up an operational version of the MAS model. It was not until October 1998 that the model was being operationally run at UC Davis. Resolutions: Initially, individual .GIF images were accessible via anonymous ftp. The files could be accessed directly from a web browser by entering the ftp URL.
Once there one would find numerous files with unique names that identify the field, domain, initial time of the forecast, and verifying time. One could quickly view each image by "clicking" on the file name. Alternatively, one could ftp individual files to one's machine and view them that way.
The ftp process was much less convenient for the user than our web pages, because the filenames are tedious to decipher and because the web page reveals the time sequence of events at a glance.
In late October 1998, the web pages were implemented for operational runs, which finally realized our original goal of providing MAS model output to forecasters (and the general public) in a greatly more convenient format.
c. There were administrative hang-ups in obtaining the funds at UC Davis that the PI did not discover until the spring of 1998. Resolution: We proceeded as if the funds would finally reach the department level (so the student could begin performing the tasks.) Most of the funds finally arrived much later in the year, requiring complicated bookkeeping.
d. The available funds did not cover the expenses needed to complete the project satisfactorily. An excellent student was assigned this project and produced a very useful and attractive product. But, the student worked on this project for many more hours than the budget from COMET was able to cover. (Approximately twice the number of hours budgeted.) Resolutions: (a) The extra time was covered by other funding sources so that COMET would be able to see clearly that major goals of the project were met. (b) We had to scale back the products that we would post on the web pages, so that the products we did post would be more useful. See sections 1.1 and 1.2
3.4. Problems encountered on the NWS side and their resolution
Below are listed comments received by UCD staff from the NWS (our responses
in parentheses)
a. Successful model run completion seems to be inconsistent. This has made getting
the forecasters to look at the data difficult as the big selling point has been
that it is a mesoscale model run out to 72 hours - quite rare! (This turned
out to be a problem of expectations. Due to limited computing resources, the
MAS model takes 12+ hours to run so that all the images would not be updated
until 1 PM. However, there was a miscommunication about this fact. The NWS thought
the model was 'crashing' because images would be updated sequentially. When
NWS personnel would check in the morning, the images up to 54 hours, say, would
be updated, but not longer because the model would still be generating the forecast.
The UCD staff are unsure how to resolve this, other than the header at the top
of the MAS model web page which states: Each 72 hour forecast begins around
11:45pm PST and completes around 1:30pm PST. The images update as the forecast
progresses so the forecast cycle for the later images may differ from that for
the earlier ones. Animations only show completed forecast times for the most
recent forecast cycle. )
b. With the above in mind, there needs to be a status displayed on the main page which will indicate to the user how complete the current model run is. (The status is NOT displayed as an automatically updated script, but as the static statements reproduced above. Like all the suggestions, this is a useful one, but we could not implement it due to limited resources of the project.)
c. Individual graphics should have the forecast (e.g., '24H', '60H' displayed on them somewhere). This was part of the miscommunication mentioned under item a. Each image has a description of the product displayed, the ending time of the image and the forecast starting time. Also, each image is accessible from a matrix that has informative labels, as suggested by the NWS. While the information is also on each plot, forecasters can compare different models more easily using elapsed time measured from initialization time. This problem is made more acute by the long time the model needs to run. i.e. recognizing that output first seen in the afternoon is a 30-hr forecast and not a 6-hr forecast.)