); and Quality
Assurance of Data Sets (QuADS) modules.
P. M. Lyster
NASA/Data Assimilation Office
Greenbelt, MD 20706, USA
Email to lys@dao.gsfc.nasa.gov
WWW /DAO_people/lys
Abstract
This is section 4 of the GEOS-3 System Development Plan (SDP).
It was based on the Science Applications International Corporation SAIC
Common Approach SDP template.
The following sections describe the planning associated
with software development tasks and processes for the GEOS-3
Project. This is a software effort, involving up to 100
developers, that uses heritage
code at the Data Assimilation Office, and develops new code.
Most of the heritage code has been developed in-house, but there
is a significant component of non-developmental code (e.g.,
code obtained from Max Suarez and other groups at GSFC).
Software is being developed for the end-to-end system.
The overarching language is Fortran 90, which has a number
of the useful features of object-oriented programming, but does
not involve the dramatic change that porting to C++ would.
Low level functions will remain mostly FORTRAN 77.
The core compute modules, which will necessarily run on high performance
computers, are being parallelized using the portable Message Passing Interface
(MPI) library.
4.1 Organization and Resources - Software Development
4.1.1 Organization Structure - Software Development
4.1.2 Project Personnel - Software Development
4.1.3 Development Environment
4.1.3.1 Hardware Items
4.1.3.2 Software Items
4.1.4 Software Training
4.2 Software Procedures
4.2.1 Minor, Major, and Full Integration Test Items
4.2.2 Requirements and Design
4.2.3 Requirements and Design Documents
4.2.4 Timeline Summary and Description of Effort for GEOS-3.1
4.3 Software Testing
4.3.1 Test Team Methodology
4.3.1.1 Test Planning During Software Requirements and Design
4.3.1.2 Test Descriptions
4.3.1.3 Test Engineering Team Activities During Coding and Integration Tests
4.3.2 Coding and Testing at the Developers Level
4.3.3 Minor and Major Integration and Testing
4.3.4 Full and Validation Integration Testing
4.3.5 Production
4.4 Software Standards
Acknowledgments
References
The following subsections summarize the organizational roles, responsibilities, and resources necessary to support GEOS-3 software development activities.
The GEOS-3 organization is made up of scientists and engineers from NASA/Goddard Space Flight Center (GSFC), General Sciences Corporation (GSC), the NASA Center for Computational Sciences (NCCS), Numerical Aerospace Simulation (NAS) Facility at NASA/Ames Research Center in California, CRAY/SGI Corporation, the Earth Systems Science Interdisciplinary Center (ESSIC) at the University of Maryland College Park, the Joint Center for Earth System Technology (JCET) at the University of Maryland Baltimore County, and in-house computer scientists from the High Performance Computing and Communications (HPCC) program.
The overall structure of the GEOS-3 project, along with subsystem team
leaders, is listed in the following. Staff
from the various institutions are distributed throughout the
organization, and distinctions will only be made where
important.
Project Manager: Jim Stobie
Systems Engineering: The hardware of system
engineering are being coordinated by Jose Zero
(section 5 of the System Development Plan (SDP)). The software
is being coordinated by Peter Lyster.
Software Development Teams: Peter Lyster is the software manager. Software subsystems [DAO, 1997] have team leaders.
Software Testing: Meta Sienkiewicz.
System Validation: Siegfried Schubert.
Configuration Management/Requirements Engineering: Mattie Harber.
Quality Assurance: David Lamich.
The systems engineering, software development and testing, system validation, configuration management/requirements engineering, and quality assurance managers are selected and assigned by the project manager. An important role of these managers is to participate in procurement and project planning activities, to prepare the development schedule and milestones, and to estimate resource requirements. A lot of the software in GEOS-3 will be heritage code. Hence resources and coordination are required to recycle old code for MPI, and to develop necessary new code. The lack of documentation of the known problems and bugs in the old code is a troubling issue for GEOS-3 development. The software development manager works with the project manager to prepare estimates of the software development effort and resources required. As described in section 3 of the System Development Plan (SDP), an evolutionary software lifecycle approach has been adopted for GEOS-3.
Software development personnel include the software development manager, team leaders, and staff as outlined in section 4.1.1. The software development manager is responsible for coordinating all activities of the software development staff. Major activities include:
The software development manager is also responsible for training of software personnel. Minimally, the software development manager conducts meetings early in the life of the project with the software staff to discuss software requirements for the GEOS-3 system, the overall project's software engineering methods and procedures, and the relationship of software development with testing and system validation, configuration management/requirements engineering, and quality assurance.
The personnel directly associated with subsystem activities are (due to the relatively small size of the GEOS-3 project, the personnel assigned to it will be used across software development activities):
Test manager is responsible for the activities of the test, which include:
This document outlines software testing methodology at the DAO; system validation, configuration management/requirements engineering, and quality assurance are discussed at length in sections 7, 8, and 9 respectively of the SDP.
This paragraph broadly lists the numbers of staff (in parenthesis) with appropriate skill levels for GEOS-3 project. Because the main requirement of the DAO is to produce scientifically valid earth-system datasets, the majority of personnel have extensive experience in scientific computing (20+). There are also a number of staff experienced software performance optimization (10),in systems administration and database management (4), communications engineering (2), software configuration management (1), and software library development (3). The DAO also has a scientific development staff peripherally involved in the GEOS-3 project (10+). It is the requirement of the head of the DAO that all professional staff be capable of and willing to work with software at the scientific, systems, or networking level.
Allocation of resources to specific development tasks may change as dictated by cost and schedule constraints. Detailed mapping of resources to tasks will be maintained in the project's schedule rather than defined here. This will facilitate maintenance of the software plan when the schedule is re-planned as part of the project's normal risk management plan execution. Because the evolutionary software lifecycle is used, the project's schedule will be evolving and will be maintained under configuration management (CM).
The following subsections provide a brief description of the established hardware and software environment for GEOS-3. There is also a brief discussion of the future environment - this is expanded in section 5 (hardware).
The Software Development Environment (SDE) provides support for and control of the development and maintenance of the GEOS-3 software through implementation of the software plan. The SDE is used throughout the system's life cycle from requirements definition through design, coding, testing, integration, validation, installation, and maintenance. The SDE includes the hardware that hosts the SDE, the operating systems and system services, and a library of tools used to develop and maintain software products. The SDE is also used for upgrading and maintaining systems involving new operating systems, hardware, and non-development items.
Staff for the GEOS-3 project are predominantly located onsite at the NASA/Goddard Space Flight Center in Building 21 and 28 (NCCS staff), at the offsite office at Forbes Boulevard, MCC1 Building approximately 1.5 miles from onsite facilities, and at the NAS NASA/Ames Research Center in California. High speed communication links provide access between the three sites. All staff have either workstation (SGI, Sun, HP), PC, or Macintosh computers with access to color and black and white printers, and Internet connection. The core high-performance computers are at Goddard NCCS (Cray 900 series, Cray T3E with in excess of 256 nodes, NCCS mass storage,...), and at Ames (Cray 900 series, SGI Origin 2000, NAStore mass storage,...). The high performance computing associated with the Data Assimilation System Computing Environment (DASCE) and end-to-end networking facilities that access the EOSDIS Core System (ECS) will be developed and purchased during the course of the GEOS-3 project, and this is discussed in section 5 (hardware).
User interface with the DASCE will be through single-password access. It is expected that key servers at Goddard (at least molotov) and Ames (at least dixon) have a common-mounted files system such as NFS. While users have a range of hardware on their desks, they all have telnet access to the servers and computing platforms at Goddard and Ames. The configuration management file system ``/CM'' will be mounted on molotov/molotov1 servers at GSFC and mirrored at Ames.
There are no special security requirements for system hardware or software other than those required to protect from unauthorized password access, software and file tampering, and the abuse of computer time.
A wide range of tools, both commercial and freeware, are maintained and are used for source code editing (vi, emacs,...), object code generation (FORTRAN 77, Fortran 90, C, C++), code maintenance (make), configuration management (cvs, sccs, rcs), communication and networking (ftp, telnet, mail, elm, Netscape,...), visualization (ghostview, gv, xview, Vis5D,...), printing (lp, lpr,...), document preparation (Word, LaTex,...), graphics preparation (Powerpoint, showcase, xfig,...), project management and databases (Access, Project, FileMaker,...), and mathematical, statistical, and visualization (MATLAB, IDL,...). Most code developers use Unix-based workstations or X terminals, and the World Wide Web is the de facto Intranet medium. For the core compute system, MPI will be used; MPI is also available on workstations such as molotov and kiloton (both in building 21) for the purposes of prototyping. MPI has recently become a standard for message-passing software, so any development under GEOS-3 will be portable and have a long life cycle.
Scientific staff have been hired based on minimum qualifications of a University degree with courses and practical experience in scientific computing. In 1996, all scientific staff at the DAO took a course in MPI parallel programming methods given by Peter Lyster, Andrea Hudson, and John Dorband. All staff also attended a Fortran 90 class given by Andrea Hudson. Five DAO staff have taken extensive courses in optimization of software for RISC processors, which are the dominant technology for commodity-based computing (refer to section 5, hardware). Three staff members at the DAO have taken extensive courses in scientific parallel programming (using PVM, NX, and MPI). In early May and July an instructor traveled to the DAO from SGI to instruct software development staff on approaches to programming for the Origin 2000. The DAO has a number of in-house experts in scientific computing, including a PI (Peter Lyster) for a High Performance Computing and Communications Grand Challenge project. This has provided a conduit for introducing new programming concepts and procedures to the DAO. All DAO staff have taken a video course on modern software engineering procedures (Pressman tapes). A number of staff (10+) have taken extension courses on software engineering management (e.g., SAIC seminars). Mattie Harber has four years experience and training as a System Configuration Engineer, and has been a Configuration Management branch manager for two years, a CM and QA auditor and consultant for 13 years, and she has six years experience as the senior Software Configuration Management instructor for major government contractors. She is a certified engineer and former program manager responsible for providing project and requirements management for a larger Government agency.
The following subsections discuss the methods and procedures associated with the software development life-cycle. Software development activities, including peer reviews, are performed for each phase-dependent process or product.
The key aspects of GEOS-3 software development are: (i) Fortran 90 is the primary language for software development. It has a number of the characteristics of more powerful object-oriented languages like C++, such as complex data types and operator overloading. Fortran 90 provides a modular programming style that clarify dependencies through the use of modules, complex datatypes, and interfaces. Fortran 90 is preferred over C++ because of the large amount of Fortran expertise and heritage Fortran code at the DAO. Code is expected to have a long life cycle, but there is some risk due to instability in compiler technology, so GEOS-3 will have to proceed slowly; (ii) the parallel core compute system involves distributed and/or shared memory hardware with message-passing (MPI) software. The message (communication) overhead and single-processor efficiency are important to minimize wall-clock execution time and achieve primary requirement of 30 days of analyses per day; (iii) by adopting configuration management (CM) of software along with documentation and test reports using the Intranet, staff, new users, and management can coordinate efforts.
The nomenclature used in the following is consistent with the levels of testing that are defined in section 8 (CM). The minor integration test items are the modules (subroutines) that comprise a non-exhaustive list of software units. The major integration test level items (bold face in the list at the end of this paragraph) are aggregate modules that make up subsystems of GEOS-3. The full integration test items comprise end-to-end integrated system software under the Goddard Earth Modeling System (GEMS) that has been adopted by the DAO [DAO, 1997]. An automation/production library will provide make, script, and control program facilities for integration tests:
); and Quality
Assurance of Data Sets (QuADS) modules.
Some software is being developed using the C language (e.g., the parallel partitioner in the online Quality Control and PSAS). Special attention will be given to portability of the interface with the overarching Fortran 90 code.
Preliminary design involves identifying key modules to be designed or reused, and specifying their interfaces. A series of internal workshops for the GEOS-3 subsystems defined in section 4.1.1 are being held. These involve relevant software developers, scientists (usually the same), and peripherally involved DAO staff, to ensure coverage of all aspects (e.g., for the parallel GCM workshop during January it was necessary to consider the parallel issues associated with the adjoint model since that will be used for future generations of GEOS). Primary requirements have already been specified [Stobie 1997]. From this, the requirements for the GEOS-3 software subsystems are allocated and derived. Derived requirements are: functional, information, availability, capacity, data accuracy, data retention, failure contingencies, user interface, external system interfaces, performance, reliability, design constraints, and security. A design document is the traditional ``system specification'', and it has functionality and interfaces designed. Requirements and design (preliminary and complete) of subsystems are submitted to the CCB for baselining and put under CM. Other purposes of CCB review are to confirm the validity of the requirements, determine whether the design is the best alternative, and to examine the design for testability (refer to section 3 of the SDP). These are checked for completeness, and for specifications that may pose either significant risk or difficulty in implementation, so that project plans may be altered or the specifications modified if appropriate to meet the project requirements. Prototyping is ongoing, especially for the DAO where there is a time urgency and so much heritage code is being reused. In this sense, requirements, design, prototyping, and implementation are concurrent processes. Developmental MPI and Fortran 90 coding has been ongoing since 1994, thereby testing functionality of the parallel code and Fortran 90 design, and identifying risks for the risk-mitigation plan. A requirements traceability matrix under CM control is maintained throughout the life of the project.
The products associated with the software requirements analysis effort are:
The software preliminary design products are:
Usually the design and coding phases follow the specification and documentation of requirements. However the present development builds on the heritage of 30 years of atmospheric modeling and analysis. Hence, for GEOS-3 the requirements, design, prototyping, and coding phases are interleaved - new design being a reworking of old code for new science and parallel computing in response in response to the new demands of EOS. During software design, the complete software architecture is defined along with the precise inner workings of each low-level software component. Design procedures ensure that requirements are addressed and traced to upper- and lower-level requirements. Finally, the logic associated with each unit is verified and the entire detailed design is peer reviewed.
Software design activities result in the following products:
The following documents are being generated as part of the requirements and preliminary design phases of GEOS-3 software effort; this list is taken mostly from the GEOS-3 DAS Architecture Design[DAO, 1997]. ``Design'' involves definition of the relevant interfaces as well as the architecture of the complete software implementation.
The initial documents are referred to as ``preliminary design''. It is expected that they will become working documents that will ultimately be full design documents with interface definitions that are under CM. These documents will have sufficient detail that staff, new users, and management will find them useful for understanding the end-to-end system and monitoring progress of the software implementation, testing, optimization, and system validation.
The timeline for GEOS-3 has changed significantly in the past year. Originally, the project involved a complete conversion to MPI (much as the ECMWF did in the mid '90s). This conversion was recommended to the DAO by the computing review panel [Farrell et al., 1996]. However, pressures on the schedule arose because of the need to add and validate new science, the proximity of the EOS AM-1 satellite launch in June 1998, and the purchase of Origin 2000 computers at Ames (160 pes at present). At present there are two paths for DAO software:
-> GEOS-3.0 In April 1997 it was realized that the
scientific validation of GEOS-3 was jeopardized by the
conversion to MPI. Hence a separate ``reconciliation'' project was
initiated under Siegfried Schubert. In June, the DAO purchased a large
Origin 2000 computer (jimpf1 and jimpf2 - both 64 pes), augmenting the
existing Origin (turing - 64 pes) at Ames. Given that existing software
at the DAO (GEOS-2.0) has been successfully multitasked for a number of
years, it was decided to convert GEOS-2.0 to multitasking FORTRAN 77
code that would run on the Origins and the Cray J900 computers at NCCS.
This ``migration'' project has
taken about 2 months; the new code (GEOS-2.X) will be used
for scientific validation up to June of 1998.
Of the core algorithms of GEOS-2.X, the GCM will have about 40 thousand lines
of code (kloc) and
the Analysis code will have about 100 kloc.
Staff at Ames will optimize the GEOS-2.X code for multitasking and
single pe performance on the Origins.
The multitasking code
that will be used for production in June '98 will be designated GEOS-3.0.
The multitasking software
development (science and engineering) will be run by Siegfried Schubert's
group.
Arlindo da Silva and Ricardo Todling will coordinate the major integration,
full integration, validation, and testing.
A lot of the validation of GEOS-2.X will continue the present series
of runs, however new science (new land surface model, online transport,
and TOVS retrievals) must also be added. For GEOS-3.0 no new science
will be added beyond January 16 1998. David Lamich is responsible for
developing the GEOS-3.0 production environment in preparation for
the EOS AM-1 launch in June 1998.
The project will report to the CCB under Jim Stobie.
Careful CM (especially software version control) and the oversight of the CCB and SSB will be needed to avoid irreparable divergence of the GEOS-3.0 and GEOS-3.1 paths. Timelines and baselines are authorized by the CCB and put under CM on the Intranet.
There will be considerable reuse of serial FORTRAN 77 code in GEOS-3. Only the highest level subroutines and drivers will be converted to Fortran 90. In the context of GEOS-3, this means that: functions and data that are functionally related are combined into modules with defined complex datatypes; large arrays may be allocated and deallocated in memory if necessary (only in high-level subroutines); common blocks will be replaced by modules (static or allocated memory); data dependencies will be made more clear through subroutine bindings; and code reuse of modules is encouraged. Because this is a substantial undertaking, and because the behavior of Fortran 90 compilers is uncertain, this process will be taken slowly, with considerable prototyping of code. The core compute codes (GCM, Observer, and PSAS) dominate the MPI requirements. The following bullets summarize the level of effort required to perform the conversion to MPI with a moderate level of Fortran 90. At the establishment of a formal integration test environment, all codes will come under CM. David Lamich is responsible for automation/production and Ken Ekers is responsible for the preprocessing/postprocessing software. This document covers generic software procedures. However, because the parallel (MPI) effort represents a substantial change for the DAO in terms of both science and software, the following paragraphs outline the work associated with each major integration test level leading up to (MPI) GEOS-3.1:
are mature. There is some work required
to generate the software for QuADS, and for automating the postprocessing
for the production
system, especially for the five custom modes of operation (first look analysis,
final platform analysis, reanalysis, pocket analysis, and 10-day forecast).
Code will have to be profiled and ported to DASCE workstations.
The levels of software integration testing are defined as (see section 8, CM):
The DAO will be integrating with several external entities - EOSDIS Core System (ECS), DAACs, etc. These external interfaces will produce their own separate test cycles (not necessarily their own software repositories). These interfaces are being detailed by the Preprocessing/Postprocessing group.
Typically, software project requirements are used to determine the amount, type, and formality of testing and validation activities; all tests and validation activities trace to top-level requirements. For GEOS-3, a moderate amount of new science is being added. The project is oriented mostly at generating a new software (some of which is parallel) with a long life cycle in a changing hardware environment. Tests are aimed at stabilizing the computing environment at Ames (hardware, OS, etc.), and later at optimizing for hardware and software performance. Later, as new science is added, more sophisticated tests will be needed as described in section 7 (testing and validation).
As discussed in section 4.2.4 (summary of timelines), staff at Ames and Goddard will coordinate interdependent tests. This coordination is aided by software Configuration Managemnet (section 8, CM).
Typically for large projects, integration testing is performed by an independent team to ensure neutrality, especially during the integration phases. Because of the relative small size of GEOS-3, there is no separate testing team. Some independence in software testing and system validation will be gained by testing and validation manager's oversight; CCB is aware of the activities. At the minor/major/full/validation/ production levels, datasets and code maintained under CM.
During the requirements analysis phase of software development, the principle activities of the test team are to: 1) assist software development to solidify a set of verifiable software requirements, and 2) begin developing an appropriate high-level test approach. The test manager will participate in scheduled internal requirements reviews, as described in section 4.2.2, until a set of requirements can be agreed-upon.
Once a reasonable set of preliminary requirements has been established, the test team proceeds with development of a Software Test Plan (STP).
The test plan defines the test organization and its responsibilities, the test environment, the overall test strategy, appropriate testable assertions about the software (i.e., test conditions), and the detailed schedule for testing.
The test strategy describes the levels of testing to be performed, the general approach to testing, and the test coverage to be achieved. The GEOS-3 project testing will include: minor integration, major integration, full integration, and system validation tests.
The test schedule is developed bottom up based upon estimates of the magnitude of the test effort, e.g., test materials development, test execution and results analysis, and the initial software development schedule. The test schedule includes a scheduled peer review (preparation, conduct, and follow-up) of each test material, i.e., the test plan, test descriptions, and every test procedure. Each test activity is preceded by a test readiness review to ensure the test is ready to commence (precedent actions are done, test environment is ready, etc.)
Where appropriate, software requirements are decomposed into a set of testable assertions about the software product, i.e., test conditions and/or variations. These assertions form the basis of the formal test effort. Each test is traced to an associated requirement in the requirements traceability matrix. The matrix lists each agreed-upon requirement, the assertions about that requirement that will be verified, and how the assertions will be verified (inspection, demonstration, test). Because testing is a highly resource-intensive activity, only the most relevant and meaningful assertions about each requirement will be tested. Since testing is in the business of finding errors, the decision to test or not to test - as early as possible within the life span of the module - is a critical one. Risk analysis is maintained routinely by the CCB.
The approach that will be followed for developing testable assertions for the GEOS-3 project is as follows: where there are minimal changes to the science, most tests will be for optimizations of the computing system and software, and roundoff-accurate regression tests will be sufficient. The scientific tests will be coordinated by Siegfried Schubert's validation group.
A test traceability database will be established on the Intranet to coordinate and monitor test activities.
Regression-tests need to be planned for cases where multiple changes occur in different parts of the developmental software, and where problems associated with interdependencies may arise.
The completed test plans (at all levels of integration) undergo peer review at least once with leaders of the software subsystems, and other testers. The baselining effort is associated with lead approval, CCB approval, or SSB approval, in accordance with the assigned decision making authority for that level of testing. Results will be baselined under CM.
If changes to the approved system/software requirements are proposed during the course of the project, the test impact will be assessed along with other project impacts before a decision to change the requirements is made. Reports are made to the GNATS Change Reporting System (CRS) now operational on the DAO intranet. If, for example, the requirements are subsequently discovered to be untestable, contradictory, or ambiguous, proposed changes to the requirements will be documented by software development or test teams and processed in accordance with section 3 of the SDP that discuss change control procedures. Furthermore, if the approved requirements do change, the test plan, test descriptions, and procedures will be revisited and updated accordingly following stated change control procedures (see Section 8, CM).
Test descriptions represent high-level designs for test procedures. Test procedures include references to the allocated system/software requirements and testable assertions. Each test description outlines the steps required to perform the tests, the expected results, the approach to be used to evaluate the results, and the pass/fail criteria for each test. Before the test descriptions are used to develop executable test procedures, a series of peer reviews are conducted to ensure that the test descriptions are documented in sufficient detail to be able to produce adequate test procedures. Once each test description successfully completes review it is baselined and placed under CM as described in section 8.
While the software development team is translating the approved design into executable code, the test team is translating approved test descriptions into executable test procedures, developing, acquiring and loading test data, conducting tests, recording unit test results, and documenting discovered defects for use by the developers to correct.
Once again, a series of peer reviews is conducted to ensure that the procedures are defect free and do not waste test resources, i.e., machine time and tester labor. Once the test procedures are successfully reviewed, they are baselined and placed under CM as described 4.3.1.1 and in section 8.
Units will often be heritage code. In the present limited-time environment, reuse is encouraged, initial modifications minimal, and coding is ongoing. Unit coding and testing is coordinated by respective software team leaders (section 4.1.1).
Fortran 90 is the overarching language, with considerable FORTRAN 77 code reused, and parallel C libraries interfaced to Fortran 90 code. Reused code are tested (``black box'') statically against reliable (regression) datasets. New code is tested (``white box'') statically for functionality; all new paths will be executed during this phase. The same regression tests can be used when the algorithm is not expected to give different scientific results. Peer reviews will be ongoing, and significant results or discrepancies will be reported to the Change Reporting System (CRS) and summarized on the DAO intranet.
Integration testing is generally structural in nature (i.e., ``white box''). However, there may be some functional integration testing techniques applied also, as well as stress/performance testing techniques. Integration testing ensures that: 1) the design elements interface properly with one another, and 2) the resulting software increments or ``builds'' are sufficiently stable to make formal, independent testing viable and cost effective.
The products associated with minor and major integration and testing activities are:
Ames integration focuses first on stabilizing the computing environment, and thereafter optimization of the hardware and software as discussed in section 4.2.4 (timelines summary). GSFC staff work first on stabilizing interfaces, and gradually migrating to new science and validation.
As part of the delivery process between Ames and Goddard, staff at the beginning of each phase agree on CM items (source code regression datasets) and how divergent codes will be maintained and merged.
Validation level of testing will involve ongoing optimization of software and hardware, testing the end-to-end production environment leading up to EOS AM-1 launch in June 1998, and validation of new science under the validation manager.
Aside from the important technical details of testing - verification and baselining of interfaces, hardware and software optimizations - testing also verifies that the code performs according to the GEOS-3 requirements [Stobie 1997].
Test manager conducts initial meetings with software development and quality assurance teams to agree on test protocol.
The overall objectives of the minor, major, full, and validation integration test team are to:
The production system must be built to work in both a real-time environment (e.g., EOS AM-1 launch capacity in June 1998), and reanalysis mode. The DAO will use its own experience in production (e.g., the current POLARIS mission support) as well as studying the activities of meteorological centers such as the National Centers for Environmental Prediction (NCEP) in Maryland and the European Center for Medium Range Weather Forecasting (ECMWF) in the United Kingdom. Algorithmic exceptions need to be handled and procedures defined and put in place for handling real-time problems. A single-image, web-based, batch system will be used for production.
Considerable heritage code is being used for GEOS-3. Some effort will be applied to ``cleaning up'' old code (e.g, at least applying useful comments and a standard DAO subroutine/module prologue) Scientists at the DAO have experience in developing code, and the details of minor software item design and implementation will be left to the respective software leads. This means that the data and control interfaces for the major integration items are important. The plans for integration center around a modified version of the GEMS concept of Maxwell Suarez. The system architecture document[DAO, 1997] and the requirements and data design of the core GEOS-3 Data Assimilation System[Sawyer, et al., 1997] define the interfaces for the DAO system. The coding standards of the DAO, dealing with such issues as reproducibility of results, is included in this document as an attachment. This document is under review and will be updated to reflect (at least) Fortran 90 design and implementation procedures.
This document was initially baselined by the DAO Configuration Control Board (CCB), chaired by Jim Stobie, in July 1997.
/subpages/office-notes.html
/subpages/atbd.html
/subpages/office-notes.html
/subpages/office-notes.html