Table of Contents

• Moving Deliberately to Platform Independence: Unidata Goals in the Face of Budget Realities
• Jumping into Java
• Farewell, FOS; Hello, NOAAport
• UNIX Comes to Metro State
• The Sun is Setting on OS/2
• PAGE: Refining Community Issues
• Unidata Does DODS
• WXP Version 5.0
• New Staff at Unidata
• COMET Case Studies and Beyond
• Supported Platforms for Unidata Packages

Moving Deliberately to Platform Independence: Unidata Goals in the Face of Budget Realities

by David Fulker, Director, Unidata Program Center

In 1997 Unidata submitted a proposal to the National Science Foundation for continuing the Unidata Program another five years. The proposal, titled Unidata 2003, set an ambitious course and included initiatives for: extending the content and enhancing the performance of the Internet Data Distribution (IDD) system; providing an advanced (3-D) visualization package; and transitioning to all-Java software, thus reducing or eliminating the need for hardware- and vendor-specific versions of Unidata software.

This spring an NSF-convened review panel gave the proposal excellent ratings and made several useful suggestions. However, budget realities at the NSF required us to reexamine our plans and determine how we would shape our efforts if funded at about two-thirds the level originally proposed. (This goal was a bit daunting, because the target fell below our operating budget for last year.)

This summer, with guidance from the Unidata Policy Committee, we sent the NSF a letter responding to reviewers’ suggestions and revising the proposal to show how we would proceed at the reduced funding level. More specifically, we defined a "baseline" effort, minimally adequate for the viability of Unidata, considering the needs of the present user community. Activities originally proposed but falling outside of the baseline were reframed into a collection of "Advancement Projects" that can be undertaken as funds permit.

Since some goals "near and dear to Unidata hearts" (as one Policy Committee member put it) are now likely to be reached only with supplemental funding, I wish to describe here our priorities and the underlying rationale.

User Support

Helping people use Unidata systems remains a top priority, and our staffing levels for user support will be unchanged. Of course individual staff members’ responsibilities will shift as we sunset OS/2, provide support for Linux, and shift to Java, but we remain committed to fulfilling user needs for consultation and assistance.

Data Access

Another top priority is to shift our data sourcing from the Family of Services to NOAAport, the data distribution system now being deployed by the National Weather Service as part of AWIPS (the Advanced Weather Information Processing System). Our intention is to give users uninterrupted data access and simultaneously to gain large cost reductions. As described in a separate article by Joanne Graham, we are taking this step in collaboration with Alden.

Several other data-access enhancements now take the form of Advancement Projects, including efforts to utilize EOS data, to enhance the IDD for disseminating high-resolution data from NWS 88D radars, and to address community needs for historical data (as suggested by reviewers).

Moving to Java

The most profound aspect of the Unidata 2003 proposal is the direction we set toward utilizing Java in future Unidata software. (An article on this appeared in the Summer 1997 newsletter.) This is especially challenging to accomplish within the baseline effort, but I believe it is essential to our future and may eventually yield economies, if the promise of platform independence is fully realized.

Thus our baseline effort includes a transition to Java software, but the pace is slower than originally proposed. More specifically, our Local Data Manager (LDM) software will not be ported to Java–unless the associated Advancement Project is funded–because we will focus most of our Java work on interactive meteorological applications and on the netCDF software. Our transition to Java and the new MetApps Task Force are discussed in the article by Charlie Murphy and Russ Rew.

Community Building

Our community building effort is the area affected most by the reduced baseline budget. For example, we will not have booths at the annual AMS or AGU meetings, and we will not reach out to non-US universities in WMO Region 4. Also, you may have noticed that our Web site is in need of maintenance. Rather than replacing our Web master (Matt Hicks left Unidata for a career advancement), we are hoping to simplify our server structure, working with a private contractor to do so.

Conclusion

Though defining a baseline effort under these circumstances was challenging, I am immensely grateful to the NSF, and especially to Cliff Jacobs and other members of the Atmospheric Science Division, for the ongoing Unidata support. Of course I am hopeful that at least one or two of the Advancement Projects will be funded, but I am committed to advancing the state of data access and use in our community, even if baseline funding is all that’s available.

Jumping into Java

by Charles Murphy, Kean University and Russ Rew, Unidata Program Center

Some time ago, Unidata began investigating the potential of a new programming language called Java. The promise of Java is that it allows building software applications that are independent of particular operating systems. In theory, a Java-application runs on a PC, a UNIX platform, or even a Macintosh–any machine that has Java installed–without having to change the application. Staff members at Unidata spend a considerable amount of time testing Unidata-supported systems on various platforms. At the time of Java’s announcement, we supported two separate McIDAS packages for two separate operating systems (OS/2 and UNIX). Even our UNIX software poses platform problems since not all flavors of UNIX are alike. UNIX applications have to be tweaked to run on Solaris, HPUX, IRIX, AIX, etc. To Unidata, the appeal of platform independence was immediate and compelling.

Unidata’s Java plans have some non-technical aspects. Much of the display and analysis software Unidata currently supports was designed and developed outside the Unidata Program Center. The generosity of the authors in making this software available has yielded important economies as well as direct forms of community involvement in Unidata. However, unlike the situation when Unidata was formed, it is now practical for Unidata to design and develop a greater fraction of the display and analysis software needed in the community.

The resulting software would be designed specifically for the Unidata community, and would be maintained and enhanced under Unidata control. However, Unidata would continue to employ community expertise and make use of appropriate software from external sources. For example, the collaboration now underway between Unidata and the Java VisAD development team, led by Bill Hibbard, at the University of Wisconsin-Madison, is providing benefits to both groups.

Finally, and perhaps most importantly, Java offers compelling technical benefits. Java is an object-oriented language. While this has many technical ramifications, for Unidata users it means that an application can be built to be easily adapted to changing requirements. Furthermore, Java allows the creation of small software components. Instead of a single, monolithic application with a variety of capabilities, the capabilities can be offered independently. Capabilities never used, never have to be installed.

In planning for Unidata’s proposal to NSF for five more years of funding, the staff decided, and the Unidata Policy Committee concurred, that creating new applications in the Java language would be a high priority. The long-term objectives of this effort are to:

Develop and distribute applications that provide most of the capabilities used by Unidata members in familiar packages (McIDAS, GEMPAK, and WXP) as well as some new capabilities;

Create a component-oriented framework that supports easy construction of custom applications; and

Maintain, support, and enhance this new software, eventually to have it supplant other applications.

We had originally hoped to accomplish much of this within the five-year proposal period. The realities of funding from the National Science Foundation (see Dave’s article elsewhere in this issue), however, mean that this will be a slower process than we’d hoped. Nonetheless, the transition to Java remains Unidata’s highest development priority. (Continuing to support existing packages is equally important.)

The MetApps Task Force

To ensure that the new applications are, indeed, what the Unidata community wants and needs, the Unidata Users Committee has established an ad hoc group: the Meteorological Applications (MetApps) Task Force. Unidata plans to proceed with developing the Java capabilities incrementally. At each step, the tool will be tested then sent back for revision and/or enhancement. The role of MetApps is to assist in this process. The task force is helping define user requirements and will test prototype Java applications. It also has the broader responsibility of developing a blueprint or vision of what analysis applications for the atmospheric sciences should look like 10 years down the road.

The task force is chaired by Charlie Murphy and its members are:

• Pete Boysen (Iowa State)
• Elen Cutrin (Western Michigan University)
• Harry Edmon (U. Washington)
• Jim Koermer (Plymouth State)
• Jeff Masters (U. Michigan)
• Michael Morgan (U. Wisconsin)
• Larry Oolman (U. Wyoming)
• Paul Sirvatka (College of DuPage)

The task force had its initial meeting last July, to meet each other, to meet with Unidata staff, and to discuss and set procedures for its involvement in the testing. More specifically, the task force

• Reviewed the concept of "use cases" as a method of specifying software requirements. (A use case is a detailed description of the steps a user needs to take to reach a specified goal.)
• Discussed the platform issues related to testing Java prototypes.
• Agreed on communications structures: between themselves, between the task force and the Unidata staff, and between the task force and the Unidata community. (The task force and the Users Committee will need input from the wide circle of Unidata users as testing progresses.)
• To begin thinking about its charge to create a "blueprint for next-generation applications for the atmospheric sciences."

Task force members and UPC staff settled on two initial prototype applications: an interactive skew-T and a program to plot surface data. Task force members agreed to write use cases for these, and did. The first prototypes are now being tested.

Over the next few months, the skew-T and surface-data plotter will be tested and refined; the task force will create more use cases (each member will create use cases of his/her choosing). While the task force does not plan to meet again, it will be working in virtual mode, using e-mail to continue producing use cases and discussing members’ visions for the next generation of tools.

Farewell, FOS; Hello, NOAAport

by Joanne Graham, Unidata Program Center

In January of 1999, Unidata, in collaboration with the University of Wisconsin Space Science and Engineering Center (SSEC) and Alden Electronics, will take a big leap forward as it turns off its connection to the Family of Services (FOS) data stream, and begins using NOAAport data in its place.

There has been a lot of discussion in the past about moving the community toward the use of NOAAport, but we never expected it to happen this fast. When we were scrutinizing and paring our five-year plans, it became apparent that living within our means would require finding new ways to get the job done. We also realized that without special funding, moving to the NOAAport era would be impossible, unless we began to think creatively. Last summer, Dave Fulker began doing just that.

A New Approach

Canceling our FOS contract would save Unidata almost $110K annually, but there could be no disruption of service–we needed to get data to our community. Knowing that Alden Electronics, our FOS provider, had an interest in both serving the university community and getting into the NOAAport business, Dave gave Jimmie Smith a call. What has evolved is a Memorandum of Understanding (MOU) among Unidata, Alden, and SSEC that puts five NOAAport systems into commission at no out-of-pocket cost to the Unidata program.

The essence of the MOU is that SSEC, Alden, an Alden customer, and two Unidata university sites will operate NOAAport downlinks. These downlink sites will be responsible for feeding NOAAport data to others. Each of these top-tier nodes will listen to at least one other downlink site; in case of failure at the primary site, the LDM will automatically fail-over to the second site, which should still be receiving data. Below this top tier, the IDD should look essentially as it does today.

Alden Electronics is paying for the NOAAport hardware and software. SSEC is responsible for the software used to ingest NOAAport signals into an LDM-compatible server. And Unidata is responsible for all issues surrounding the LDM software, including training and consultation for the five downlink sites. We’re also taking on the project management issues, such as testing, comparing the data streams (FOS and NOAAport), and scheduling. Each node will have the ongoing responsibility of ensuring that its downlink is operational and properly maintained.

Making the Transition to NOAAport

We are working to get two university sites up and running as NOAAport downlinks (we’ll announce who these sites are once everything is official). We will have three feeds to the IDD in January: one at Alden, one at SSEC, and one coming from Unidata. (While Unidata did not purchase a NOAAport system, we were given permission to split the signal from an AWIPS system in COMET to feed the IDD. This will add an additional level of redundancy to this system on an ongoing basis.) We hope to have the other three sites operational by the end of January.

Unidata has been receiving NOAAport data over the IDD for several months, and we have passed those data to a few universities for testing. The feedback we’ve received assures us that this transition will cause very little, if any, pain to our users. Barring any unforeseen disaster, we will turn off FOS in January. If this transition requires you to make some modifications at your site, we will announce it before we go "live."

If you experience difficulty during this transition, you should contact support.

Wrap-up

We are excited about the opportunities provided with NOAAport. We will begin by receiving only the NWSTG/NCEP channel (which currently includes all of the data normally included in the Family of Services stream). As we gain more experience with NOAAport, we hope to add new data streams, and possibly new channels, to the mix in the future.

We hope that this transition will be easy for all of you. If you have any general questions (of a non-technical nature) about this project, I’d like to hear from you. You can contact me via telephone at (303) 497-8651. Again, questions of a technical nature should be directed to support. Thank you all for your support and patience as we move together toward new and exciting opportunities.

UNIX Comes to Metro State

by Sally Bates, Unidata Program Center

Late last spring, Anthony Rockwood, Professor of Meteorology, saw the handwriting on the wall, took a deep breath, called Unidata’s Don Murray, and committed himself to converting his program’s PCs from the OS/2 operating system to UNIX. "It is a big step," Tony admitted. "UNIX is not a turnkey system, and it’s more complicated than OS/2. But it’s also much more powerful. I don’t regret jumping into this for a moment."

The Years in the Data Desert

For many years, Rockwood’s institution (Metropolitan State College of Denver) had little in the way of computers or real-time weather data. He started with an old NAFAX system that provided him with crude weather maps on expensive thermal paper. To augment this, Tony would occasionally tape satellite loops from TV weathercasts to show his students ("You have to show the atmosphere in motion somehow," he remarks, "and this was the only thing I could think of.") In the early ’80s NAFAX and thermal paper maps were replaced by DIFAX and maps printed on a dot-matrix printer. These were higher quality and lower maintenance systems, but the need for satellite imagery was still a problem. Finally, through an NSF grant, he received enough money to buy a dedicated satellite-image-receiving system from Alden Electronics. "We were really excited by the prospect of receiving satellite images, but the system never really worked very well. It was a C-band satellite system, and there is so much terrestrial interference in downtown Denver that we could never get images reliably." Then he remembered Unidata.

While a graduate student in Atmospheric Science at Colorado State University in the mid ’70s, Rockwood saw an early version of mainframe McIDAS. On completing his graduate studies, he worked at NCAR for a few years, but ultimately ended up as a full-time faculty member at MSCD. His connections to NCAR and to the Boulder research community, however, evolved into a part-time faculty research position with the Weather Research Program at NOAA’s Forecast Systems Lab. Sometime in 1987 or 1988, while at FSL, he remembers seeing a demonstration of Unidata PC-McIDAS, but, like the earlier mainframe application, it was command-line driven and seemed too difficult to be useful. After the fiasco with the Alden system, however, he was desperate. By then Unidata McIDAS had evolved from DOS to OS/2 and had gained a menu system. In 1994, with McIDAS on a 90-MHz PC with 16-MB RAM, a Ku-band receiver (which was much less susceptible to terrestrial interference), and the Unidata McIDAS broadcast data stream, Rockwood finally had the real-time data, including satellite images, that he needed for his classes.

Learning and Loving OS/2

Rockwood had had no previous experience with OS/2 when he signed on with Unidata. He remembers that it took him about a year and several Unidata Workshops to become comfortable with installations, network configuration, and setting up NFS (network file system) connections. He never felt fully comfortable with OS/2 and, as is the case at most institutions, there was no campus support for OS/2. As a result he relied heavily on Unidata support (Don Murray and Tom Yoksas) to help with everything from hardware selection, to software installs and configuration, upgrades, and the seemingly endless task of system maintenance. When he wanted to add a CD-ROM or configure a display monitor, for example, he turned to Unidata; Don Murray helped him find and install the necessary OS/2 drivers. The access to real-time weather data, however, transformed his teaching. He soon moved from the satellite data stream to the IDD with his original equipment (the 90-MHz PC), then added a 133-MHz system with 32-MB RAM in 1996. This allowed him to run McIDAS XCD and receive text products for the first time. In 1997 he added a 100-MHz laptop, and in 1998 a 200-MHz Pentium Pro system with 64-MB of RAM. Each time he added a new PC, it would become the data ingester/server, and the older system moved to a client used for analysis and display. By last summer his meteorology lab included an OS/2 computer network of one ingester/server and three client PCs, Alden’s DIFAX service, plus NIDS products from the Denver radar through a cost-free arrangement with Alden.

The laptop has been particularly useful. Rockwood teaches 12 hours each semester. His courses cover the gamut, from introductory survey courses to synoptic and dynamic meteorology and forecasting labs. The classroom and lab are connected and share the same network. Using NFS, Rockwood is able to use McIDAS products, satellite imagery, and Web products in the classroom. "I would be lost without it [the laptop]," he laughs. "I once thought it had been stolen and I absolutely panicked."

Moving to UNIX

Unidata’s message to the community last spring about the pending sunset of support for OS/2 by SSEC jolted Rockwood into action. Despite his comfort with OS/2, he realized that the sooner he made the transition to UNIX, the better. Rockwood is also a member of the Unidata Users Committee, where he represents that portion of the community that is heavily dependent on Unidata’s OS/2 applications. He felt he could better represent this group if he experienced the transition himself, so the decision was made to make the move. After discussions with Don Murray, he opted for Solaris x86, primarily because others on his campus used Solaris and because it came bundled with MOTIF, which is needed for building GEMPAK. "We elected to begin by installing Solaris on my ingest machine only; the other machines are still running OS/2," he noted. With MSCD less than an hour’s drive from Unidata headquarters, Murray came down to Denver and performed the installation with Rockwood watching every move. By the end of the day, Solaris was installed and configured, and the ingest machine was running the LDM, McIDAS-X, and GEMPAK/GARP. "My head was spinning by the end," Rockwood admitted, "and I know I couldn’t have done it by myself. But at least I now have an idea about what’s involved. What’s really amazing," he adds, "is that the system has been running reliably ever since!"

The day of installation at MSCD was useful to Murray as well. He identified several holes in the documentation for the LDM, McIDAS, and GEMPAK and began the process of developing a protocol for helping others make the transition.

Rockwood spent part of that summer becoming familiar with the new system. Because the ingest machine is now doing a lot more than it did under OS/2, Rockwood hasn’t seen much increase in speed of the applications. He has noticed, however, that McIDAS-X is faster than McIDAS-0S2 in displaying satellite imagery. He has also been learning GEMPAK/GARP/NWX, which he’d never used. The result? "I love GARP and NWX, and so do my students! The interface is so easy and the variety of data is terrific. Since GEMPAK/GARP is only running on the Solaris machine, the students are now fighting over who gets to use it. With 35 majors, it’s become a battle royal. Until we got GEMPAK/GARP, we’d have to use the Web to look at the ETA, AVN/MRF, and RUC model data. Now they all want to use GARP and NWX to produce products tailored to their own interests." Rockwood has discovered that the two applications, GEMPAK/GARP and McIDAS-X are wonderfully complementary. McIDAS shines for manipulation of satellite imagery, overlays, and on-the-fly objective analysis, whereas GEMPAK/GARP makes it easy to display gridded model data. "You really need both," he adds, "but I sure wish McIDAS had a better interface."

Last year, Rockwood applied for and has been awarded an NSF Unidata equipment grant. During the next semester he will be purchasing six new computers to add to the existing equipment. At that time, he will complete the transition of all the machines to UNIX. "I’m really anxious to complete the move. Now that I see the benefit on the one machine, I want all the computers in our network to be running GEMPAK/GARP and McIDAS, so as many students as possible get experience with them. I’d also like to share some of the products, like radar and satellite images and local forecasts, with the rest of the campus. Once I get the new network established, this should be fairly easy to do. I know I’m going to need help again when it comes time to install software on my new equipment," he added, "but I also know that I’ll get all the help I need from Unidata. But I feel strongly that each of us using Unidata software has the obligation to learn as much as possible about our systems. Unidata was established as a cooperative effort between UCAR and its community, to get weather data to our educational institutions. So, next time, I’ll do the installation, and Don will watch. It should be interesting!"

The Sun is Setting on OS/2

by Don Murray, Unidata Program Center

In May of this year, the Unidata Program Center sent out a questionnaire about the use of McIDAS-OS2 in the Unidata Community. This was prompted by a request from Space Science Engineering Center (SSEC) at the University of Wisconsin-Madison (the primary developer of McIDAS), which was looking into alternatives to OS/2 for running McIDAS on PC platforms. Since that request, SSEC has decided that their November 1998 release of McIDAS (version 7.5) will be the last to support OS/2 and that they will sunset support for it altogether in 1999.

To the Unidata questionnaire, 15 sites responded that they are still using McIDAS-OS2. Of these, nine state this is the only Unidata display software they are using.

In light of SSEC’s decision, the Unidata Users Committee reviewed the use of OS/2 in the Unidata community at its October 1—2, 1998 meeting. This review included discussions with the UPC staff on the effects of a change in policy regarding McIDAS-OS2 and support for Solaris for Intel and Linux.

The Users Committee recommended to the Policy Committee that Unidata support for McIDAS-OS2 end on July 31, 1999. The Policy Committee endorsed this recommendation at its October 15—16, 1998 meeting.

What will happen to users of McIDAS-OS2 after July 31, 1999?

The sunset of a supported package means a cessation of advancement, not a prohibition against use. Indeed, such software typically continues to function as long as the environment–i.e., the hardware, the operating system, and the input data–remains stable. However, there is no guarantee of continued usability after the sunset date: Unidata will not fix bugs or adapt software to cope with environmental changes, such as new formats in the data stream. Unidata will provide at least one more major release of McIDAS-OS2 prior to the sunset date. This will include updates to make the system functional in the year 2000 (i.e., Y2K-compliant).

In July 1999, we will be changing the manner in which imagery is sent out. These changes to the Unidata—Wisconsin channel will better utilize bandwidth and lessen the processing load on ingesting machines. Unfortunately, the changes mean that McIDAS-OS2 sites will no longer be able to ingest the imagery. A note will be sent out shortly detailing the changes in the data stream and what sites need to do to prepare for them.

Non-ingesting McIDAS-OS2 systems will be able to continue accessing data from a UNIX ingestor or a remote ADDE server. However, at some point this may not be a viable situation if there are changes to file formats or ADDE interfaces in future releases of McIDAS-X. Sites continuing to use the OS/2 operating system after the sunset date should be aware that they must be running OS/2 Warp version 4.0 with current Fixpacks installed for their systems to be Y2K compliant. Warp 3.0 is not Y2K compliant.

What are the alternatives for McIDAS-OS2 users?

Those sites using McIDAS-OS2 to ingest data from the IDD will need to convert to the use of the UNIX LDM program to continue ingesting data. Unidata is currently supporting Solaris 2.6 for Intel and Red Hat Linux 5.1 for running Unidata software on PC platforms. In most cases, the hardware used for ingestion under McIDAS-OS2 can be used to run Solaris for Intel or Linux and the LDM. These systems can also be used to run McIDAS-X. Non-ingesting systems will also be able to run McIDAS-X under UNIX if the hardware is adequate.

Unidata supports its other software packages (GEMPAK, LDM) under UNIX, so sites now moving to UNIX will be able to take advantage of these packages as well as McIDAS-X. Sites using the LDM software have more flexibility in what data they receive and what is done with them. Some McIDAS-OS2 sites that have switched to UNIX have installed GEMPAK and use that package in addition to (or instead of) McIDAS-X. The Unidata GEMPAK distribution includes several Graphical User Interface (GUI) programs (including GARP) which sites have found easier to use than the McIDAS interfaces for general meteorological education, especially for accessing gridded data. Unidata McIDAS-X has a GUI included with it also.

How will the UPC help McIDAS-OS2 sites transition to UNIX?

The Unidata Program Center support staff will assist sites that choose to transition to UNIX. We will consult with users on the ability of their existing or proposed new hardware to handle a PC version of UNIX and Unidata-supported packages. We are already providing binary releases of the LDM and GEMPAK for Solaris for Intel and Linux and will soon provide releases of McIDAS for these platforms. We will also support the use of freely available compilers (gcc and f2c) for building all these packages. We have recently updated our installation documentation for LDM and McIDAS-X to make the installation process go more smoothly.

It is our recommendation that any site with multiple OS/2 systems and no UNIX systems convert its ingesting system over to UNIX as soon as possible. This will allow the site to run the LDM and continue receiving data. Several sites have already made this transition. The ingesting system can act as a file server for the other OS/2 systems until they can be converted, just as is done now with the OS/2 ingesting system. This will allow sites to slowly transition to the use of UNIX while maintaining data access. The UPC staff has been assisting some of these sites with remote installation and configuration and, where possible, with site visits.

Tony Rockwood of Metropolitan State College of Denver, a member of the Users Committee, recently converted his ingesting OS/2 system over to Solaris for Intel. He has offered to be a point of contact for sites inquiring about this change and the effect on his program. Tony’s experience in making this transition is described elsewhere in this issue.

McIDAS-OS2 sites need to start planning now for this transition. If you have any questions, please don’t hesitate to contact Unidata User Support.

PAGE: Refining Community Issues

by Sally Bates, Unidata Program Center

Early in November, representatives from 38 institutions met in Virginia to discuss the future of UCAR’s Program for the Advancement of Geoscience Education (PAGE). The goal of the workshop was to refine further the needs and priorities identified last year during a series of focus groups. Briefly, the focus groups, held at six locations across the country, had identified the following needs:

• A community multimedia database;
• Access to COMET materials in forms appropriate for use in undergraduate classrooms;
• A "clearing house" for a range of materials, including curricula materials, research results, and "best of practice" techniques;
• Coordination and sponsorship of faculty development workshops, training, seminars, and sabbaticals to help faculty use multimedia in their classrooms and to help them learn and use current pedagogical and assessment techniques;
• Assistance in applying student assessment and program evaluation methodologies; and
• Assistance in research consensus on copyright issues.

The Virginia Conference

During the first morning of the November conference, participants were briefed on the context in which PAGE was formed.

• John Snow (Dean, College of Geosciences, U. Oklahoma) summarized the extensive recent literature on shaping undergraduate studies in earth and geosciences. These range from American Geophysical Union reports and reports from the National Research Council to the National Science Foundation’s Shaping the Future: New Expectations for Undergraduate Education in Science, Mathematics, Engineering and Technology.
• Michael Mayhew (Geoscience Education Coordinator, NSF) described recent trends within NSF to reconsider the division’s approach to geoscience education, including the creation of an education program within the directorate.
• Jack Fellows (UCAR Vice President for Corporate Affairs and Director of the Office of Programs) summarized events leading to UCAR’s formation of PAGE and UCAR’s commitment to science education.

There was considerable discussion after each presentation on its relevance to PAGE and to the concerns of the community. Susan Avery (Chair, PAGE Steering Committee and Director of the University of Colorado’s Cooperative Institute for Research in Environmental Sciences) and facilitator Kaye Howe (President, Howe and Associates) guided and documented the discussions to ensure that all the ideas and concerns expressed were fully captured.

At the end of the formal presentations, PAGE director Mary Marlino summarized the community needs that had been identified during the six focus groups held during the Fall of 1997. This information formed the basis of a planning document that had been distributed to all participants prior to the conference. The participants were assigned to smaller discussion groups for the afternoon. With the planning document in hand, they were asked to identify strategies and roles in eight areas:

• Technology and Multimedia Access (e.g., what are the discipline-specific technology development issues that should be handled by PAGE?)
• Curriculum Development (e.g., are there tools, techniques, and education approaches that should be adapted and disseminated by PAGE?)
• Teacher Preparation (e.g., how can PAGE help improve pre-service teacher education?)
• Assessment (e.g., how can PAGE contribute to assessing whether and which technology innovations are successful in the classroom?)
• Faculty Development (e.g., how can PAGE contribute to faculty development?)
• Community Building (e.g., who is the PAGE community and how should it be structured?)
• Intellectual Property (e.g., how should PAGE balance desire for individual benefit with the community goal of shared resources?)
• Outreach to Under-represented Populations (e.g., what programs, policies, and partnerships should PAGE encourage to bring diversity to the geosciences?)

Reaching Consensus

The second day of the conference was devoted to presenting and discussing the ideas and recommendations that emerged from the smaller groups. Several common themes emerged. The concept of PAGE as "incubator" for community ideas and resources was widely shared. This role envisions PAGE as providing a framework to facilitate access to resources created within the community, including the evaluation and assessment of those resources. Participants encouraged the program to form partnerships with the wide variety of institutions already involved in geoscience education reform.

After a morning of intense discussion, Eugene Takle (Iowa State University) introduced a resolution that, with fine-tuning from the participants, captured the essence of the conference. The resolution was adopted unanimously. It reads:

We, the attendees of the Fall 1998 PAGE workshop, in response to geoscience education needs* and in recognition of community readiness, resolve that

*As indicated, for example, by the AMS Heads and Chairs’ resolution of October 1996 on multimedia education.

Director Mary Marlino is pleased with the extraordinarily strong consensus reached at the workshop on the importance and character of PAGE’s future. "We believe that we can now say with confidence what the community wants. We’re a diverse community, and the fact that we were able to reach consensus is a powerful motivator for moving us to the next phase."

Unidata–believing its own community stands to benefit significantly from PAGE–is in close collaboration with Mary and will help develop the NSF proposal she’s now preparing.

Assuming success in the proposal-review process, the "incubator" will be fully functioning at UCAR next summer or fall. We hope Unidata participants will be among the first faculty members to see their educational ideas take shape through interaction with PAGE’s staff of educational designers and assessment experts.

A full report on the conference, including information on who participated and detailed reports on group discussions, is available on the PAGE web.

Unidata Does Dods

by Ethan Davis, Unidata Program Center

DODS (Distributed Oceanographic Data System) is a development effort being undertaken jointly by the University of Rhode Island Graduate School of Oceanography and the Massachusetts Institute of Technology Earth, Atmospheric, and Planetary Science Department. Funding for this effort is from NOAA and NASA. In its proposal to NASA for this development work, Rhode Island subcontracted with Unidata to provide support services for DODS. Specifically, Unidata has been funded (through Rhode Island) to assign one person (me) to act as the principal point of contact for a given software package or system. My role is to act as a filter to the user community, answering the obvious questions immediately or passing the question to whomever in the DODS group most familiar with the associated software. Rapid feedback (same-day turnaround) to users is a cornerstone of this user support model. To maximize user’s familiarity with DODs software, I will work with DODS core-group programmers to enhance or correct the software. To minimize my need to write new responses to every question received, I have created a searchable record of our interactions with users, based on Unidata’s e-mail archive system. Most of this record will be externally accessible through the Web, augmenting DODS documentation.

What is DODS?

DODS makes remote, scientific data accessible through a number of data analysis and visualization packages familiar to oceanographers. There are two perspectives to understanding DODS: the data provider’s and the data user’s. The provider’s perspective, making data visible to others, involves setting up a DODS data server. Data servers are available for data files in netCDF, HDF, JGOFS, DSP, Matlab, and FreeForm formats. Servers for several other formats are also being developed.

The data user’s perspective on DODS centers on the ability to utilize familiar data analysis and visualization packages to access remote data. Once the application is DODS-enabled, it becomes a DODS client and can access data from any DODS server, regardless of the format in which the data are actually stored. Several applications have already been DODS-enabled, including the commercial Matlab and IDL packages and several free applications (e.g., Ferret and ncview). The DODS-enabled Matlab application includes a GUI for easy access to DODS data. A DODS version of the netCDF API is also available so that applications that use netCDF can be DODS-enabled by simply relinking. The Ferret and ncview applications utilize this feature of DODS. More DODS GUIs and API libraries are being developed.

Several resources are available on the DODS web site if you run into difficulties. It contains user documentation and support resources. Besides the documentation, the support resources include an FAQ page and searchable support e-mail archives.

WXP Version 5.0

Editor's note: WXP is currently in a state of transition from Purdue University to Unisys Corporation. The author of the package, Dan Vietor, left Purdue for Unisys in early 1998 and the rights to WXP are being transferred to Unisys. At this time, this transfer has not been completed.

While the WXP package is not supported by Unidata, many in the community use it. Unidata maintains an e-mail list that WXP users may use to seek support either from each other or, in a limited fashion, from the author at Unisys.

The availability of WXP is currently restricted. The FTP site at Purdue is disabled as the legal transfer of WXP to Unisys proceeds. In the near future, a new FTP site will be made available at Unisys. However, issues about cost of or restrictions on the use of the package have not been fully resolved. When the new licensing for WXP is set up at Unisys, the details will be made available to the Unidata community. If there are any questions about the package, its availability, or its pricing, contact Vietor.

by Dan Vietor, Unisys Corporation

WXP version 5.0 is a dramatic change from the previous release five years ago. Since then several new data types have been added to the standard data streams. These include NIDS, radar mosaics, METAR data, and the latest NOAAport. To add support for these new data types, WXP had to change the way it processed data. In previous versions of WXP, each program was closely tied to the data it was processing as well as to the way it visualized the data, and there was a significant amount of redundant
code that made any changes and upgrades nearly impossible.

In upgrading WXP, my goals were to unify existing functionality, add new capabilities, support the new data types, and develop a graphical user interface. In other words, WXP needed to be rewritten from the ground up.

I began this task in 1994 by developing a program ("rad") to support NIDS and NOWrad data. This became a prototype of the new WXP library. Since then, I’ve added more and more of WXP’s functionality to the new WXP library. Now, very little of WXP4’s source code remains.

Beta testing of WXP5 was started in mid-1996 and its core has been stable since mid-1997, but requests for additions to WXP, the need to support NOAAport, Unisys, and other data types, and the port to Windows 95/98/NT delayed its release nearly two years.

New Functionality

Below is a list of the major new features included in WXP5.

WXP Resources. The UDRES resource interface (in version 4) was replaced with the WXP resource interface that now includes support for complex and conditional resources and the use of environment variables. Environment variables offer an intermediate solution to setting resources. Rather than repeatedly specifying the same resources to different programs within a script, environment variables can be set, and these settings disappear when the script ends.

New Naming Convention. The file name conventions, hard-coded in WXP4, have been moved to a name convention file so that more types of filenames could be used. In addition to "current" filenames (based on time), the new interface allows for different styles of name conventions that might be used with NIDS and lightning data. A set of wildcard characters can be used to set date, time, and data type in the file name. Each naming convention has an associated "name convention tag" to specify which type of file to use. This means programs can use data from more than one source.

New Menu and Variable Interface. In earlier versions of WXP, users were limited in how they could specify parameters. The new interface has been generalized to accept more types of values so that almost any time, level, or variable combination can be specified. Variables can be composites (station model), functions of other variables, or overlays of multiple variables.

A wide variety of plotting attributes can be specified (contour interval and base, colors, line styles, fill patterns, etc.) Complicated specifications can be added to ".var" files for each program. These define aliases for complex data types and station model plots (which can include any plottable variable in any units). The variable files can be used to set up multi-panel plots as well. In each of these cases, there is a database file used to predefine aliases and to indicate what will appear in each menu.

Plot Domains and Regions. WXP5 no longer has preset regions. There is a "wxp.reg" database file to which the user can add any predefined region, including those for local use. The region aliases simplify domain specification, and the plot domain specification allows new projections (including extended domain parameters).

Map Plotting. The new mapping interface allows the plotting of multiple map files, each with its own plotting attributes. Complicated specifications can be placed in a map list file (.mpl). Maps can be map databases, GIF images, raw files (e.g., to plot county names), or binary files (e.g., from the USGS DLG database). Conditional map plotting toggles the display of a map depending on the size of the domain. Thus, maps can be more detailed as the user zooms in on the image.

New Graphics Interface (looping, zooming, HPGL). WXPloop and regular plotting programs are now unified. This allows programs like rad and sfcwx to loop and overlay data without using WXPloop. Users may also zoom in by stretching a rubber-band box over the image; the image will be replotted to the new domain. The new plot may have more map detail (conditional map plotting) or more stations plotted (automated priority change). Plotting and contouring can be also be done by the same program. There is now support to print to HPGL-compatible laser printers and plotters. This includes any printer that supports PCL5. Finally, more mouse and keyboard commands have been added for greater interactivity.

GRIB Changes. The new GRIB interface decodes more types of GRIB data (e.g., ECMWF, UKMET, and NCEP). The new "model.lup" file allows grids to be pieced together, such as the thinned AVN grids, prior to plotting. The grid math interface allows users to perform a wide variety of functions on the gridded data (e.g., Laplacian and Q-vector functions), and new vector functions and streamline functions have been added.

Unit Specification. WXP uses a simple unit conversion process that allows various types of unit conversion.

Fonts. WXP can now use system fonts such as X11 and Adobe fonts.

New WXP Database Files. Database file names now have extensions that reflect data types (e.g., ".map" for map files) and several new file types have been added. Look-up files have been added to facilitate updates.

Windows 95/98/NT Support (WXP32). Most of the capabilities of
WXP5 have been ported to Windows 95/98/NT. Support has been dropped for DOS.

Other Operating Platforms. WXP5 is now being developed on a Linux
platform with support for Solaris (Sparc and x86), AIX 4, and HPUX 10. Future support for SGI IRIX and Dec UNIX are questionable at this time.

Support for NOAAport and New Data Types

WXP5 supports most of the new data formats included in NOAAport, including RCM radar products (the poor man’s NIDS), new GRIB products, and GINI satellite imagery. The radcvt program can create national radar mosaics, which may be redistributed freely. Support for Redbook graphics will be added at a later date.

WXP now supports the following data types:

• Surface: METAR, SAO, Synop, Buoy, DRIBU, and CMAN
• Upper Air
• Radar: MDR, RCM (including national mosaics), NIDS, NOWrad, Unisys radar mosaics
• GRIB: support for most GRIB products, including HIRES, NOAAport, NCEP, ECMWF, and UKMET
• Satellite: Unidata McIDAS AREA files plus some other GOES-based AREA files, NOAAport GINI format, Unisys DSAT file format
• MOS: support for ETA, NGM, and MRF MOS data
• Wind Profiler: only basic support
• NLDN Lightning: support for both SUNY (Unidata) and Unisys formatsAdditional decoders for CLIMAT, TAF, and hurricane products

The Future of WXP

WXP is currently in transition from Purdue to Unisys and many issues (pricing, support, and direction) remain. I can report on the following future plans for WXP, however:

• As part of the WXP5 rewrite, much of the code was designed with object-oriented programming in mind. Parts of WXP will eventually be ported to Java and some Java-based WXP objects should be available sometime during 1999. It is unknown whether a full port of WXP to Java will be done.
• I’ve also already started developing a graphical interface for WXP on Windows; it eventually will be ported to UNIX.

A Word of Thanks

WXP version 5 has been a long process of rewriting code and adding new support and functionality. Lost in most of this was the thorough testing needed to make WXP5 a solid set of tools. The Unidata sites that participated in the two-year beta test provided me with invaluable testing and bug information. I would like to thank the dozen or so beta test sites. Without them, my job would have been far more difficult. I hope we can continue your involvement in the future.

New Staff at Unidata

by Sally Bates, Unidata Program Center

Baptism by Fire

Joanne Graham joined the Unidata Program at a dead run. "I spent my first two days attending a Policy Committee meeting," she laughs, "and, boy, was that an experience! I didn’t understand a fraction of what was being said, and would have been even more lost but for a wonderfully helpful member who quietly explained to me what a NOAAport was, and an IDD, and an LDM, and . . ." Joanne’s introduction to Unidata was indeed baptism by fire. The meeting, held in Rhode Island, was marked by the news that Unidata’s budget for the new proposal period would be significantly lower than requested. On returning to Boulder, she became immersed in helping identify the ramifications of the new financial constraints and developing budget scenarios for both baseline and "advancement" projects. (Dave Fulker’s article elsewhere in this issue explains these.)

Joanne is Unidata’s new program administrator. With a B.Sc. in Business Administration and eight years of administration within the NCAR Atmospheric Technology Division’s Research Aviation Facility (RAF), she’s comfortable managing large and diverse budgets, but learning the Unidata language took time. "I hadn’t expected to be boggled by the terms," she admitted. "It’s like learning a foreign language." At RAF the jargon was about aircraft parts and instruments; at Unidata, it’s software packages, data streams, and computer terms. But learn the new language she has: see her article in this issue on NOAAport.

Unidata also represents a big change in scenery as well. RAF offices are at the Jefferson County (Jeffco) Airport in Broomfield, Colorado. "I’d walk out of my office at Jeffco into a huge hangar," she remembers. "Sometimes we’d have meetings in one of the aircraft. I really loved seeing the different aircraft and instruments, and meeting with the range of people involved in maintaining, equipping, and flying the planes." After her years of interacting with pilots, mechanics, engineers, and scientists, Unidata’s mix of programmers and administrative staff may seem tame.

"Unidata presents an opportunity for me to be involved in a broader range of projects and to get to know people in a broader community," Joanne responds when asked what drew her to Unidata. "At RAF my job focused primarily on finances and my interactions outside of NCAR were fairly limited. At Unidata we are regularly involved with people not only within UCAR, but from the university and federal communities as well. I am really enjoying this."

Before joining NCAR, she worked for the University of Colorado Foundation as an events planner and project coordinator, activities that she thoroughly enjoyed. Her interest in meeting and working with a range of people is also expressed in her external activities. Joanne and her husband, Scott, are avid skiers, and Joanne taught skiing to blind students for nine years as a volunteer. She now volunteers in the Boulder Valley School District teaching reading in an elementary school. "My kids are in the BVSD," she explains (she has two), "and I like to keep in touch with their schools."

"Leaving the RAF after eight years was like leaving home," Joanne remarks, "but I knew immediately that my work at Unidata would be exciting and rewarding. Unidata is a terrific program with terrific staff and a very supportive community. My ‘baptism by fire’ made me appreciate this immediately," she noted. "I look forward to how much more I’ll learn in the years to come."

Off the Ice Sheet and Into the Kitchen

Jeff Weber, Unidata’s new student assistant, is clearly a meteorologist’s meteorologist. Shortly after joining Unidata in early September, he got married and headed for the Florida Keys on his honeymoon, knowing full well that a hurricane was coming. "I was really looking forward to it," he admitted, "since I’d never been in one before." His wish was granted. He and his bride, Jennifer, were evacuated twice because of Hurricane Georges: first from the Florida Keys, then from Miami Beach. "It was really neat. We had two days on Islamorada pretty much to ourselves. Because of the dome of high pressure, it was warm, clear, and still. The only drawback," he noted, "was that all the other tourists had left and the locals were busy boarding up, so we had to make meals for ourselves in the hotel room." And they missed their appointment to swim with dolphins, since the sea park closed. His new wife, apparently, is not adverse to Jeff’s enthusiasm for raging weather; a good augury for their life together, it would seem.

Jeff is in the process of completing his masters in Geography at the University of Colorado (CU). His primary interest is in climatology, with a strong interest in remote sensing. "I’ve always been a huge weather-weanie," Jeff admits, "but it’s taken me some time to give in to it." Jeff completed his undergraduate work at CU in international finance and then spent several years in a variety of business ventures, including real-estate development in Colorado Springs and creating adventure expeditions in Belize, in Central America. "Lying in a hammock in Belize, looking at the clouds, I finally realized that studying weather was what I really wanted to do," he said. "So I packed up, spent time in Arizona picking up the undergraduate prerequisites I needed, and got back to CU to study climatology."

His interest in adventure, weather, and remote sensing led him to the Greenland ice sheet. He has spent the last two summers installing automated weather stations on the ice sheet for CIRES (CU’s Cooperative Institute for Research in Environmental Science). "Under NASA and NSF grants, CIRES has installed 15 of these towers," Jeff remarked. "NASA is interested in assessing the mass balance of the ice sheet. I personally installed and maintained seven of the towers over two summers. It’s a difficult two-person task. My partner and I camped on the ice sheet for weeks, sometimes installing new towers, sometimes performing maintenance on established towers. Working a small crane in -40° with -120° wind chill was grueling, physically and emotionally. But," he adds, "it was also extremely beautiful. The optical properties of the atmosphere there are truly awesome." And this work forms the basis of his master’s thesis, which compares measured versus modeled pressure fields over the Greenland ice sheet.

At Unidata, Jeff has been assigned the task of loading COMET case studies onto the CODIAC systems. (Ethan Davis, who was formerly responsible for this is now devoting most of his energy to supporting the Distributed Ocean Data System; see the article on DODS elsewhere in this issue.) "My goal is to see how much I can automate the task of uploading the case studies," he explains. "At this point, it’s a manual task that takes considerable time." Jeff is also teaching two sections of a meteorology course at CU and engages in forecasting for some friends who run a California roofing business. Added to all this is his music (he’s a bass player who favors "psychedelic" jazz). His schedule is so busy, he seems oblivious to his surroundings: a workstation in the office kitchen. ("Hey, after the Greenland ice sheet, this is comfortable!")

COMET Case Studies and Beyond

by Linda Miller, Unidata Program Center

UCAR’s COMET, JOSS, and Unidata are working jointly to provide hydro-meteorological case studies on the World Wide Web via the CODIAC database management system. The case-study data have been collected and developed by COMET and are based on weather events of interest to forecasters and researchers. The NWS Office of Meteorology has provided support for this project with the goal of fostering cooperation between the NWS Science and Operations Officers and the university community.

The 13 case studies now online are in the table below. You can search or browse through them or order individual data sets from a particular case study. Supporting documentation and sample exercises are included to provide examples of how the case studies can be used in various settings. In the last Unidata Newsletter, we reported on some of the diverse ways case studies are being used in the community.

Other Case Studies of Interest

The survey also indicated interest in community contributions of case studies. Since then, Lynn McMurdie at the University of Washington, Department of Atmospheric Science, has volunteer to contribute a case, including sample exercises, based on a "Midwest Cold Season Synoptic Storm" from October 16-17, 1996. We are adding this to the case study library as Case 14.

We would like to encourage additional case study contributions from the community. If you have a local, regional or national case study that you have created and would be willing to share, either by link from our Web page or by adding it to the CODIAC library, please contact us.

Case Studies Currently on CODIAC

Unidata Supported Platforms

by Matt Hicks, Unidata Program Center

* Some Unidata packages (netCDF and LDM4, for example) are actually supported on a wider range of platforms. See the specific package documentation for information on whether the software has been ported and tested on additional platforms.