Review of NASA's Distributed Active Archive Centers (1999)

The Langley Research Center (LaRC) DAAC manages data related to atmospheric chemistry and the Earth radiation budget, from remote sensing observations and field experiments. At the time of the review, the DAAC had extended the capabilities of its own information system to manage data from the first Clouds and the Earth's Radiant Energy System (CERES) instrument, which was launched on the Tropical Rainfall Measuring Mission (TRMM) satellite on November 28, 1997. The success of this development and data management effort, which was undertaken because of delays in the development of the EOSDIS Core System (ECS), illustrates the resourcefulness and capability of LaRC DAAC staff. Its success, however, has also led the DAAC to forgo use of the ECS for managing its upcoming data streams. It may be possible for the DAAC to gener-

alize its CERES-specific information system to accommodate other types of data, but to do so would duplicate overall EOSDIS development efforts. It would also incur the risk of isolating the LaRC DAAC from the EOSDIS system, thereby making it more difficult for users to integrate data from the LaRC DAAC with data from other DAACs. Consequently, the panel's main recommendation is that the DAAC develop a transition plan to link its information systems with the ECS and keep a strong focus on the overall EOSDIS goals and ideals.

Langley Research Center began processing Earth Radiation Budget Experiment (ERBE) data in 1985. The LaRC DAAC was formed in 1989 and serves the atmospheric science community, particularly those segments interested in Earth radiation budget, clouds, aerosols, and tropospheric chemistry (Box 4.1). Its current holdings include data from aircraft and satellite instruments and field campaigns.

In addition, the DAAC is currently processing data from the first CERES instrument, which was launched on the Tropical Rainfall Measuring Mission (TRMM) in November 1997. The CERES/TRMM data will increase the volume of the DAAC's holdings from 900 GB to 155 TB by the completion of the mission. Because the ECS was not ready in time for the TRMM launch, the DAAC developed the Langley TRMM Information System (LaTIS) from its existing information management system.

The DAAC is scheduled to receive data from several EOS era instruments over the next few years. These include two more CERES instruments, the Multi-angle Imaging Spectroradiometer (MISR) and Measurements of Pollution in the Troposphere (MOPITT), all on the AM-1 platform, and the Stratospheric Aerosol and Gas Experiment III (SAGE III) on the Russian Meteor 3M satellite. Incorporation of these data streams will increase the volume of the DAAC's holdings from 3 TB to about 1,300 TB by the completion of the mission, but the DAAC feels that scaling-up is less a data volume problem than a problem with the number and diversity of data sets and the ability to train staff to know enough about the data to help users. If allowed, the DAAC will expand the capacity and functionality of the LaTIS to accommodate these data streams, although this would tend to further isolate the LaRC DAAC from the EOSDIS system.

The Panel to Review the LaRC DAAC held its site visit on November 18–19, 1997. The panel subsequently updated its report through e-mail discussions with the DAAC manager in June through September 1998.

The LaRC DAAC has holdings in the areas of the Earth's radiation budget, clouds, aerosols, and tropospheric chemistry (Box 4.2). For example, the long-

term radiation budget data from ERBE and the follow-on CERES project will prove valuable to researchers assessing long-term climate variability. An example of an Earth radiation budget data product is given in Figure 4.1. Similarly, the LaRC DAAC enables researchers to view the temporal and spatial variability in the composition of the atmosphere. This provides insight into trends in the oxidizing properties and radiative forcing of the atmosphere. The overview of data points out, for example, areas of photochemical ozone production versus

destruction and shows the impact of anthropogenic emissions on the chemistry of the remote troposphere.

To facilitate integration of different types of data from different sources, EOS data will be distributed in a common format, Hierarchical Data Format (HDF). The LaRC DAAC and its users have little experience with HDF-EOS and are concerned about its being a deterrent to data use and access, particularly due to a limited set of tools for its use. In addition, the three HDF data structures supported by the ECS—point, swath, and grid—do not apply to all LaRC data sets. ESDIS recognizes the problem, but until a solution is devised, the panel counsels the DAAC to consider supporting multiple formats. Several data centers and DAACs have experience writing translators for HDF, and the DAAC should take advantage of this existing expertise before MISR and MOPITT are launched.

The scientists involved with the mission or experiment are largely responsible for the metadata associated with their data products. For non-EOS data sets, the LaRC DAAC provides the data producers with a data ingest form, and the scientists specify the key parameters and perform the quality assurance and quality control. The DAAC then checks the data against the acceptable values provided by the scientists as another quality assurance and quality control step for the data. For EOS missions, the DAAC is obligated to use the ECS metadata model, although data providers can also define product-specific metadata. Only a subset of the ECS metadata was used for the CERES/TRMM mission, however,

which may pose difficulties for its incorporation into the ECS. The problem is that the ECS has a minimum set of metadata, ''valids" without which the ECS will not work.

At the time of the site visit, the DAAC was preparing for the imminent start of processing for the CERES/TRMM experiment. (The processing began in December 1997, and the DAAC has already reprocessed some of the data.) Similarly, the DAAC's processing plans were to generate Level 1-3 CERES/AM-1, MISR, and MOPITT data, and to distribute and archive the AM-1 data and SAGE III products using the ECS (see Table 1.1 for a description of processing levels). Delays in the ECS, however, have led NASA to consider transferring processing responsibilities for some instruments from the DAACs to the science teams. As a result, the DAAC's backup system, the LaTIS, will be used to process and handle CERES/AM-1 data. MISR processing is still planned for the ECS, and MOPITT processing is planned to transition to the ECS after an initial validation period.

To prepare for the data streams, the DAAC is testing and integrating Project Generation Executables (PGEs) into its information system. As of June 1998, the DAAC had run 31 simultaneous instances of the CERES/TRMM PGE for producing Level-1B data. With regard to MISR, eight PGEs have been delivered to the DAAC for testing, and the Level 3 PGEs are still being developed. The DAAC has successfully run two of the MISR PGEs through the data processing system and is testing and integrating the others into the ECS. Tests to integrate MISR PGEs into the LaTIS are scheduled for summer 1998. Finally, the three MOPITT PGEs will be run by the MOPITT instrument team rather than the DAAC, until six months after launch. Although the DAAC has tested MOPITT PGEs on earlier versions of the ECS, comprehensive tests for integrating the PGEs into the system will not begin until closer to launch.

At the time of the review, the panel was concerned that interdependencies with other instruments could affect the DAAC's readiness for the CERES instruments. CERES/TRMM depends on the Level 1B product of the Visible Infrared Scanner (VIRS), and CERES/AM-1 depends on Level 1-B products of the Moderate Resolution Imaging Spectroradiometer (MODIS). Simulated VIRS and MODIS data for testing PGEs are being provided to the LaRC DAAC by the CERES instrument team, and the DAAC anticipates no problems receiving the data it needs for PGE testing.

The DAAC does not have a formal strategy for reprocessing. Rather, it attempts to ensure adequate resources to allow both processing and reprocessing, and works with its instrument teams to implement reprocessing as necessary. For

example, with the CERES/TRMM experiment, the DAAC has been processing Level-1B data daily since December 1997. Several revisions of the Level-1B PGE have been incorporated, and parts or all of the data have been reprocessed twice as part of algorithm verification. In the longer term, the CERES team and the DAAC are planning a more extensive reprocessing of CERES/TRMM data in the third year of the mission.

Subsetting is a concern of the DAAC. Subsetting tools are scheduled to be provided in later versions of the ECS, but they will likely not be available before the next EOS mission is launched. Consequently, the DAAC has begun developing capabilities for subsetting large-volume, high-demand products on-the-fly.

The satellite holdings of the DAAC are most useful when combined with other types of data. For example, the LaRC DAAC mandate includes aerosols and tropospheric chemistry. Aerosols and reactive trace gases show a good deal of variability on regional scales; their concentrations are often significantly higher near sources, but certain meteorological conditions can cause pollution on a large scale. These regional-scale perturbations can be relevant to global change issues, for example, the sulfate aerosol and ozone from industrial processes in North America, Europe, and Asia and biomass burning in the tropics. Numerous regionally focused field experiments to gather data on aerosols and tropospheric gas-phase species have been conducted or are planned, and the LaRC DAAC will have to be aggressive about acquiring these data sets in order to best serve the scientific user community.

NASA and NOAA are negotiating a Memorandum of Understanding to transfer data from the DAACs to NOAA archives sometime after the end of the EOS missions. Until this agreement is concluded, the LaRC DAAC plans to continue managing its data as long as funds are available. Although the DAAC sees the data transfer as inevitable, it believes that this will be expensive and that a NOAA archive will move the data too far away from those who have expertise with the data to be really useful.

The user community for the LaRC DAAC can be divided into two general types; data providers and data users. The DAAC philosophy is to serve both user types equally, while recognizing that scientific researchers of either type have the highest priority. Data providers are primarily scientists involved with current or recent space experiments, field experiments, data analysis and synthesis teams, and EOS instrument teams. Data users include scientists, educators, the general public, and the commercial sector. DAAC surveys indicate that scientists are the primary user group, accounting for more than 50% of Web-based inquiries, and overseas users are the fastest-growing user group. The DAAC tries to serve its entire user community by providing a variety of ways to access and use its data holdings.

The role of the DAAC's User Working Group (UWG) is to identify new data sets that would be useful to the DAAC and its users, and to determine whether additional functionality is needed. The UWG feels that the DAAC is responsive to its recommendations, but with the completion of Version 0 of the information system, the members feel that their job is done and there is little interest in joining or participating in the meetings. Neither the DAAC nor the UWG feels that the UWG has a role in guiding the development of the LaTIS or ECS systems. After an 18-month hiatus, the UWG held its requisite two meetings in the past year, although only about 25% of members attended.

The panel feels that the UWG is not as effective as it could be. The DAAC seems to want the UWG to become an outreach group that operates under the DAAC. Instead, in the panel's view, the UWG should be an external group that provides scientific oversight, and it should have a co-chair from outside Langley Research Center as mandated in its charter. The panel followed up with the UWG in June 1998 and learned that a co-chair from the University of Colorado had recently been appointed. To ensure that the needs of the users are met the panel urges the UWG co-chairs to become familiar with a broad range of DAAC activities, and to become more aggressive in providing needed advice.

A significant strength of the LaRC DAAC is its strong interaction with the radiation and clouds scientific community who both produce and use DAAC data. This evolved as a result of Langley's processing of the ERBE data beginning in 1985. Thus, when the DAAC was formed in 1989, the initial staff already had experience in interacting with ERBE scientists, whose close geographical proximity to the DAAC greatly facilitated this interaction. The evolution continued as preparations were made for processing CERES data; the DAAC personnel actively interact with CERES algorithm developers as well as attend CERES Science Team meetings. The proximity and interaction with both ERBE and CERES have clearly proven beneficial to the DAAC staff, providing them with a unique appreciation of the science issues relating to the data they are processing.

Field campaign data are generally more complex than satellite data. They involve one-of-a-kind instruments and require extensive metadata. One such field experiment was the First ISCCP Regional Experiment (FIRE) for which the LaRC DAAC archives and disseminates the data to investigators. LaRC DAAC personnel participated in the planning meetings and field experiments, and scientists from the FIRE experiment felt well served by the DAAC. A representative from FIRE who attended the site visit stated, "The LaRC DAAC is an integral part of our experiment." On the other hand, this strong involvement with specific projects limits the DAAC's ability to take a broad view, and attention should be paid to other instruments and disciplines.

The DAAC's cooperation with the radiation and clouds scientific communities has been excellent. Interaction with the broader scientific community using DAAC data is not as strong. For example, Langley Research Center hosts an outstanding atmospheric chemistry facility employing world-class scientists. They hold seminars and offer scientific expertise to anyone in the DAAC who is interested. Some of the DAAC personnel were drafted from this facility, and to take full advantage of the in-house expertise in chemistry, more such appointments should be made in the future. The panel feels that unless ties with a broader range of scientists at Langley Research Center and elsewhere are strengthened, the DAAC will miss the benefit of a richer source of advice and feedback from its users. For example, scientists actively involved with the DAAC could help identify which complementary data sets to acquire (see "Data Acquisition," above).

Users can access the DAAC's information system in a variety of ways, including a graphical interface, a character interface, Web search, and ftp. If a user has a problem with any of the access methods, the DAAC attempts to solve it. If time is required to solve the problem, however, the DAAC will provide access to the data via another mechanism. Problems with media or DAAC-provided software are addressed by DAAC staff. If the problem is with the content of the data file, the problem is forwarded to the data provider. The UWG felt that the DAAC handles unsophisticated customer requests and problems well and that it is also effective in identifying the right data providers for users to talk with.

Subscription services are available at the DAAC, but the system is not automated and bogs down quickly. Future releases of the ECS will have subscription services, and the DAAC plans to wait for this capability to be offered by the ECS, rather than develop its own automated service.

The DAAC will ultimately be evaluated on the number and impact of reviewed scientific publications that acknowledge DAAC services. Although the DAAC has played an integral role in major experiments such as ERBE and FIRE, little effort has been made to track publications or citations to document the productivity of the DAAC. The DAAC presented a list of 12 peer-reviewed journal articles that used DAAC data. Based on the panel's knowledge of the literature, the publications of panel members, and the number of researchers using the DAAC (several hundred per year), the panel suspects that the number of articles that actually used data from the DAAC is probably an order of magnitude greater. DAAC personnel expressed reluctance to make the effort to document their impact on the science, but doing so could help the DAAC avoid unfair criticism in the future. Active, atmospheric researchers on-site (see recommendation above) would have a vested interest in enhancing and documenting the scientific productivity of the DAAC.

The LaRC DAAC is located within a secure facility, but because few people need to physically visit the DAAC, high security was not viewed by the DAAC as a barrier to access. Visits can be arranged easily for U.S. citizens and residents with green cards. For other individuals, a visit of less than two weeks can be approved by the deputy center director with about ten days notice, and longer visits require approval by NASA Headquarters and about one month notice.

The Version 0 system runs on a collection of networked computers under the UNIX operating system. This system, which is being phased out, offers a standard X-Windows interface, a character-based interface, and an evolving Web-centric interface, all developed at the DAAC. In addition, Version 0 includes a cross-DAAC interoperable Web gateway interface. Some users have written single-purpose software programs that rely on Version 0. The DAAC will have to provide these users with an easy path to upgrade to the ECS baseline in order to be able to quickly retire the Version 0 hardware, software, and processes once an operational version of ECS has been delivered. Only by explicitly planning this transition in a timely fashion will the DAAC be able to eliminate the need to allocate resources to the Version 0 system.

The future hardware, software, and process suite specified in the ECS contract comprise the ECS baseline. At the time of the site visit, some hardware with initial checkout and installation software had been delivered, and the DAAC was awaiting the remainder of the baseline system without knowing exactly what the system would include or how it would operate.

Hardware. The hardware associated with the ECS baseline is a modern system architecture composed of SGI Challenge and Sun Ultra Enterprise machines, along with fairly large tape archive systems (EMASS AML and STK PowderHorn) built by Storage Technology. This hardware appears to be fully installed and available for use once the software is delivered. During the site visit the panel was given no evidence that the system hardware had been sized to fit the load expected at this DAAC. Since the aggregate input/output and processing bandwidth available within the installed equipment seems to support the T3 communications link, one must assume that this analysis has been done as part of determining the hardware baseline by the ECS contractor.

The panel notes that the DAAC is accumulating maintenance costs on ECS hardware that sits idle until the ECS software is delivered. If and when the software is delivered, the DAAC will have to make a concerted effort to migrate its data sets to the new system.

Software. Although details of the ECS software design and selection were not available to the panel, the software is described as an object-oriented architecture, composed of approximately 70 COTS packages surrounded by more than a million lines of contractor-developed custom code. This COTS software appears to

have grown into a fairly stable set of supported elements as the vendors' products have matured and the ECS contractor has firmed up its design.

Processes. The descriptions given to the panel were unclear concerning time lines and processes necessary to install a locally desired change into the delivered software. LaRC DAAC personnel had only a minimal amount of system knowledge in this area, and it seems likely that staff will need process training when the system baseline is brought on-line later this year. DAAC staff were unsure of what metrics will be available to allow them to understand how well the system is running when it is on-line. Again, basic ECS system training, with an emphasis on production metrics relevant to the LaRC DAAC, would significantly improve the DAAC staff's understanding of the system.

Because the ECS baseline software was not available in time to support the launch and initial operation of CERES/TRMM, ESDIS asked the LaRC DAAC to develop a parallel system that would serve as an interim baseline until the ECS was installed. The resulting system, the LaTIS, was designed to use the COTS chosen by the ECS contractor where possible, based on the rationale that the training requirements for the DAAC staff would be minimized.

Hardware. The hardware baseline for the LaTIS is based on the next-generation SGI machines (the Origin series), which are largely compatible with the ECS Challenge series machines. Both are multiprocessor architectures and use the same processors. However, the processors are connected in different ways and thus require different version of the SGI operating system. The DAAC's experience is that applications generally run on either series, but drivers do not. It expects that the LaTIS would run on Challenge machines, but has not tried this.

LaRC DAAC management obtained a factory-refurbished tape archive (the STK PowderHorn library with six Redwood SD-3 drives) to save money. The archive is completely compatible with the ECS baseline and can therefore become part of the eventual ECS system.

Software. Because the LaTIS contractor is not the same as the ECS contractor and because details of the ECS software design were not available, the LATIS software was implemented using software that is at least partially incompatible with the current ECS baseline. Specifically, the LaRC DAAC team has chosen to use the BigSur database technology on top of the Informix Universal Server to implement the LATIS. BigSur is the result of work at the University of California, Berkeley, and has been modified to handle the load and requirements for automating the CERES production process. Although this is a technologically sound choice for the LATIS design, such incompatibilities will force the LaRC DAAC to operate a separate maintenance

process until such time as this software can be merged into the ECS. In other software selections, the LaTIS appears to have achieved compatibility with ECS by using libraries obtained directly from the ECS contractor. When asked about the configuration management of these libraries, however, DAAC personnel indicated that the libraries used for the LaTIS may not have kept up with the latest changes to the ECS libraries. Thus, it appears that this is a second area in which the LaTIS may prove challenging to merge with the ECS.

Langley Research Center scientists have identified a number of additional capabilities, such as subsetting, that could be included in the LaTIS (and the ECS, if they are not already part of that baseline). It is obvious that, if allowed, the LaRC DAAC will expand the functionality of the LaTIS to meet the needs of its users. Thus, it becomes even more important to ensure that the system is covered by a technically sound set of change and upgrade processes if and when the ECS can be used.

Processes. The processes used for the LaTIS appear to be reasonably well thought out and consistent with modern engineering procedures. The DAAC uses a configuration management mechanism for identifying, implementing, testing, and installing changes to the baseline, as well as a defined end-to-end test procedure using both live instruments and simulated data. In addition, the LATIS hardware configuration includes a smaller, similar system in parallel to the main processing system where additional development and/or changes can be tested prior to cutting in a new production baseline. Thus, the LaTIS appears to be a technologically sound production system. However, the DAAC does not keep metrics for measuring its performance, making progress difficult to document.

The LaTIS presents an enigma to the DAAC. Although the system looks as though it works, it requires an infrastructure and budget for its lifetime support. Such an infrastructure will quickly be recognized as redundant with the ECS baseline once that system is installed and operational (see Recommendation 4 below).

The DAAC is experienced in the use of conventional methods of providing data to its customers. Such methods include responding to user requests by providing data on magnetic tape, floppy disk, or CD-ROM. A majority of users are now requesting that data be provided via the Internet. Statistics on users' access methods show that in nine months (December 1996 to September 1997), 70% of

users have switched from ordering data off-line to ordering data over the Internet. To serve these users, the DAAC has made good progress on developing its Web site; the panel found the Web site to be simple, straightforward, and well documented, although it can be difficult at times to find specific data sets.

Since the time of the review, the DAAC manager, Roy Dunkum, had retired and Richard McGinnis, the deputy, has become DAAC manager. Although the DAAC had only nine months to prepare for CERES/TRMM, and delays in the ECS had compressed the time in which to prepare for the AM-1 platform, Dunkum seemed confident about the DAAC's ability to handle the upcoming data streams. This assessment seems to be based on the DAAC's successes in managing existing data sets and in developing the Version 0 and LaTIS systems, but whether the DAAC can manage the ''fire hose" of data remains to be seen.

Dunkum's philosophy was that for system design, hardware is cheap and it is reasonable to buy sufficient hardware to accommodate average peak loads. For staffing purposes, a philosophy of "just-in-time" hiring has been followed because hiring staff before there is work to do wastes money and results in low morale. Just-in-time staffing, however, may make it difficult for the DAAC to maintain the high level of training that it has provided to staff in the past.

The panel perceived serious tensions between DAAC staff and the ECS contractors on-site. The ECS contractors were not invited to help prepare for the NRC site visit and they were not introduced to the panel. Uncertainty about the ECS contract is high, and the ECS contractors are worried about job security. Emergency backup plans such as the LaTIS, which work around the ECS, and proposals to replace the ECS with the LaTIS have made matters worse. Even with these morale problems, however, staff turnover (five or six individuals per year) is probably normal.

The LaRC DAAC's total budget is $7.9 million in FY 1998, with an average budget over a nine-year period of $10.8 million (Table 4.1). The main variability in the budget is related to major hardware acquisitions (e.g., FY 1996 and FY 1997 for CERES/TRMM).

To show its cost-effectiveness, the DAAC cited several factors, including just-in-time staffing; the purchase of a used and upgraded StorageTek; the rela-

tively low cost of living; the large pool of expertise in the area, which keeps relocation expenses low; and low growth in the budget, compared with the growth in data sets, data volume, projects, and granules. Quantitative measures of cost-effectiveness are not kept by the DAAC.

The DAAC has two types of contingency plans. The first, development of the LaTIS to manage CERES/TRMM data, is described above. The second is related to the "25-50-75 scenario" for processing data from the AM-1 instruments. In the event of further delays in the delivery of the ECS, NASA has decided that only 25% of the data will be processed initially. Unfortunately, interpretations of what 25% means differ between the DAAC, the ECS contractor, and the instrument teams. The ECS contractors plans to install only 25% of the hardware, but the CERES instrument team plans to process a full month of data at once every four months, which will require full processing power in order to keep up with the data streams. The panel suggests that the interested groups work together to devise a compatible implementation of the 25-50-75 scenario.

As noted above, at the time of the site visit, the DAAC had made no real preparations for the ECS. When the ECS is delivered, the DAAC will have to devote a great deal of time, resources, and development to make the systems compatible or to transition its data sets to the new system. Although the rapid development effort that led to the LaTIS is commendable, the panel is concerned

about the ability of the current instrument-specific version of the LaTIS to fit within a multi-DAAC system. On the other hand, parallel operation of the LaTIS and ECS systems is not likely to be cost-effective.

The DAAC is separated physically and programmatically from the atmospheric scientists at Langley Research Center. The DAAC is located in the Information Systems and Services Division of the Internal Operations Group of NASA's Langley Research Center. The Atmospheric Sciences Division, on the other hand, is located within the Space and Atmospheric Science Program Group. The heads of both groups report to the Langley Research Center director.

As indicated by their presence at the site visit, Langley managers are interested in the operations of the LaRC DAAC. Langley Research Center provides facilities, secretarial support, and travel support to the civil servants. In the future, the DAAC will begin ''full-cost accounting" and will have to pay for all the facilities and services it uses.

The LaRC DAAC identified two problems in its relationship with ESDIS—communications and philosophical differences. With regard to the former, UWG members complained that action items on software sent to the ESDIS Project are mostly ignored. However, the primary communication problem—that ESDIS acts as a gatekeeper for interchanges between the DAAC and the ECS contractor—has been resolved. The DAAC now discusses bugs, software fixes, and so forth, directly with the ECS contractor.

Philosophically, the DAAC does not believe that a uniform EOSDIS, which is promulgated by ESDIS, is in the best interests of its users. It therefore works to customize EOSDIS functions and to take on some of the responsibilities of the ECS contractor. For example, to use people and resources efficiently, Dunkum received permission and funding from ESDIS to provide maintenance on the ECS hardware and software already at the DAAC. The development of the emergency system LaTIS, which was built to fewer requirements than the ECS, is another example. If allowed, the DAAC would likely attempt to extend

the capabilities of the LaTIS to meet the needs of AM-1 instruments, rather than use the ECS.

In the past, all of the DAACs cooperated to create interoperability in Version 0 and the ECS, but now that system development has become the responsibility of the ECS contractor, communication between the DAACs has largely been reduced to regular teleconferences. The LaRC DAAC works with the GSFC DAAC because of instrument interdependencies, but is not proactive in marketing its own tools (i.e., the LaTIS) or learning about the tools or techniques of other DAACs. In the panel's view, these examples illustrate a weakness in the links between the LaRC DAAC and the other DAACs. The DAAC's anticipated use of the LaTIS, rather than the ECS, for upcoming EOS data streams will likely further isolate the LaRC DAAC from the system.

Although the DAAC finds dealing with the ECS contractor in Landover to be slow and difficult, it feels that the ECS contractor is becoming more responsive to the identification of bugs. Nevertheless, the DAAC does not believe that the ECS, if it is ever delivered, will meet the needs of the science teams. Not only would the ECS have to be adapted to take advantage of the new network environment (e.g., WWW, Java), but new software demanded by the science teams would also have to be incorporated into the ECS release schedule.

Despite these problems, the panel found the DAAC to be complaisant about the ECS. Indeed, with the diversion of ECS maintenance funds to the LaRC DAAC, and ECS engineers to the development of the LaTIS, the LaRC DAAC feels it has already worked around the anticipated ECS difficulties.

Important functions of DAACs are to make it easy for data providers to work with the information system and to satisfy their users. The LaRC DAAC's interactions with its data providers are superb. The DAAC even participates in the design and execution of data management aspects of the field experiments, which will help it manage the resulting data better in the long term. The DAAC's relationship with users, however, is not as strong. In particular, the DAAC could benefit from having more interaction with the atmospheric science user community. A ready opportunity to understand more about the DAAC's data sets exists through a closer relationship with the atmospheric scientists who are housed just a few buildings away from the DAAC. In addition, the User Working Group,

which is seeking a role in the EOS era, could help the DAAC learn more about user needs, as well as the utility of the DAAC's formats and tools.

Given the delays in the ECS, the development of tools to make the DAAC's data easier to find and work with will be increasingly important to the user community. The DAAC manages its existing data sets well, but to make EOS data as useful, the DAAC must continue developing its Web interface and subsetting tools. The latter will be particularly important for dealing with large EOS data sets.

The DAAC has already begun to deal with its first EOS data stream from the CERES instrument, which was launched on the TRMM satellite in November 1997. Because the ECS was not ready, the DAAC developed a CERES-specific information system, the LATIS, to manage the data. That the LaTIS appears to be working well is a tribute to the talent, dedication, and resourcefulness of DAAC staff. The use of the LaTIS, however, comes with two costs. First, the DAAC incurs maintenance costs for the information system for the lifetime of the mission. Second, the LaTIS was built to fewer specifications and a smaller metadata model than the ECS, which may pose downstream difficulties for users trying to obtain data from the different information systems. As such, the LaRC DAAC is in danger of becoming a weak link in the ultimate EOSDIS system.