Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 195
Review of NASA'S Distributed Active Archive Centers APPENDIX C CGED Interview with ESDIS (September 1997) PART I. What does ESDIS expect of the DAACS? [questions based mainly on the EOSDIS DAAC Strategic/Management Plan, hereafter referred to as Plan] 1. Relationship with scientific user community. Science advisory groups have been established to ensure that the data and information services provided by the DAACs meet the needs of the science community (Plan, section 2.4). How well are the DAAC advisory groups working? To what extent is their advice coordinated with advice from other scientific advisory groups? In general, the DAAC User Working Groups (UWG) have been very effective in providing DAACs with guidance as to their individual strategic plans and priorities for functionality and content. These priorities are particularly helpful with establishing holdings of the DAACs, as well as in determining needed community outreach. This effectiveness is illustrated by the efforts of the DAACs to respond to the recommendations that come out of the UWG meetings and the willingness of the UWG to make recommendations to NASA on behalf of the DAACs. In particular, the DAACs are required to obtain
OCR for page 196
Review of NASA'S Distributed Active Archive Centers their UWG's concurrence on their annual work plans prior to submission. These plans are used by the ESDIS Project as input to the negotiation of budgets and work priorities. In addition, UWG membership has been fairly stable, despite the investment in time required to participate in regular meetings. We conclude that the members feel that this activity is a reasonable investment of their time, either for ensuring that their own needs are met or that the wider communities' needs are met. With respect to the latter, UWGs make particular efforts to ensure that the group's composition represents a cross-section of the potential user community. The other advisory groups advise as to EOSDIS capabilities, and, therefore, indirectly the DAACs, as the long-term institutional base for the EOSDIS. The coordination between these groups is mainly via NASA, with additional informal coordination by way of dual participation in the meetings of these advisory groups. Several of the DAAC UWG members are also members of the EOSDIS Data Panel which is responsible for advising the ESDIS Project in overall direction and priorities in serving the science community. In addition, DAAC Project scientists and DAAC Managers participate directly in the Data Panel meetings. DAACs are kept informed of any advice Project receives from other science advisory groups such as ESSAAC [Earth System Science and Applications Advisory Committee], NRC Panels, ERG [EOSDIS Review Group]. 2. System development. Each DAAC is responsible for determining whether extensions to existing ECS system capabilities are necessary (Plan, section 3.1.2). Have the DAACs responded to ESDIS with proposals for system improvements or prototyping? Which of these have been incorporated into EOSDIS? DAACs have suggested and been funded to perform system improvements and prototypes via both their annual work plans and more formal proposals to the ESDIS Prototyping Manager. The latter proposals are more directed at solutions for evolving ECS (and are reviewed by the EOSDIS Data Panel), while the former have been more directed towards building and improving V0 [Version 0].
OCR for page 197
Review of NASA'S Distributed Active Archive Centers Two ''official'' prototyping activities are currently in an early implementation test phase at the GSFC DAAC. They are 1) U. of Maryland dynamic query preview capability in the V0 IMS [Information Management System] browse interface and 2) Georgia Tech web-accessible case-based reasoning help tool based initially on V0 user requests to the DAAC help desk. The query preview capability was also incorporated into the ECS JEST tool. ECS has funded prototyping activities with universities, including UAH [University of Alabama, Huntsville] (partnered with the GHRC [Global Hydrology Resource Center] at MSFC [Marshall Space Flight Center] has developed and operated the Hydrology DAAC) to implement subsetting which was incorporated into their products. DAACs have participated in the various reviews of ECS development and in EOSDIS working groups addressing the design and operation of the ECS. Discussions of extensions (especially additional data products) have started in some UWG meetings, and it is expected that these plans will become better defined once the ECS is operational, the DAACs have experience in working with ECS and its interfaces, and standard products are regularly generated. 3. System integration and testing. Hughes has missed several deadlines for releasing new versions of the EOSDIS software. All of the DAACs expressed concern about these delays. With the available ECS software, are the DAACs ready to receive, process, disseminate, and archive EOS data? If not, what are the likely impacts on specific DAACs and instrument teams? The initial delivery of ECS software to the DAACs (the Pre-Release B Testbed) is supporting the initial testing of science software within the DAAC environment. The August demo version of ECS will be installed at the GSFC DAAC in late October to support early operator training and science software testing in single thread scenarios. A test version of the system will be deployed at GSFC and EDC in January 1998 and at LaRC and NSIDC in February 1998 to support science software integration and testing in the production environment and to support critical interface testing. This will support preparations for operational readiness in mid-May (GSFC, EDC) and mid-June (LaRC, NSIDC). Following the launch of AM-1 at the end of June and Landsat-7 in early July and the subsequent instrument turn-on period, the DAACs will be ready to receive, process, distribute, and archive data.
OCR for page 198
Review of NASA'S Distributed Active Archive Centers To mitigate any risk of further delays in ECS, teams of ITs [instrument teams] and DAACs have been developing Emergency Backup Systems to support minimal production and distribution of products for 6 months following the launches of AM-1 and Landsat-7. The EOSDIS Alternative Implementation Path has also been studied with inputs from ITs (and DAACs) as a contingency against a failure to deliver the full ECS, 4. Operations. During the V0 timeframe, the DAACs are responsible for all local operations, including data reception, product generation, cataloging, archiving, distribution, and reprocessing, as well as defining staffing and resource requirements (Plan, section 3.5.2). How well V0 is performing? How much of the anticipated demand can be met by V0? What lessons learned from Version 0 have been incorporated in EOSDIS? Version 0 has been very successful in providing data to the users, as is illustrated by the metrics in our monthly reports. However, V0 has minimal real-time ingest (ASF the exception) and product generation requirements. The LaRC and GSFC systems are being augmented to support CERES processing for TRMM, but a major development would be required to provide an automated production environment sufficient to support MODIS and to provide the production on demand functions required for ASTER. With the Version 0 systems, the DAACs are currently managing a volume of data comparable to only 6 months of AM-1 and Landsat-7 data. A major expansion would therefore be required in the data management systems and archive capacity. Furthermore, while fully distributed, the Version 0 systems do not provide an evolvable architecture. Development would be required at several of the DAACs to support PM-1 and follow-on missions. At the start of the ECS contract, a Version 0 "lessons learned" paper was developed by the Project and the DAACs and used to guide the ECS planning. The DAAC's experience in Version 0 has also guided ECS through their on-going involvement in design reviews and working groups. For example, much of the Version 2 metadata model and user interface look-and-feel is derived directly from the corresponding V0 items and community feedback on these items, including the on-going V0 Web user interface project. Some of the most important lessons to be incorporated from the V0 effort into Version 2 work have been processes for soliciting and incorporating community feedback into Ver-
OCR for page 199
Review of NASA'S Distributed Active Archive Centers sion 2 development. This has been particularly important with regards to working metadata and user interface issues. The DAACs generate products and/or distribute products that were generated by the instrument teams. What successes and problems have been associated with these activities? DAACs have successfully worked with PIs [principal investigators] in defining and producing various Pathfinder products, products from existing flight missions such as ERBE and SAGE. NSIDC's work with EASE-Grid has been highly praised by the user community. The DAACs are working with the Instrument Teams in the integration and testing of science software into the ECS environment. This collaboration is working very well. There has been one instance where a key ECS member was not available at a DAAC during an Instrument Team visit and the communications needed to obtain backup support did not follow the planned procedure, but the process has been corrected to avoid a similar problem. How well are the DAACs documenting, reporting, and resolving operational problems within a DAAC or between DAACs? Weekly telecons of the DAAC Managers and quarterly face-to-face meetings, facilitated by the ESDIS, give opportunity for reporting and resolving problems, as well as a mechanism for addressing common problems or assisting each other. For example, recently NSIDC found that it could provide the GHRC (previously operating the Hydrologic Cycle DAAC) much needed spare optical platters. DAACs worked together to smoothly transition data sets into their various archives when it became necessary to close the Hydrologic Cycle DAAC, while continuing cooperation with the GHRC (the hosts of the Hydrologic Cycle DAAC). Other on-going cooperative efforts allow DAACs to obtain data streams needed to meet their requirements (for example, SSM/I data from MSFC to NSIDC, other products between EDC and NSIDC, and between GSFC and LaRC). No major problems have bubbled up to the attention of the ESDIS Project. For both ECS IR-1 delivery (January, 1996) and ECS Pre-Release B Testbed (April, 1997), a conflict resolution system has been in place to report, document, track and facilitate the resolution of problems and issues found in the activated ECS, at each DAAC. Once documented, a committee comprised of representatives from ESDIS, HAIS [Hughes
OCR for page 200
Review of NASA'S Distributed Active Archive Centers Applied Information Systems Corporation], and each DAAC meet, via telecon, to clarify new problem reports, determine the status of outstanding problems, and determine strategies to resolve the more difficult problems. In addition, after Instrument Teams (ITs) and DAACs completed their Science Software Integration and Test (SSI&T) operational activities on ECS IR-1, each DAAC/Instrument Team contributed to the ESDIS produced document entitled: ECS IR-1 SSI&T Lessons Learned. This document is an excellent account on how to avoid unforeseen problems when integrating science software into the ECS. SSI&T is an ECS activity that will continue as long as science software is improved and/or science analysis evolves. A call for lessons learned from SSI&T into the ECS Pre-Release B Testbed has been made, and inputs are currently being gathered from the ITs and DAACs The Zraket report noted that the DAACs have little if any budgetary control in the ECS. What budgetary and staffing discretion does ESDIS allow the DAAC managers? Separate budgets are established for each DAAC for meeting high-level requirements, and each DAAC, within the guidance of its UWG, has discretion in determining how to most effectively meet those requirements. In addition, DAACs often successfully propose additional work over and above the budgetary guidelines. The DAACs have worked closely with the ESDIS Project in developing operations staffing and transition plans whereby a significant portion of the budget originally assigned to ECS has been transitioned to the DAACs for operation of the ECS-delivered system at the DAACs. The DAACs have opportunity to provide input to ESDIS's evaluations of the ECS Contractor's performance, and a DAAC representative sits on the ECS Contractor's Performance Evaluation Board (for fee determination). 5. User support. Given the fragmented responsibility between the DAACs and the instrument teams, how are the DAACs expected to provide user support on technical issues related to data quality and product generation? The responsibility of the instrument teams is to develop algorithms and software for generating the standard products, and perform opera-
OCR for page 201
Review of NASA'S Distributed Active Archive Centers tional quality assessment on the data products as they are produced. Instrument teams may request the DAACs to help in the quality assessment, but the ultimate responsibility for data quality rests with the ITs. User support from DAACs are for both "push" users (i.e., the instrument teams) and "pull" users (consumers of data). In support of the "push" users, DAACs support the Science Software Integration and Test process both initially and for any subsequent updates. DAACs and their respective ITs have worked out the SSI&T procedures and identified their respective responsibilities. The ESDIS project has facilitated this process through SSI&T workshops. ECS Contractor provides any support needed in the SSI&T process since the science software has to work in the software environment developed and delivered to the DAACs by the contractor. To support the pull users, DAACs are expected to be aware of the products they hold, their characteristics, utility, anomalies, etc. We recognize there is a learning process involved here and the Instrument Teams are expected to provide some initial help in getting the DAAC personnel educated about the specifics of their products. The ITs are also responsible to provide the appropriate documents (ATBDs [Algorithm Theoretical Basis Documents], Guides, etc.) to the DAACs for storage and distribution along with the products. During the initial months of a product's existence, there will be need for consultative assistance from the ITs to the DAAC user services personnel. This is part of the scientists' responsibility in publishing their data. Providing this assistance in the beginning to the DAACs will relieve them of the long-term burden of supporting user inquiries. 6. Science software development, integration, and test. The science software produced by EOS investigators is integrated into the DAAC production environment, where it is tested to verify its readiness for operational product generation (Plan, section 3.7). How much software integration and testing has taken place? Each DAAC has been an integral part of, and is in concurrence with, all discussions involving Science Software Integration and Test (SSI&T) schedules, plans, and instruments and algorithms. Although the goal is to perform SSI&T on all science software before launch, it is essential that science software to perform these high priority functions, be integrated and tested with ECS.
OCR for page 202
Review of NASA'S Distributed Active Archive Centers The largest effects that ECS delivery delays have had on science software is in the area of better understanding the ECS/Science Software interfaces. Delayed ECS leads to delayed SSI&T, and thus a delay in understanding of these interfaces. The final result is a delay or postponement of implementing enhancements to the interface and Science Software. Sometimes lessons learned from one delivery are barely known in time for the next delivery. Fortunately, the primary interface between ECS and the Science Software is the Science Data Processing Toolkit which has not suffered any delays. Delays in the readiness of ECS has not affected the science software readiness schedule. To what extent are the science teams behind on their software deliveries? How has the readiness schedule been effected by the delays in delivery of the ECS software? [Note: this question was not answered.] 7. Science data planning. To what extent has the DAAC experience with user interests and satisfaction affected NASA's planning for future product generation and product support services? The DAAC experience has led NASA to fund the DAACs to perform various services, including a CD-ROM sampler which can be useful to a large segment of the user community and prepackaged data sets which save users effort. In addition, the DAAC experience has emphasized the needs for establishing common formats to help the users, as well as lower costs of providing services. PART II. What do the DAACs expect of ESDIS? [questions based mainly on advance team visits to the DAACs] 1. Relationship with scientific user community. The EOSDIS Project Scientist (Skip Reber, formerly Steve Wharton) brings science issues related to the DAACs to the attention of the relevant science advisory groups (Plan, section 2.4). How well does this process resolve conflicts in priorities or gaps in communication between the DAACs and the science producers?
OCR for page 203
Review of NASA'S Distributed Active Archive Centers A Data System Working Group (DSWG) chaired by the EOSDIS Project Scientist facilitates communication and action among the instrument teams, DAACs, and the ESDIS Project. Members of the DSWG include representatives from the ITs, DAACs and the ESDIS Project. Representatives from the "pull" user community have been included in the meetings as well when relevant. This group is especially important to resolving priorities when there are budgetary limitations, as well as resolving data product needs. For example, when the ECS deliveries were delayed and development activities had to be replanned, this working group was called on to assist in developing a list of functional priorities for ECS Releases B.0 and B.1. Also, a recent meeting was held of the DSWG to resolve metadata issues and answer several questions that the ITs have had regarding their responsibilities in providing metadata. (Due to the approaching launches of Landsat-7, AM-1 and SAGE-III, a high priority has been placed on getting the system ready for data producers and addressing issues related to generation of standard products.) 2. System development. The Zraket report noted that the DAACs have little control over the management of the ECS or its future evolution. Indeed, some DAACs said to the CGED advance teams that the ESDIS response to their questions and comments takes so long that it is not possible to contribute meaningfully to ECS development. One DAAC noted that the DAACs and ESDIS worked collectively to implement Version 0, but that there was little opportunity to contribute to the development of Version 2. How do you respond? ESDIS has followed a different paradigm for the development of Versions 1 and 2 from that for Version 0. (Last December, the responsibility for Version 1 development to support the TRMM launch was shifted from the ECS contractor to the Goddard and Langley DAACs due to schedule slips by the contractor and to help focus the contractor's attention on Version 2.) For Versions 1 and 2, the system development was not subdivided into parts that DAACs were independently responsible for and a part that was to be developed collaboratively. The rationale for this was the need for a large common core system infrastructure-thus the EOSDIS Core System (ECS). It was felt that duplication of the extensive functionality needed to handle the required automation, throughput, etc. would be too expensive with distributed development. This approach ensured that the DAACs were involved in the development of the ECS by involving them in all the ECS design and requirements reviews (several DAAC personnel served on each review board)
OCR for page 204
Review of NASA'S Distributed Active Archive Centers and workshops (most DAACs had several personnel attend each of five user interface workshops), various design/operations working groups, provided liaisons (science and system engineering) to the DAACs from the ECS contractor, and provided additional funds to each of the DAACs to support up to 3 FTEs for interacting with the ECS contractor. Through their participation on review boards, the DAACs have made many suggestions for changes to system functionality (e.g., ability for end users to retrieve parts of science software packages), implementation (e.g., placement of browse data on higher performance archive) and architecture (e.g., location of product request handling in the system) that have been incorporated into ECS. Recently, ESDIS also made the DAACs part of the newly formed Integrated Test Program, wherein the DAACs will play an integral role throughout the ECS test life-cycle, not just operations. In replanning the ECS Release B development, the DAACs were involved (along with the ITs) in setting the priorities, reviewing the detailed functionality allocated incremental releases, in setting the success criteria for the August demonstration, and in reviewing the August demonstration. There has been a growing need on the part of the DAACs to gain a better understanding of how ECS will function in order to plan their operations. The August demonstration provided this perspective and has elevated this planning to a new level. 3. System integration and testing. The DAACs are expected to participate in system tests, assess the results, and recommend the acceptance of any deliverables (Plan, section 3.2.2). However, several DAACs feel that ECS is a moving target with large uncertainties in what will be delivered to the DAACs and when. How can the DAACs test a system for which there is no complete picture and which changes constantly? A Test Methodology Working Group, which includes ESDIS Project personnel from the DAAC and Science Operations addresses this issue. It is defining the inputs to testing (such as system documentation) and the types of test that must be performed by various groups. The DAAC managers are kept abreast of the status of this group and solicited for their input through the weekly DAAC Manager's Telecon and the weekly DAAC Operations Working Group.
OCR for page 205
Review of NASA'S Distributed Active Archive Centers 4. System management. The ESDIS Project is responsible for establishing user service, data products, and processing requirements for the DAACs (Plan, section 3.3.1). How much weight should the DAACs place on providing user services to the general public? DAACs are guided by the priorities set by the "EOS Execution Phase Project Plan," a contract between NASA Headquarters and GSFC. This document provides the "Level 1 Requirements" for all the EOS-related Projects including EOSDIS. The pertinent requirement here is: The EOSDIS shall provide Earth science data and information services to the EOS investigator community, the broader Earth science community, policy makers, the education community and the general public in that order, commensurate with resources. However, it is expected that under the current budget DAACs can support the general public. This does not mean that DAACs are expected to spend a substantial proportion of their budgets to support this segment of the user population. In fact, DAACs have discovered that some small-scale activities can meet many of the needs of this segment. However, DAACs are not funded to duplicate or compete with the other outreach activities conducted by NASA, or other government agencies. If a DAAC has ideas for a substantial activity it is advised to propose to these other groups (such as NASA's education outreach group) or through their own institutions (for example, University of Colorado at Boulder). Recently, the EOSDIS Review Group sponsored by NASA HQ reviewed the high-level goals of EOSDIS and revised this requirement as follows (in their draft report): (C) By processing, archiving, and distributing environmental data, EOSDIS will support the following user communities: National and international agencies and entities with whom NASA has written agreements or legal obligations concerning MTPE data NASA-funded MTPE investigators Members of the broader U.S. and international Earth science community U.S. policy makers
OCR for page 206
Review of NASA'S Distributed Active Archive Centers If levels of support are sufficient, the following communities will be served to the extent possible: The U.S. education community The general U.S. public Others While this change in requirements has not been formalized yet, the service to the general public is at a lower priority than that to the other categories of users in both the present and revised versions of the requirements. Also, NASA has a commitment to education, and some level of support to the U.S. education community will be provided, even if resources are not sufficient to cover categories (a–d). The ESDIS Project is also responsible for overseeing the hardware systemwide, but some DAACs are concerned about having the appropriate technology to support the transition from Version I to Version 2. How do you respond? Technology selection is based on, among other things, buying hardware as late as possible to take advantage of price/performance improvements, maximizing processing power and storage capacity to meet requirements, facilitating porting of instrument team software from science computing facilities, and supporting software compatibility from version to version within ECS. 5. Operations. Several of the DAACs noted that the attention of ESDIS and Hughes has been strongly on systems development, rather than on operations or maintenance of the system. Will the transition to an operational mode with more focus on the DAACs occur in a timely and smooth manner? Are sufficient funds available to support long-term system maintenance? The transition to operations is not occurring at the most optimum time because of the development delays. However, through the Test Methodology Working Group mentioned above, we are attempting to ensure that operations needs are met as best as possible given the other circumstances. In addition, we have found it difficult to justify our operations and maintenance budgets. This means that budgets continue to erode, as in many areas, but in particular this area. This is a problem in that there is not functionality that can easily be cut to solve the budget problems. We are going to have to do a better job at justifying these budgets. However,
OCR for page 207
Review of NASA'S Distributed Active Archive Centers it may take actual cost data, as opposed to our models to convince the decision-makers of this need. The ECS contractor assigns some staff to the DAACs, but the level of contractor support can be very unstable. Why not allow the DAACs to do their own recruiting? The ECS Contractor was originally requested to provide staffing for all DAACs with major operational responsibility for EOS instrument data, with expectations that operations would be transitioned to the DAACs at a later date. This set the stage for the operations concept for the system to be developed: How many people would be required, at what skill, etc. Recently DAACs were given the opportunity to move up this transition, and three DAACs have taken advantage of this opportunity: NSIDC, JPL, and LaRC. (The JPL and NSIDC plans were approved by the ESDIS Project a couple of months ago; the LaRC plan was approved over a year ago.) EDC (except for user services) and GSFC have declined to take on this responsibility until later in the operations phase. And even the DAACs that took advantage of this opportunity requested that certain functionality continue to be provided by the ECS Contractor. In addition, the ECS Contractor has been working with DAACs to ensure that personnel recruited work well in the DAAC environment. 6. User support. The DAACs, in consultation with their User Working Groups, are responsible for evaluating user needs (Plan, section 3.6.2), but at least one DAAC said that ESDIS inserted different priorities, thus inhibiting interaction between the DAACs and their users. How do you respond? NASA may sometimes have to direct DAACs to support additional requirements for programmatic reasons, such as commitments to other agencies or foreign partners. If additional funds do not come with these requirements, then ESDIS and the DAACs must accommodate the requirements by diverting resources from items of low priority. Such decisions should be made with the cognizance of the DAAC's UWG. The SMP [Strategic/Management Plan] addresses this possibility in a section on ''Developing Priorities for Data Set Support.''
OCR for page 208
Review of NASA'S Distributed Active Archive Centers 7. Science software development, integration, and test. The attention of the instrument teams and EOS project has been strongly on algorithm development, rather than on smooth and consistent operations. At least one DAAC noted that frequent changes in algorithms are inconsistent with the production of readily interpretable time series. How will an appropriate balance be assured when the system becomes operational? The priorities in the early stages of the mission (several months after launch) will be on instrument and algorithm checkout. Therefore, there is a need for frequent changes. However, when the algorithms are more stable and it is scientifically meaningful to produce standard products routinely, the operations will be more consistent and smoother. In "steady state" operational setting, it is at the SCFs [Science Computing Facilities] that the frequent updates to algorithms will be implemented and tested, and it is after they are certified that the software migrates to the DAACs. The ECS-delivered to the DAACs is sized to accommodate operations in parallel with I&T [integration and test] of new versions of algorithms. Decisions to reprocess data on a large scale will be made by the Data Processing Resources Board chaired by the EOSDIS Project Scientist (Skip Reber) and with representation from the science community including the ITs. Some DAACs thought that the instrument teams were reluctant to provide documentation on the algorithms and quality control methodologies used in processing data products, making it difficult for the DAACs to serve their users. How will ESDIS ensure that the instrument teams provide the necessary documentation to the DAACs? The ITs are required by their contracts to provide Algorithm Theoretical Basis Documents (ATBDs). In addition, through the DSWG meetings, the ITs have been persuaded to provide simplified Guide documents about their instruments and products. Through a QA Working Group set up under the auspices of the DSWG, the Project has been working with the ITs and DAACs to ensure that the ITs provide their QA plans and make their requirements on the Project and the DAACs known, and identify and resolve any related problems. 8. Contingency planning. Several of the DAACs feel that the ECS is overdesigned (i.e., one-stop shopping) and may even be an obstacle that the DAACs have to "wire around." Given
OCR for page 209
Review of NASA'S Distributed Active Archive Centers the delays in ECS development, could the DAACs work together to evolve a unified system? It would be difficult for the DAACs to develop such a system in support of AM-1 or Landsat-7. DAACs can somewhat scale their current systems to address some particular needs, as the LaRC and GSFC DAACs have to support TRMM instrument data while allowing the ECS Contractor to concentrate on the bigger problems of AM-1 and Landsat. However, they would have difficulty meeting the larger processing and data requirements of AM-1, Landsat-7, and future missions with the various V0 systems, without the infrastructure to be established with the ECS. The ECS has been designed with the premise that originated from the science community's advice that one-stop shopping (i.e., consistent searching and ordering/accessing data at multiple locations) was a desirable thing to do in support of interdisciplinary science. Requirements have been discussed with the various advisory groups in order to determine whether any of the requirements could be relaxed. The EOSDIS Review Group has suggested some potential modifications, however no group has recommended dropping the one-stop shopping requirement. This requirement is particularly valuable for the larger user community which does not currently have access to large amounts of NASA data. (Also, while one-stop shopping is often cited as a function that could be reduced to save a significant amount of money, it is not a cost driver.) When the ECS development is completed, it will provide a scaleable, adaptable, and evolvable architecture that is easily extended to support new missions and data products. It will be highly automated, support user access to information without requiring knowledge of data center holdings, and permit DAAC-unique extensions to support individual science discipline needs. If time permitted the development of independent systems by the DAACs to meet AM-1 and Landsat-7 data loads, the DAACs could evolve an interoperability layer as was done under Project leadership in Version 0. However, ECS provides a lower level of interoperability, for example, support for product generation fed by data product subsets from other DAACs. As a contingency, the instrument teams are constructing their own, homegrown processing systems that are independent of EOSDIS. What steps will be taken to involve the DAACs in this development?
OCR for page 210
Review of NASA'S Distributed Active Archive Centers Strictly speaking, the word EOSDIS in this question should be replaced with ECS. The ESDIS Project has funded each of the ITs to develop Emergency Backup Systems without depending on any of the yet-to-be-delivered ECS capabilities. Each IT was asked to propose an appropriate teaming arrangement with DAACs to ensure that, through the period of launch through 6 months thereafter, the IT/DAAC team could produce, archive and distribute the minimal set of data products necessary to checkout, calibrate and validate their instruments and algorithms. (Note that performance requirements are greatly relaxed for these backup systems.) It was left to the ITs to determine the best teaming arrangements in each case. The following is the set of teaming arrangements that has resulted: ASTER: Data processing at JPL SCF; Archival and storage at EDC DAAC [L1 processing occurs in Japan, data are shipped to and archived at EDC; EDC sends small subset of L1 data to JPL SCF per JPL IT's request; JPL SCF produces higher level products and transfers to EDC DAAC for archival and distribution] CERES: Data processing, archival and distribution occurs at Langley DAAC using the "Langley TRMM Information System (LaTIS)" appropriately augmented to provide additional capacity needed for early months of AM-1 data processing. MISR: Processing at JPL SCF; archival and distribution at Langley DAAC. MODIS: Processing at MODIS TLCF at GSFC; archival and distribution through GSFC, EDC and NSIDC DAACs for the appropriate products MOPITT: Processing at NCAR SCF; archival and distribution at Langley DAAC. PART III Other issues [questions based mainly on the Zraket report] 1. Several key management positions are vacant at NASA HQ and Goddard. For example, some of the DAACs feel that the departure of Dixon Butler left a vacuum, and all are concerned that Charlie Kennel has not been replaced. This issue was also raised in the Zraket report. How do these vacancies affect the long-term stability of EOSDIS?
OCR for page 211
Review of NASA'S Distributed Active Archive Centers Dixon Butler certainly left a vacuum. Some DAAC UWGs are concerned that, although they were originally chartered by NASA HQ, NASA HQ no longer gives them any guidance. Dixon's vision, initiative, and leadership helped develop and communicate a common purpose. His programmatic responsibilities now reside in the Science Division at Headquarters and in the MTPE Program Office at Goddard. However, the science leadership for developing the objectives for EOSDIS is now very ably provided by Skip Reber, the EOSDIS Project Scientist. Skip has taken an active role, for example, in establishing processes for setting priorities and allocating EOSDIS resources to science products. The-long term stability of EOSDIS will depend on the success of the system in satisfying science user needs and on user acceptance of some of the compromises necessary to achieve a broader good (e.g., the acceptance of metadata and format standards and system capabilities needed to make data usable by a broader community). 2. Who has end-to-end responsibility for making sure that the relationship between the science (people and knowledge) and EOSDIS is going smoothly? Skip Reber, the Acting EOSDIS Project Scientist is responsible for this. H. Ramapriyan, Chief of the ESDIS Science Office provides Skip Reber with the necessary support from the Project. The ESDIS Project Manager, Rick Obenschain, is responsible for assuring that EOSDIS meets science requirements within budget and schedule commitments. 3. What do the EOS investigators (instrument teams and interdisciplinary investigators) think of their DAACs? From the comments we have heard at the Investigators' Working Group meetings and other science advisory groups' meetings, the DAACs and the services they have been providing are being viewed quite favorably. This is also evidenced by the demand for the DAACs' services from the user community. Further evidence is the intense resistance we saw from the community when a change to a "Hub and User Services Centers" concept was proposed by the Project about two years ago as a cost-saving measure. Similarly, UWGs include EOS investigators, and in general the UWGs are very happy with their DAACs, as evidenced by various letters of recommendation received by the ESDIS Project and MTPE. The investigators' willingness to continue to be associated with the UWG,
OCR for page 212
Review of NASA'S Distributed Active Archive Centers and the required time commitments, imply that the investigators think this is a worthwhile effort. 4. NASA has apparently implemented the architecture recommendations of the Zraket report. Is ESDIS going to be able to meet their responsibility for provision of system-wide software that implements the new EOSDIS architecture? The August 28th ECS demonstration showed that the current ECS software can perform all critical data ingest, archive, management, processing and distribution functions as defined by the EOSDIS community. Furthermore, it showed that the current ECS software can support the at-launch data ingest rates for all DAACs. Although additional performance tuning and development are needed to support the AM-1 and Landsat-7 launches, ESDIS feels that these results show it will be able to fulfill its responsibility for provision of system-wide software that implements the new EOSDIS architecture. NASA is also working with DOE to support analysis of the reusability of elements of ECS to support the ARM program. 5. The Zraket report noted that a substantial effort is being made within EOSDIS through the Pathfinder program to reprocess data important for global change research. What lessons learned from the NASA Pathfinder program have been incorporated into EOSDIS? The Pathfinder program resulted in two categories of products: Software and science algorithms developed to reprocess satellite instrument data to higher level products, and the resulting long-term global datasets. Science algorithms have evolved as science analysis techniques, research interests, and technology has moved forward. Pathfinder algorithms have certainly contributed to these factors, as EOSDIS science algorithms become more developed. In addition, Pathfinder algorithms were used in the early ECS prototype work. The prototype development represented a generic, stand-alone processing environment using the design concepts from Pathfinder, as well as other data processing systems. The prototype was demonstrated using real Pathfinder processing algorithms, both as heritage algorithms and as encapsulated within the SDP Toolkit. Another early ECS study was aimed at analyzing the performance of the SDP Toolkit with the Pathfinder SSM/I precipitation rate algorithm
OCR for page 213
Review of NASA'S Distributed Active Archive Centers (FORTRAN 77) obtained from NASA/MSFC. The ability to use toolkit functions in a parallel symmetric multiprocessing environment was also investigated using an SGI CHALLENGE XL with 8 processors. Pathfinder data production systems were developed to be robust and operable for specifically known, finite datasets. Many of the broad challenges that EOSDIS is required to meet, such as being evolvable, flexible, extensible, interoperable, etc., were not applicable to Pathfinder software development. In addition, although the Pathfinder data production systems provide several lessons learned, the heart of the EOSDIS implementation challenges results from requirements that have never been implemented before. Specifically, EOSDIS is a distributed system, where each site is required to produce, archive, and distribute data in conjunction with other sites; science software is dependent on products from other science teams; the information management system is very sophisticated to satisfy the broad and very diverse user community; a coordinating infrastructure is required; and capacity and throughput requirements on both the push and pull sides of the system are very high. The resulting Pathfinder datasets have been invaluable to EOSDIS development. In particular, AVHRR data was utilized by the ECS Science and Technology Lab (STL), to assess various processing technologies (DCE, workstation multiprocessors, MPPs, etc.), evaluate and validate hardware architecture for PGS, and share lessons learned with the science community. This was also done in cooperation with the High Performance Computing and Communications (HPCC) Program, to make use of MPP technologies. Several DAACs were involved in initial pathfinder data processing activities (NSIDC, GSFC, EDC), and nearly all DAACs are at least involved in or planned to be involved in archival and distribution of Pathfinder products. The Pathfinders have been extremely popular, and have pointed out the need for consistent data sets, at the price of sacrificing potential improvements in the data sets which were discovered later in the processing. The DAACs and the PIs also gained experience in developing processes needed to determine if and when data sets should be reprocessed. 6. The Zraket report concluded that, given the complex funding authority and organization control, the overall coordination of EOSDIS activities would be cumbersome and time-consuming. What is the current chain of command for decision making? For funding?
OCR for page 214
Review of NASA'S Distributed Active Archive Centers The DAACs provide annual proposals with work priorities and budget requirements to the ESDIS DAAC Systems and Science Operations Manager, Greg Hunolt. Greg Hunolt has a budget for all of the DAACs (except for ASF, which is managed separately), and has the authority to allocate funds in response to the DAAC proposals. If a good case exists for increased funding, he can provide justification for use of contingency funds to the ESDIS Project Manager. Once their budget submissions are approved, the DAACs have authority to allocate funding to accomplish the proposed work plans. What are the responsibilities of ESDIS to NASA HQ? Of NASA HQ to ESDIS? The ESDIS Project is responsible to the MTPE Program Office at Goddard and ultimately to NASA HQ to meet Level 1 requirements and to support science user needs within budget and schedule commitments. NASA HQ and the MTPE Program are responsible to the ESDIS Project to assure that requirements are consistent with the budget. 7. The Zraket report recommended that products should be designed and controlled in part by the scientific and other "customers" of the system. What has been done to implement this recommendation? The set of standard products is established by the science community. The product generation algorithms and software are developed and delivered by the science community. The priorities for resource allocation for processing and reprocessing the products are governed by the science community through the Data Processing Resource Board (DPRB) chaired by the EOSDIS Project Scientist. The instrument teams and interdisciplinary teams have their own computing facilities where they produce new innovative products (research or special products) that may eventually become standard products. In response to the recommendations from the BSD/CGCR [Board on Sustainable Development/Committee on Global Change Research] from the summer of 1995, the MTPE has further expanded the role of the science community (and others for extensions to applications domain) in generation of products through the WP [Working Prototype]-ESIPs, the proposals for which are now under evaluation. These are meant to provide an extra measure of innovation in both science and technology. In addition, some DAACs have or are planning to generate additional products as recommended by their UWGs which represent the general user community. This would fall within the scope of DAAC-unique functions the DAACs are expected to develop.
Representative terms from entire chapter: