Table of Contents

• Unidata's Path to Platform Independence
• Get Connected! Achieving vIDD, the Next-Generation IDD
• NIDS via IDD
• McIDAS and Sponsored Participation: Using Unidata Software in a Private Secondary School
• COMET Case Studies on the WWW
• What's Up with Weather
• Comings and Goings
• Issues in Data Usage

Unidata's Path to Platform Independence

by Dave Fulker, Unidata Program Director

We recently submitted a proposal to NSF for continuing Unidata through the year 2003. Attempting to look that far ahead was both challenging and exciting, and I am indebted to the Unidata Policy, Users, and Advanced Technical Advisory Committees for their critically helpful roles in laying out our future course. Please find the proposal here and give me any feedback you wish to provide on how well it reflects your own view of how Unidata should evolve (link no longer available).

By far the most profound aspect of the proposal is our plan to change the basis for defining which platforms (i.e., which computers and operating systems) are the targets of Unidata development and support efforts. Specifically, we are planning a transition toward Java-based computing. Looking back, issues concerning operating system support have been with us since Unidata's inception. Most recently, platform issues surfaced in the form of questions about Unidata's future roles vis-à-vis the Linux and OS/2 operating systems.

A Brief Platform Support History

Unidata's founders included proponents of several operating systems, but the primary debate surrounded Unix. Some argued that Unix represented the future and offered a high degree of hardware independence; others argued that a significantly larger community of colleges and universities could participate in a Unidata that supported computing under DOS (the IBM PC operating system); still others noted that Digital Equipment's VMS, not Unix, had already been adopted in several of the nation's most prominent meteorology departments. Another aspect of the debate was a more fundamental question: Could Unidata software be sufficiently portable to run on most or all operating systems?

Several working groups wrestled with these matters, and I would summarize their conclusions (c. 1985) as follows:

• Some aspects of the Unidata system concept, especially those pertaining to real-time data management, were too complex to realize in a fully portable manner. Nonetheless, Unidata should strive for portability in all system components where it is practical.
• Unidata should provide and support software for DOS, VMS, and a few variants of Unix, recognizing that the DOS-based capabilities would be less comprehensive than those for Unix and VMS.

Early Unidata software suites reflected these principles by offering exactly one package, PC-McIDAS, for DOS users, and several systems, including the Local Data Manager (LDM), for VMS and Unix users. See Resolution 8510.4 in the log of Policy Committee resolutions for more information on this position.

In 1989 a panel of reviewers -- convened by NSF to consider a Unidata proposal -- recommended dropping support for VMS, as an economy measure, and the Policy Committee concurred (see Resolution 9003.2). Soon thereafter, the Policy Committee recommended sunsetting DOS in favor of OS/2 (Resolution 9006.4). This step was informed by and consistent with the plans of McIDAS developers at the University of Wisconsin in Madison, where steps were already being taken to shift McIDAS toward OS/2 and Unix, exclusively. Of course, these Unidata decisions caused considerable pain for users, who had difficulty making the corresponding changes at their universities, but the net effect has been to increase the capabilities of all Unidata participants by focusing more resources on development and less on software compatibility issues.

Recently users have asked Unidata to consider supporting additional systems, including Windows 95, Windows NT, and Linux. Because others develop our display and analysis software (McIDAS by SSEC; GEMPAK by NCEP; WXP by Purdue), adapting any of them to run on an entirely different operating system (Windows 95 or NT, for example) would be difficult without the developer's consent and assistance. Linux presents fewer difficulties because it is a variant of Unix, and all Unidata software already runs on several flavors of Unix. Other arguments for Linux have included:

1. Linux runs on inexpensive hardware, including 386, 486, and Pentium PCs;
2. Linux is "freeware"; and
3. several Unidata packages have already been ported by community members to Linux platforms.

These are strong arguments; indeed, our own recent efforts to adapt and test Unidata software under Linux were quite successful, and the results are now available to users. (Be aware that Linux seems to require more system savvy than some departments may have available.) However, we believe we can better serve the community by focusing on the more general goal of platform independence (for the reasons discussed below) rather than further dividing our resources by adopting an explicit policy of Linux support. Fortunately, this decision will eventually lead to Linux compatibility, because the Java virtual machine will be a part of future Linux releases.

Costs of Multiple-Platform Support

Unidata support encompasses a broader range of platforms than do many commercial systems of lesser complexity. Specifically, users can employ various mixes of Unidata software to perform a range of data-acquisition (in real time), storage, interactive analysis, and display functions on the following platforms:

• AIX (on IBM RS/6000 workstations)
• IRIX (on Silicon Graphics workstations)
• HP-UX (on Hewlett Packard workstations)
• Linux (on 386+ PC-compatibles)
• OS/2 (on 386+ PC-compatibles)
• OSF/1, also known as Digital Unix (on Digital Equipment workstations)
• SunOS (on Sun Sparcstations)
• Solaris (on Sun Sparcstations)
• ULTRIX (on Digital Equipment workstations)

Our netCDF software runs on an even longer list of systems, including WIN32 (for PCs with Windows variants) and UNICOS (for Crays).

As you might guess, Unidata staff direct a large proportion of their time toward maintaining, testing, and debugging software in all these environments, especially when new versions of Unidata packages are released or when vendors provide new versions of their operating systems. And yet, even with the amount of effort we direct toward multiple platforms, the only Unidata software usable on the highly popular Microsoft Windows platforms is netCDF. The Policy Committee identified this as a vulnerability and noted that our support for PC -compatible platforms relies heavily on IBM's OS/2, an operating system that is in stiff competition with several Microsoft products and whose future therefore has a degree of uncertainty.

As hinted previously, a number of users think that OS/2 should be eliminated and replaced by Linux in our future support plans. Others have suggested replacing OS/2 with Windows NT or Windows 95. The Users and Policy Committees have debated the relative strengths and weaknesses of each of these strategies.

• The Linux approach is easiest for Unidata staff to implement because the porting is nearly complete, and similarities to Unix reduce maintenance problems by some degree. However, many of our OS/2 users chose that platform because the associated system-administration tasks require less time and expertise than they do under Linux.
• The Windows strategy probably would have the most salutary effect on our existing OS/2 user community, but the associated problems of porting Unidata software would be immense, especially because the authors of GEMPAK, McIDAS, and WXP apparently have no plans or resources for doing so.
• Opinions diverge immensely on the future of OS/2.

Platform Independence via Java

As I mentioned at the beginning of this article, a fundamental question at Unidata's founding was whether Unidata software could be sufficiently portable to run on most or all operating systems. Until now, the answer has been substantially negative, although we have succeeded in employing a single source code (through auto-configuration) for each package that runs on variants of Unix. Recently, however, a small revolution in computing has begun as a result of Java, a computing and programming environment which promises an unprecedented level of platform independence. In our view, Java represents the first opportunity to meet the complex needs of Unidata users in a truly platform-independent fashion. Realizing it is a major under-taking, the Users and Policy Committees have scrutinized this objective. In respect to concerns raised about OS/2, it is noteworthy that IBM appears to have an especially strong commitment to Java, and one result is that Java programs perform remarkably well under OS/2.

However, incorporating Java into Unidata's future is based on more than needs for platform independence and concerns about Windows and OS/2. By planning a transition to Java we anticipate gaining a number of benefits.

Vendor Support: Vendor endorsement of Java is widespread, and it already can be used under Microsoft's Windows 95 and Windows NT, IBM's OS/2 and MVS, Apple's MacOS, and many Unix operating systems, including those provided by Digital Equipment, Hewlett Packard, IBM, Silicon Graphics, and Sun. As noted previously, Linux support for Java is also being developed.

Inexpensive Computers: Java is especially well suited for the so -called network computers (NCs) and other very low cost systems which may be of increasing interest to Unidata colleges and universities, perhaps for labs or other settings where large numbers of workstations are needed.

Low System Maintenance: A frequently reported difficulty for Unidata sites is the lack of adequate resources (time and expertise) to perform routine system administration functions, such as incorporating bug fixes and keeping software at the current revision level. The Java computing environment offers the potential for secure, fully automatic downloading and dynamic linking of individual software components at run time. With this and other Java features, we may eventually be able to lower the administrative costs of running Unidata software.

Object Orientation: Java will help Unidata utilize object-oriented software design and development methods. Because of their ages, the packages in the present suite of Unidata software are based primarily on older methodologies, so this change represents an opportunity for modernization, including better user interfaces and higher levels of interactivity. Of course there are many object-oriented languages -- such as C++ -- that Unidata could choose for such modernization, but Java is viewed by experts as having an especially clean and powerful "object model." Proper use of classes, inheritance, interfaces, threads, and other fundamental notions realized in Java should foster good designs and simple implementations.

Programming Productivity: The Java environment has features to enhance the productivity of software engineers. The Java language is simple and portable. Java is multi-threaded to ease the handling of concurrent tasks; it is strongly typed to eliminate undetected type-matching errors; it allows no pointer arithmetic and performs array-bounds checking to prevent memory corruption and pointer-manipulation errors. Java automatically allocates and frees memory (with garbage collection) to prevent memory "leaks." Libraries already are or soon will be available for effective graphical user interfaces (GUIs), I/O, networking, animation, image manipulation, threads, graphics, secure transactions, and many other purposes.

Network Orientation: The success and importance of the Internet Data Distribution (IDD) system illustrates the benefits that can be derived from distributed computing, especially in the type of "virtual community" that Unidata represents. Java's built-in support for object serialization and remote method invocation (RMI) facilitate effective use of distributed computing. Among other benefits, these features will help us meet our goal (articulated in the five-year proposal) of treating the aggregated data holdings of Unidata participants as a community-wide resource. Indeed, some of the most exciting elements of Unidata's future depend on a technology model that is consistent with Sun Microsystem's maxim that "the network is the computer."

Transition to Java, with Continuity

The nature of Unidata's transition to Java was the major topic of the May Policy Committee meeting, with particular attention on how this transition would affect current OS/2 users. The committee adopted a set of principles to guide the transition:

• The Unidata Program's long-term goal is platform independence.
• The target architecture is the Java virtual machine.
• The language of choice for new implementation is Java.
• The Unidata Program Center's roles are three:
• Developing and supporting data-management (i.e., system-level) software;
• Collaboratively developing and supporting user-level software; and
• Providing infrastructure (tools) for software development.

Additional guidance was contained in a Policy Committee resolution directed toward the Unidata Program Center (UPC):

"The Policy Committee requests the UPC develop a transition plan from OS/2 and Unix to a system involving a Java-based client-server implementation. The transition should include the following steps:

• Development of a Java-based "image viewer" client that would serve as the GUI
• Adaptation of OS/2 and Unix applications to function as servers to the image-viewer client

Functions should be added to the client-side Java application as quickly as practical, eventually allowing it to replace platform-dependent systems. The transition plan will be developed by the UPC and discussed by the Users Committee, ATAC, and the Policy Committee; it will include a time line and a resource-allocation table. The plan should include support for OS/2 and Unix users until the capability of the Java application addresses most user needs."

I am pleased to accept this guidance and am optimistic that our Java strategy will benefit Unidata and its user community. In particular, this strategy requires no users to depart from OS/2, because the Java support is excellent in that environment. However, I wish to warn you that our new direction may affect the level of service you receive, even though I am committed to the Policy Committee's recommendation on providing continuity of capabilities. Specifically, staff efforts must be directed toward learning about Java and building new software, and this necessarily will reduce our level of effort in other areas. Your comments and questions are most welcome and may be sent directly to me via e-mail.

Get Connected! Achieving vIDD, the Next-Generation IDD

by Ben Domenico, Unidata Program Manager

Want more data? How about satellite images at higher resolution? NEXRAD data? Forecast model output? What about the full NOAAport at your fingertips? Then connecting to NSF's new experimental network may be just for you.

In 1993 NSF decided to create a very high speed Backbone Network Service (vBNS) to connect its supercomputing centers at projected speeds of up to 2.5 gigabits (2.5 billion bits) per second, fast enough, according to MCI (NSF's chosen network provider), "to transmit the contents of two public libraries per second." (Speeds have not yet reached projected levels: the vBNS backbone is currently running at 622MBps, with UCAR's connection to the vBNS at 155MBps.)

As conceived, the network was to support only scientific research requiring high-performance networking, but last year participation was expanded to support broader needs of researchers in the US academic community. As part of this expansion, NSF started its "Connections to the Internet" program, one component of which seeks to provide high -performance connections for research and education.

We believe that the vBNS infra-structure will soon provide the bandwidth needed to carry the expanded data that our users want, and we would like to see as many IDD sites as possible with vBNS connections. NSF has accepted my proposal to use vBNS to test the IDD system under conditions where speed is not a constraint; the proposal requested no additional funds.

Creating a very high speed IDD (vIDD) will enable the UPC to:

• reconfigure the current IDD to provide more reliable relay service;
• test the LDM in a high-speed, high-bandwidth environment; and
• deliver more data to sites connected to the vBNS.

The NSF Directorate for Computer and Information Sciences and Engineering (CISE) is offering two-year seed-money grants to get institutions connected. Proposals will be evaluated in part on how well the campus network infra -structure would support the high speeds. It should come as no surprise that your campus network may need to be upgraded before you can connect to the vBNS; it would be of little use to have a 145 MBps connection to the vBNS if the data are going to hit a 10 MBps Ethernet bottleneck when they get on campus. You will also need to have a strategic plan to show how the university will continue the service after the two-year seed grant runs out.

So far, 64 sites have been awarded vBNS connectivity, roughly half of which are Unidata sites. To date, only UCAR, Cornell, and Penn State have IDD computers connected to the vBNS.

We would like you to get connected. Knowing how long proposals can take, we encourage you to talk with your campus network administrators to see whether they are looking into the vBNS opportunity. And if your campus is applying for a Connections grant, you may want the proposal to mention the fact that it would enable your department to participate in the vIDD experiment.

The NSF CISE grant announcement and the Unidata proposal for vIDD are also available on the Web.

To further encourage you to move toward vBNS, this year's Unidata equipment-grants-program announcement noted that applying for funds to take advantage of vBNS will position sites to make good use of the equipment grants. We expect that NSF will continue to assign special consideration for this activity in future Unidata equipment-grants programs.

NIDS via IDD

by Harry Edmon, University of Washington

For the past five months the University of Washington (UW) has been routinely sending compressed Level II NEXRAD data from the Seattle Weather Service Office (WSO) at Sand Point to the UW Department of Atmospheric Sciences via the IDD.

The Level II data are taken from the radar via a Sun workstation and placed on a private network in the Seattle office via equipment installed and maintained by the National Severe Storms Laboratory (NSSL). A UW owned and operated Sun takes the Level II data off of this network and, using a locally written decoder and the LDM, sends the data via the Internet to the UW.

The Seattle WSO shares a T-1 line with the Western Region Headquarters, so using a small amount of bandwidth is critical. A raw Level II volume is 9.8 Mb and new volumes are sent every six minutes. To reduce the load on the network, each volume is separated into 44 chunks with each chunk containing 100 radials of the image. Before transmitting each chunk, the ingestor compresses it, so that the total size of all 44 chunks taken together is only 0.5 to 1.5 Mb. A decoder at UW reassembles the volume scan in the same format as NEXRAD Level II tapes. Volumes can then be ingested into processing and display software packages such as Zebra.

The main problems this system presented were figuring out how to use the NSSL software to ingest the grids and getting the compression and decoding software to work reliably. We also had problems initially with the data flow to the NSSL Sun being shut off after radar maintenance, but this problem cleared up without any action on our part. We have been pleasantly surprised at how well the volumes compress and by how well the LDM handles this relatively large data set.

The reliability of transmitting the data via the IDD is excellent, and the latencies are very small. We would be willing to help anyone else who obtains a Level II data feed and is interested in transmitting the data in this manner. Contact Harry Edmon for further details.

McIDAS and Sponsored Participation: Using Unidata Software in a Private Secondary School

by Jonathan R. Bernon, The Taft School

In July 1994, I was in Kansas City for a conference and remembered that the National Severe Storms Forecast Center (NSSFC) was nearby. In high school I had been fascinated by the weather and had volunteered at the National Weather Service Office in Warwick, Rhode Island, during my junior and senior years. So I showed up at the NSSFC office, explaining to the folks there that I was a math teacher in an independent school and that I loved weather. A very kind gentleman gave me a tour, answering my questions and letting me observe as severe-thunderstorm and tornado watches were issued. I was amazed by the high-tech equipment some screens with constantly looping radar and satellite pictures, others with textual data scrolling by. My guide encouraged me to use my interest in weather to bring meteorology to life in my classroom. I left with the dream of creating a weather course at my school involving equipment similar to what I had seen at the NSSFC. Today, thanks to a tremendous amount of help from the Unidata community, The Taft School offers a course in atmospheric science supported by first-rate equipment, software, and real -time data.

My Dream Takes Shape

The road to achieving my dream was not direct. First, I needed to learn meteorology. I taught myself by reading books, visiting the National Weather Service (NWS) in Taunton, Massachusetts, and by browsing the World Wide Web. At Purdue University, I found some great Web pages depicting data graphically with explanations of how to read the maps.

My next step, was to serve as the faculty advisor of one student's independent study course in atmospheric science during the spring term in 1995; we both learned as we went along. (The following semester I team-taught the course as a regular 11th- and 12th-grade science elective.)

As my understanding grew, so did my quest for timely data. I had became dissatisfied with the images on the Web they took too long to download and there were too few focused on the northeastern United States. I wanted weather data in real time.

For my third step, I called Unidata, which I had learned about via a link from Purdue's Web site. As luck would have it, Unidata had recently created the Sponsored Participation category by which institutions that are not colleges or universities (and hence do not qualify for full membership) may use the infrastructure of Unidata to gain access to meteorological data.

Pulling the Pieces Together

Dave Fulker, Unidata's Director, explained to me that, under Sponsored Participation, I could get all of the FOS (Family of Services) data for free, if I found a university or college to sponsor Taft. Paul Gluhosky in the Department of Geology and Geophysics at neighboring Yale University was willing to get me started, and his department's chair, Ronald Smith, formally agreed to sponsor Taft. Although Paul had only limited time to help me, he set up his machine to provide me with data and answered my questions as time permitted.

There remained the problem of software. I wanted McIDAS because it runs on a PC, but I faced licensing issues (sponsored participation does not include free access to software). McIDAS is owned by the University of Wisconsin Space Science and Engineering Center (SSEC). Sandra Nilsson, Unidata's Program Administrator, contacted SSEC and eventually the legal agreements between SSEC and Unidata were amended to allow Unidata universities to distribute McIDAS free of charge to K-12 institutions. This process took several months, so it was fortunate that I got the ball rolling well ahead of the time that I wished to be up and running.

Don Murray, who is in charge of McIDAS OS/2 development at Unidata, helped me select a computer. When I was ready to buy, prices had come down so far that we were able to purchase a Gateway 2000 200-Mhz Pentium Pro system with 32 MB of RAM, a 4-MB graphics card, a 2-GB hard disk, a 17 -inch color monitor, and 3-year on-site service, all for under $3500. (When buying computer hardware and software, always ask for the educational rate; the extended warranty is also a good idea, especially since the machine will be running constantly.) Don had told me to buy the fastest machine, most memory, and largest hard disk that our budget allowed. That was sound advice since Taft only has one machine running McIDAS, it must both ingest and display data at the same time, so speed and storage capacity are important.

In August 1996, my Gateway 2000 machine and OS/2 software came in, and our T-1 line was up and running, so I used FTP to download McIDAS from Yale's computer. Nothing worked. In downloading McIDAS, I had forgotten to change the setting for file transfers from ASCII to binary; in addition, my graphics card did not come with the driver for OS/2! Fortunately, I found the driver on the Internet. (Don had warned me to make sure that all the parts of my system were OS/2 compatible; while Gateway had said the pieces were compatible, the computer did not ship with all the drivers.) One of the faculty at Taft who had experience with PCs and the Internet helped me with this process; it helps a lot to have someone on staff who knows OS/2 or who just knows a lot about computers. If you are inexperienced like me, you will definitely need some help setting up your machine.

When the machine was running and the software loaded, I ran the installation program, following the instructions provided on Don's Unidata Web page. The instructions are excellent, but when viewed on my web browser, some of the command lines in the instructions wrapped onto a second line. Being unfamiliar with McIDAS, I didn't know the proper syntax and didn't recognize when lines were incorrectly truncated. My suggestion to other newcomers therefore is to familiarize yourself with the syntax.

Up and Running, Sort of

Once installed, McIDAS worked well, and most of what I wanted was accessible through the built-in menus. As time went by, however, I found that I wanted to customize the application for my students, so I went to a McIDAS training course at Unidata in the fall of 1996. (As a sponsored participant you are entitled to attend the free workshops at the Unidata Program Center [UPC] in Boulder, Colorado, provided there is space available.)

During my time at the UPC, Don Murray and Tom Yoksas spent considerable time helping me learn the basics. They were extremely patient; I would have driven anyone else completely crazy! The material is overwhelming and can be frustrating to learn, but the results are incredible. Because of my teaching schedule, I was only able to stay two and a half days instead of the full week. I wanted to stay the whole week McIDAS is easy to use from the menu, but when you get familiar with the command -line mode, you can produce very sophisticated displays.

Consistent delivery of data turned out to be a problem. I received my data from Yale, so when Yale went down or had trouble with its feed, I was without data. Sometimes this was frequent, and if Paul was out of town, I wouldn't have a feed for days. I started looking for a backup site, and Mitch Baltuch, who configures the Unidata IDD system, suggested I talk to SUNY-Albany and Plymouth State. David Knight from SUNY and Jim Koermer from Plymouth State both agreed to be backup data sites for me. I am very grateful to them and have had to use Albany on many occasions.

Weather in the Classroom

At first, I set up the machine in my office while I experimented with the basics. Then I moved it to the computer lab so students could use it. The machine is dedicated to weather-related uses, and two distinct groups of students now use the system: the 20+ members of the meteorology club and the students in my atmospheric science class.

Before my system was set up, the meteorology club relied on textual data obtained at first through CompuServe, then from Gopher, and later Web images obtained via a dial-up connection. The club now uses the Unidata system to create forecasts a couple of times a day. Since Taft is 80% boarding students, the weather machine gets used seven days a week, at various times from 6:45 A.M. to 10:00 P.M. Students find the menu-driven system easy to use. They look at surface data and satellite pictures, as well as textual data from the NWS. I have customized the command that allows access to the latter, so students can quickly view items such as MRF output for Connecticut. As their knowledge grows, I'm sure their use of McIDAS will increase.

I am now about half way through my second atmospheric science class, and the system has made an enormous difference. We've covered upper-air soundings, skew-T diagrams, and streamline plots, which they found particularly "cool." As we get into more advanced topics, such as upper-air maps and computer-model output, I'll be using even more McIDAS capabilities. My course runs one semester, though it could easily be taught over a full year. We use Meteorology Today by Ahrens as the text.

While at the UPC for training, I learned about access to lightning data; Ronald Henderson from SUNY-Albany, who controls the access to the National Lightning Detection Network data, was kind enough to provide a feed to Taft. The students love overlaying lightning data on satellite pictures and looping the images.

Kids learn best when they are interested in the subject matter, and technology is used best when it enhances teaching and learning in ways that are not possible through other means. The Unidata system fits this scenario perfectly. McIDAS allows my students to learn about the weather as it is happening, which they really enjoy. While it's possible to obtain products like satellite pictures over the Web, the weather machine allows students to do more. They can, for example, quickly loop satellite images and overlay other data. The system's power and ease of use is wonderful.

I'm very pleased with the Unidata setup at Taft. The power of this system as an educational tool easily justifies both its initial costs and its operating costs. And getting real-time data helps to justify the large investment now being made by more and more secondary school sin high-speed Internet connections. For Unidata to be used more widely at the secondary-school level, however, more universities and colleges will need to donate resources (bandwidth) and time as my experience shows, getting started is not easy. But the reward for those institutions that participated would be a growing pool of high school graduates with interest in and some knowledge about atmospheric science.

I am grateful to all the people who made it possible for Taft to become the first secondary school to have direct access to the Unidata data stream and McIDAS through Unidata's sponsored participation program.

COMET Case Studies on the WWW

by Ethan Davis, Unidata Program Center, Julie Adolphson, COMET/NWS, and Linda Miller, Unidata Program Center

The COMET case-study library is being made available to the entire meteorological community through the WWW-based CODIAC data-management system. Each COMET case study is a collection of meteorological data sets covering a specific interesting event. The COMET case-study library is a well -rounded resource that contains a variety of meteorologically significant case studies useful for training and research.

This collaborative project between UCAR's COMET, JOSS, and Unidata programs is funded by the National Weather Service (NWS) to support the NWS Science Operations Officers (SOOs) on-station training-and-research program during this era of diminishing resources. The much improved access to and ease of use of the case-study data sets allows the SOOs to collaborate with the academic community using the same software and data sets.

The case studies include WSR-88D radar, GOES-8 or -9 satellite data, NCEP model data, NWS Family of Services (FOS) text data, and upper-air and profiler data. Some of the cases also contain data sets that were contributed by users. For example, surface mesonet data, isentropic gridded model data, and mesoscale-model output have been contributed by universities in three of the existing on-line cases. We are very interested in obtaining additional data and encourage you to contribute data that would make for richer case studies.

Currently Available

Please take a moment to check the case studies that we have made available through the CODIAC system. Currently, the following three COMET case studies can be searched, browsed, and downloaded through the Web:

• COMET Case Study 004, Bow Echo, 5 May 1996
• COMET Case Study 005, Lake Effect Snow, 4-5 January 1995
• COMET Case Study 007, High Plains Snow, 13-14 March 1996

At present, seven COMET case studies, including the three listed above, can be ordered for delivery on 8-mm tape through the Web. These seven cases contain meteorological events dating back to 1993.

More Information

For a more detailed explanation of this project and direct access to the CODIAC system, see our Web page, which includes a "What's New" section.

Stay Informed

To stay informed of the latest developments on the COMET case-study project, please subscribe to our casestudies mailing list. To subscribe, see the instructions on the Web or we'll be happy to add you to the email list. Just send a request to Ethan Davis or Linda Miller.

Suggestions

We are always interested in suggestions on how to make the case-study data easier for users to access and how to make the case studies more useful for the users. If you have any suggestions, including what cases you would like to see available, send e-mail to support@unidata.ucar.edu . We are currently working on a short user survey in which we will ask for more specific input.

We look forward to hearing from you!

What's Up with WEATHER

by Peter Neilley, NCAR

WEATHER is software that is designed to provide access to the Family of Services data. It provides a simple, uniform interface to nearly all of the types of data used in standard meteorology labs. WEATHER was contributed to the Unidata community and is currently being used by about 35 universities and government labs and 15 commercial sites around the world. It is free to nonprofit education and research institutions.

What WEATHER Does

WEATHER is designed to access textual weather products efficiently in terms of both user time and computer resources. Using one simple command syntax to access all types of weather data, WEATHER outputs both raw and decoded data (such as METARs, synoptic data, ship reports, buoy data, soundings, and profiler data). It can also read and interpolate model gridded data files to generate customized messages.

WEATHER is also flexible. It supports data access by state, station ID, city name, user-defined alias, WMO header, or any combination thereof, and the data can be searched and filtered in numerous ways. For example, you could request METARs that are reporting heavy snow or all severe -weather reports that mention tornadoes. Output is also flexible: in the METAR example, you would have complete control over the parameters, units, and format of the decoded METAR data. Output can be sent to printers, files, and the terminal.

Finally, WEATHER is easily extensible: new data forms can be accessed, often without adding any code or recompiling.

What WEATHER Doesn't Do

WEATHER is strictly a terminal, or shell-level, program. It does not generate graphical output, although many sites use WEATHER as the front-end search engine for graphics-generating programs. Some sites have developed X Windows-based interfaces to WEATHER, but these are not yet distributed or supported.

Recent WEATHER Changes

Most of the changes incorporated in the past year have focused on improving the ease with which WEATHER can be customized and ported. Configuration files now give users considerable control over the format, parameters, and units that are output from METAR and gridded data sets. The ability to access reports by city name has been added and the online help has been improved. WEATHER is also migrating from a source-code to a binary distribution to help make it easier to maintain.

WEATHER Forecast

WEATHER for Linux is now available and a version for AIX machines may be available soon. A Web interface for WEATHER is also being developed using JavaScript. Some sites already have CGI-based WEATHER interfaces [see sidebar].

Trying WEATHER

The official WEATHER User's Guide is available (link no longer available). This site also includes a link that creates a telnet session to a free account that lets you try WEATHER and links for downloading the current version.

The current version of WEATHER is 4.7. It may be obtained here from the Web site mentioned above. It is also available (source-code version only) from the Unidata anonymous FTP server in the pub/weather directory. WEATHER is known to work under SunOS, Solaris, HP-UX, IRIX, and Ultrix.

WEATHER is contributed software: it is made available through, but not supported by, the Unidata Program Center. Support for WEATHER is community-based and provided via the e-mail list weatherbud@unidata.ucar.edu.

Classes on the installation and use of WEATHER have been given during the Unidata package classes in the past and may be repeated this fall if there is enough interest.

Comings and Goings

Unidata has experienced several staffing changes since the last issue of the Newsletter. In the front office we welcome Donna West, who joined the staff as an administrative assistant in April. In recent years, Donna was employed by Unidata-member Dalhousie University in Nova Scotia, where she worked first in the Employment Equity Office (Canada's version of affirmative action) and then in the Office of the Dean of Faculty of Health Professions.

Donna first visited Boulder in the 1970s, giving performances of gagaku and bugaku (Japanese imperial court music and dance) in Denver and at the University of Colorado at Boulder. Returning to Boulder 20 years later, she was again involved in the arts, this time as Associate Director of the Colorado Dance Festival. Her time with the Festival included the unique opportunity to coordinate a Boulder tour stop by the great Mikhail Baryshnikov.

These days, Donna nourishes her artistic temperament through the practice of ikebana, the art of Japanese flower arranging.

Donna replaces Heather Gallien, who left Unidata in February to take a position in marketing, which was her college major. We wish her well in this new endeavor.

Temporary employee Jan Dillon helped with the front office workload between Heather's departure and Donna's arrival, and has stayed on to assist with the arrangements for the Unidata/COMET summer workshop. Her hard work has been appreciated.

Student assistant Jennifer Philion has also moved on. Jen was a journalism major at CU-Boulder with the goal of becoming a sportswriter; in her position at Unidata, she learned about the World Wide Web and how to write HTML. Her goals and work experience melded beautifully to land her a job with the Web edition of The Sporting News. Jen did a lot to improve the Unidata Web site and she was always fun to have around the office. We wish her lots of success in the future.

Issues in Data Usage

Giving Credit to NOAA

In these days of shrinking Federal budgets, including that for the National Weather Service (NWS), we would like to encourage Unidata sites to publicly credit NOAA and the weather service for the data received through Unidata. This credit should appear wherever the data is used, from Web pages to products conveyed via mailing lists to research papers. Many Unidata sites credit Unidata; while we appreciate being credited for the software we support, the data we distribute are generated by NOAA and it may help if this were acknowledged whenever those data are used.

Remailing Data

For those of you who make data available to users or groups who are not members of the Unidata community, please remember that these data are subject to NWS and World Meteorological Organization restrictions. Data remailed to others or made freely available via FTP should be labeled as being restricted to education and research use only. For further information, see the "General Guidelines for Using Data Acquired through Unidata".