AIPS++ note 176 Copyright (C) 1994,1995,1996 Associated Universities, Inc. Washington DC, USA. Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this document under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this document into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the AIPS++ Consortium. The AIPS++ consortium may be reached by email at aips2-request@nrao.edu. The postal address is: AIPS++ Consortium, c/o NRAO, 520 Edgemont Rd., Charlottesville, VA. 22903-2475 USA. =============================================================================== AIPS++ Development Plan This draft is a proposal which will be formally discussed (and possibly modified before adoption) at the AIPS++ Steering Committee meeting on 16 December 1994. R. Simon, Project Manager J. Noordam, Chairman, AIPS++ Steering Committee 1 December 1994 Table of Contents 1. Introduction 1.1 Background 1.2 Development Overview 1.3 Layered Development for AIPS++ 1.4 Phased Development in AIPS++ 2. Management Structure 2.1 The AIPS++ Consortium 2.2 AIPS++ Steering Committee 2.3 Project Manager (PM) 2.4 Project Administrator 2.5 Project Computer Scientist 2.6 Project Astronomer(s) 2.7 Project Editor(s) 2.8 The AIPS++ Center 3. Infrastructure Development 3.1 General principles 3.2 Infrastructure Components 3.3 Infrastructure Milestones 4. Application Development Streams (ADS) 4.1 Application Development Streams 4.2 Interferometry ((u,v) plane) Calibration and Imaging (UVCI) 4.3 Single Dish Calibration and Imaging (SDCI) 4.4 Image Analysis (IMAL) 5. AIPS++ Aware/Compliant Applications 5.1 Visualization Applications 6. Software Development Procedures 6.1 Built-in Growth and Renewal 6.2 Code Acceptance Procedures 6.3 Change Control 6.4 AIPS++ Workshops, Schools, and Meetings 6.5 Unresolved Issues 7. AIPS++ Long Term Development Strategy 7.1 Current Consortium participation 7.2 Expansion to local development groups 7.3 Development of an AIPS++ Programmer Community 7.4 Outside AIPS++ Code Development 7.5 User Support 8. Project Milestones 8.1 Phased Development Approach 8.2 December 1994: Extended Review 8.3 Version 0.5 (Alpha Release) 8.4 Version 0.9 (Beta Release) 8.5 Version 1.0 (First Full Release) Appendices: AIPS++ Policies Appendix A. AIPS++ Consortium Agreement Appendix B. AIPS++ Mission Statement Appendix C. Copyright and Licensing Policy Appendix D. Platform support policy 1. Introduction 1.1 Background The AIPS++ project is an attempt to create the next generation data reduction and analysis package for Radio Astronomy. Its origins can be traced to concerns within NRAO and other institutions that current data reduction packages do not provide the flexibility and future potential desired, despite the present success of these packages (e.g., 'Classic' AIPS, which is used very widely). Because such an undertaking has become too large for a single institute, seven radio institutes (ATNF, BIMA, DRAO, NFRA, NRAL, NRAO, TIFR), which among them represent the majority of large radio synthesis telescopes worldwide, have joined forces in an AIPS++ Consortium. The AIPS++ Consortium aims to resolve the dilemma that faces developers of astronomical data reduction packages: packages which are large enough to serve the needs of a broad section of the radio astronomical community are difficult to write, distribute, and maintain if only the resources of a single institution are available. For example, many of the software modules in a large package are relatively mundane, but still must be available in each and every package which is developed. There is a significant gain in efficiency if many institutions can join forces to create a common data reduction package. This approach will avoid duplication of effort, and allow more effort to be concentrated on advanced problems in data reduction and analysis. A consortium approach to software development also resolves another problem: a common software package will allow astronomers to easily use a variety of instruments, and also ease combination of data from multiple instruments. A comprehensive software system can thus serve as an important communications tool between astronomical instruments and their users. The many advantages of developing a common package for data reduction are balanced by various concessions which must be made to a large distributed organization like the AIPS++ Consortium. First, communications between programmers scattered among remote sites are more difficult; the effort to keep the various groups informed and up to date is a necessary cost for a project like AIPS++. This cost is balanced (we hope) by an even greater benefit, namely the wide applicability which AIPS++ applications hope to achieve. Second, an approach to software development which is more formal than customary in the past in Radio Astronomy is required. This may limit the efficiency of individual programmers somewhat, but should be balanced by the increased robustness and stability of the code. The AIPS++ project started in earnest in January 1992. Since then, the infrastructure has made considerable progress, but the design and implementation of astronomical applications has lagged behind. Without going into the details, some of the lessons learned have of course influenced the current Development Plan. The most important difference with earlier plans is the splitting up of the application domain into a number of semi-independent 'Application Development Streams (ADS)'. 1.2 Development Overview This development plan rests on four cornerstones to make it happen: (1) Developing true programmability in AIPS++ by insuring that application development can and does occur away from the Project Center; (2) Supporting infrastructure development and coordinating application development with a strong, well-staffed Project Center; (3) Adopting a layered approach to AIPS++ development; and (4) Providing for built-in growth and renewal in AIPS++. The most important strategic goal of AIPS++ is to serve the needs of the various Consortium instruments. Obviously, the key to this is "programmability", which allows the Consortium members to control their own destinies by writing the software they need. Key applications for particular instruments must be developed by groups closely associated with those instruments. By providing both an infrastructure with a rich set of tools, and coordinating the development of broad application Frameworks for specific areas, AIPS++ will achieve its goals for programmability. An important mechanism for insuring AIPS++ programmability will be to strongly encourage the development of AIPS++ applications outside the AIPS++ Center. In this way, the Consortium institutes (and others) are forced to develop the capability to write their own applications, and the Center is forced to coordinate and support them properly. (This of course does not mean that the Center should not write any applications at all.) This approach also satisfies the practical constraint of where people are actually located. Because of the size and variety of its community, AIPS++ must also have a conscious policy for "built-in growth and renewal". It should be possible to gradually improve the design of the various application "Frameworks", and there must be room for radically new ways to process the same data. This will be achieved by strongly encouraging the development of a broad community of AIPS++ knowledgeable programmers and placing a high priority on maintaining the stability and backwards compatibility of the AIPS++ system. 1.3 Layered Development for AIPS++ AIPS++ has adopted a simple, layered model for its development. The bottom layer is identified as "AIPS++ Infrastructure" and will form the basis for other developments in AIPS++. Infrastructure, in this context, refers to those classes and modules required for building applications, and as well as general utilities, code distribution and management functions, programmer documentation and guides, and so on. From a programmers' perspective, the infrastructure will contain key classes and modules that are generally not specific to any particular application area. Examples of key classes in the AIPS++ Infrastructure include classes for math functions, arrays, the AIPS++ table system, coordinate and image classes, I/O classes, command line interface classes, basic graphics infrastructure, and system related classes. On top of the infrastructure level reside a several Application Development Streams. At this writing, three semi-independent Application Development Streams have been identified for the first full release of AIPS++. Each of these streams address a particular area which needs its own data structures, basic data models, and standard processing methods: Interferometry (where data is taken in the (u,v) plane) Calibration and Imaging (UVCI), Single Dish Calibration and Imaging (SDCI), and Image Analysis (IMAL). Their relationship is shown in the simple diagram below. A fourth application development area, Visualization, has evolved into a slightly different category: an "AIPS++ aware" application. The Visualization application development effort (abbreviated VISU in the diagram below) will result in applications which have tight communications with the rest of AIPS++, but will also have the capability of operating independently of AIPS++. The Application Development Streams are largely independent from each other (but not from the infrastructure), and can thus be dealt with separately. AIPS++ Aware Applications have a greater independence from the AIPS++ Infrastructure. In the future there will be more application development streams and AIPS++ aware application development groups, if necessary, to cover new fields (such as optical interferometry?) or new applications (specialized applications for use on high performance computers?). Other new application development streams may represent alternative approaches to the problem domain of an existing Development stream. The latter development would demonstrate the ability of AIPS++ to renew itself. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +--------+ | | +--------+--------+--------+ | VISU | | | | | | | | UVCI | SDCI | IMAL | +-+----+-+ | | | | | | +--+--------+--------+--------+----+----+----+ | | | AIPS++ Infrastructure | | | +--------------------------------------------+ Simplified diagram of the basic development structure for AIPS++: This simple figure emphasizes to relationship between AIPS++ Infrastructure and the application development streams presently planned for AIPS++. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1.4 Phased Development in AIPS++ Section 9 of this document describes in detail the basic development phases for AIPS++. In brief: AIPS++ is currently (November 1994) focusing on infrastructure development, guided by limited application development. This phase comes to an end with the "Alpha" release of AIPS++ in early 1995. The focus then shifts to application development, with the expansion of groups focused on particular application development areas (such as interferometry, single dish, and image analysis). Infrastructure development will continue, concentrating on expanding the basic system and finishing areas of the infrastructure which were not essential for initial application development. This phase will end with a "Beta" release of AIPS++ in mid 1995. After that, the project moves into a phase which concentrates on completing, testing and debugging the basic suite of AIPS++ applications, and completing the user environment for AIPS++. Depending on how smoothly and successfully development has proceeded, this will lead to either an initial public release of AIPS++ in early 1996, or perhaps a second Beta release in early 1996 with the initial release later in 1996. 2. Management Structure 2.1 The AIPS++ Consortium The AIPS++ project is being carried out by a consortium of seven radio observatories. The Consortium has been established by a memorandum of understanding between the seven organizations involved (see Appendix A for the details of the Consortium agreement). In brief, the current (November 1994) members of the AIPS++ Consortium are: AIPS++ Consortium Members ------------------------- _______________________________________________________________________________ Member Institution Contact ------------------ ------- CSIRO / Australia Telescope National Facility Ray Norris rnorris@atnf.csiro.au Neil Killeen nkilleen@atnf.csiro.au Berkeley/Illinois/Maryland Array Richard Crutcher crutcher@uiuc.edu Herzberg Institute for Astronomy / Tony Willis Dominion Radio Astronomy Observatory twillis@drao.nrc.ca Netherlands Foundation for Research in Astronomy Jan Noordam jnoordam@nfra.nl National Radio Astronomy Observatory Richard Simon rsimon@nrao.edu Nuffield Radio Astronomy Laboratory Dave Shone dls@jb.man.ac.uk Tata Institute of Fundamental Research Ramesh Sinha sinha@gmrt.ernet.in _______________________________________________________________________________ 2.2 AIPS++ Steering Committee The AIPS++ Steering Committee (SC) represents the Consortium members, and has ultimate authority over AIPS++ Project policy. The SC provides general guidance to the Project management. In particular, the selection and prioritizing of the Project goals and policies require consultation with the SC. The SC is also responsible for periodically reviewing progress of the project. From time to time, the SC may arrange for external experts to review the project, since the SC may be to close to the project to have a proper perspective. (Many SC members serve as either local site managers or programmers for the project, is addition to their duties as SC members.) The SC appoints a Chairman, who maintains regular contacts with the Project Manager. It is admissible that the Project Manager is also the representative of a Consortium member, and thus a member of the SC. The Project Manager cannot be SC Chairman, for obvious reasons. The SC meets at least twice a year, alternately at a site that is convenient for the Center, and at a Consortium site. Urgent SC business will be conducted by Email and telephone conferences. SC members should think creatively in providing the Project Manager with the necessary resources for the project. They have the responsibility for insuring that the Institution they represent meets its obligations under the AIPS++ Consortium Agreement. 2.3 Project Manager (PM) The Project Manager (PM) for AIPS++ is the head of the Project, and is responsible for the timely success of the Project. As a practical matter, the PM must be located at the Project Center (see below). The primary role of the PM is to take an overall view of the Project, to pursue the Project Plan, to identify any obstacles or shortcomings, and to take whatever steps are necessary to overcome these. The PM must also assume the following responsibilities and duties: - Supervise and manage the Center personnel, in association with the Project Administrator. - Coordinate the work being done at the various sites with that done at the Center. - Request the necessary (and timely) resources and contributions from Consortium members. - Arbitrate in case of a conflict. - Write a progress report for each Steering Committee meeting. - With the Chairman of the AIPS++ Steering Committee, establish the agenda for each steering committee meeting, coordinate and prepare all the necessary input papers, and arrange for minutes of the meeting. Project Manager of AIPS++ is a full time job. 2.4 Project Administrator The Project Administrator shall serve in a support role under the direction of the PM. The Project Administrator provides tactical guidance to the Project (in contrast with the PM's strategic guidance), with the following primary responsibilities: - Establish manpower and money budgets for the AIPS++ Center, and administer these once they have been allocated, in consultation with the Project Manager; - Develop and maintain a detailed project schedule; - Monitor the progress at each site with respect to the assigned tasks and schedule milestones; - Coordinate design, development, implementation, and documentation preparation activities between the Center and the sites; - Compile and distribute monthly progress reports, including analysis of the progress with respect to the Project schedule; - Attend and actively participate in technical meetings of the AIPS++ Center. 2.5 Project Computer Scientist The Project Computer Scientist is the Architect of AIPS++, and shall (under the broad direction of the Project Manager): - Take full responsibility for the design and implementation of the necessary AIPS++ Infrastructure. - Participate in the design of the frameworks for the various Application Development Streams. - Insure that AIPS++ functions on all appropriate hardware and software platforms. - Insure that all system oriented documentation (e.g., class documentation, programming guidelines, etc.) is correct. 2.6 Project Astronomer(s) Since it will not be easy to find people who are capable to cover the entire spectrum of AIPS++ applications, each Application Development Stream is expected to have a separate Project Astronomer. Their primary goal is to insure the astronomical applicability and correctness of the AIPS++ product. Project Astronomers will have varying levels of involvement in AIPS++, depending both on their availability and on the demands placed on them by the Application Development Stream with which they are involved. The Project Astronomer(s) shall (under the broad direction of the Project Manager and the Application Development Stream leader): - Take full responsibility for the establishment of requirements, including consultation with the Consortium partners and the astronomical community at large; - Organize and participate in the thorough testing of AIPS++ applications; - Evaluate the quality, suitability, and robustness of the infrastructure code necessary for the development of applications; - Insure that all end-user documentation (e.g., cook books, reference manuals, help systems) is written and is correct. 2.7 Project Editor(s) Documentation is of crucial importance to AIPS++ for two reasons. First, the distributed nature of AIPS++ development means that programmer documentation is important even during the development phases of the project; code acceptance procedures presently in place aim partly to insure that adequate programmer documentation and tutorials are available for development. Beyond that, user documentation covering all aspects of AIPS++ is vital. The goal is comprehensive documentation of AIPS++ tasks and procedures, guiding both novice users through standard procedures as well as experts through more subtle uses of AIPS++. A distinction exists between programmer level documentation and user level documentation; both may use the same underlying implementation, but user level documentation must carefully aim at a broad spectrum of users. Full documentation of AIPS++ and its core routines will require the efforts of one or more Documentation Editors as well as expert users. The Project Editor(s) shall, working closely with the Project Manager, the Infrastructure group, and the Application Development Stream leaders: - Organize the broad framework for AIPS++ Documentation, including guides, tutorials, and detailed documentation for programs, tasks, and algorithms. - Work with the Project Manager and the Project Administrator to organize and assign documentation tasks to a variety of individuals, as needed. The Documentation Editor is not responsible for writing the documentation, but is responsible for identifying and prioritizing the needed documentation. 2.8 The AIPS++ Center The working definition of the AIPS++ Center is: the single place where the Project Management resides, and where most of the infrastructure is produced. The concept of a strong AIPS++ Center is extremely important for the success of a widely-flung project like AIPS++. The Center is hosted by one of the member institutions. It provides the following key functions: - Project Office, consisting of the Project Manager, the Project Administrator, the Project Computer Scientist, the Project Editor, and their support staff. - Development of the AIPS++ Infrastructure, including support of and coordination with Application Development Streams and developers of AIPS++ Aware applications; - Training at various levels for AIPS++ software developers; - Extending and maintaining the base libraries; - Managing the repository of the AIPS++ source code, including code distribution to Consortium sites or other sites, and code acceptance and review procedures; - Managing the AIPS++ Documentation system, and the documentation flow between the Consortium members, the Center, and the user community; - Manage AIPS++ operations under the control of a designated Head of Operations, including release distribution, user registration and support, user schools and training, management of user-submitted code, and related functions (details on AIPS++ operations will be discussed in the future document "AIPS++ Operations Plan"); - The execution of special studies, in coordination with other Consortium members; - Review of designs and implementations done by the Center or other members. 3. Infrastructure Development 3.1 General principles The AIPS++ Infrastructure provides the basic wherewithal for building applications and allowing Users' interaction with those applications. It is the primary responsibility of the AIPS++ Center, although major contributions have been made and will continue to be made from other Consortium sites (individuals or groups working on infrastructure-related tasks outside the Center must share the responsibility for close and continuing communication and cooperation with the Project Center). Until a viable development environment for AIPS++ applications is completed, AIPS++ Infrastructure must receive the highest priority within the project. As the AIPS++ project moves from a focus on the infrastructure to a focus on application development, stability of the infrastructure will become increasingly important. Backwards incompatible changes to the infrastructure software (affecting applications or application developers) must not be allowed except for unavoidable exigencies which have to be planned for carefully, and managed with utmost care, coordination and caution. 3.2 Infrastructure Components Details of the AIPS++ Infrastructure philosophy and design are presented in the document "The Design of AIPS++", and individual parts of the Infrastructure are described in a various documents, including "Libraries Overview", "AIPS++ Class Reference Manual", "Table Reference Manual", "Array Tutorial", "FITS Tutorial", and "Graphics Display Infrastructure", all of which are available from the AIPS++ documentation system. The infrastructure for AIPS++ divides into two broad categories: AIPS++ System infrastructure, and AIPS++ Astronomical infrastructure. Under the System infrastructure category, the following key areas are included: - Tables, table storage & storage management - Array and Lattice Classes, Mathematical libraries, and related classes (linear algebra, Sorting, gridding, FFT, rotation, projection...) - FITS Classes, (and eventually other interfaces to graphics and data storage standards, including general data conversion classes) - Processing environment (Glish & Command Line Interface [CLI], and Graphical User Interface [GUI]) - Control and Communications system (Glish, with extensions) for process control and communications, links to semi-independent applications, class binding to CLI, binding of FORTRAN and/or C to AIPS++ classes and tables - Infrastructure graphics (basic vector and raster graphics), - Documentation, automatic documentation extraction (On-line and hard- copy), user tutorials, programmer tutorials, documentation for system installation, and change reporting - Code acceptance and check-in procedures, coding standards, code documentation standards - Code Distribution and management, revision control, automated testing - Various aspect of release preparation and support, including release packaging, installation procedures, and software problem reports (bug reports) and their resolution - Compiler and system architecture support - System level infrastructure, Operating System interface Under the Astronomical infrastructure category, the following facilities will be included: - units classes (defining standard units and conversions), - coordinate classes (implementation of astronomical coordinates and coordinate system), - generalized image class (multidimensional, full coordinates, with various associated methods), - generic data structures (Basic (u,v) / Visibility set support, Single Dish support, spectroscopy, polarimetry, ...) 3.3 Infrastructure Milestones Infrastructure development will move through three different phases during the coming year. The following summarizes which parts of the AIPS++ Infrastructure will be ready for the various release. Note that most of the infrastructure is available with the Alpha release, to allow application development to proceed, and that most of the required components for the Alpha release are complete at this time (November 1994). Alpha Release (early 1995): - AIPS++ Table system, with early storage managers - Array and Lattice Classes, Mathematical infrastructure, and related classes - FITS Classes - Glish, with bindings to a few selected classes - Limited user interface tools (simple parameter editing and storage, basic data catalog system, basic history logging and processing history) - Basic Infrastructure graphics (simple raster and vector graphics display) - Documentation system with fully standardized Programmer documentation for selected critical classes, some programming tutorials, class browser, partial class reference manual - Code Distribution and management, revision control, code acceptance procedures, automated testing - Release preparation and support - Support for SunOS, Solaris, IBM/AIX, and SGI operating systems - units classes - coordinate classes - generalized image class (initial version), - generic data structures (Basic (u,v) / Visibility set support, Single Dish support, ...) Beta Release (mid-1995): - AIPS++ Table system (improvements and optimizations) - Processing environment (Glish & Command Line Interface [CLI], and initial Graphical User Interface [GUI], along with the capability to run some applications in stand-alone mode from a normal UNIX shell) - Installation procedures for multiple architectures, compilers - generalized image class (enhanced version), Initial Public Release (or second Beta Release) (early 1996): - AIPS++ Table system, with phase 3 storage manager (optimized disk table storage) - Documentation system with full, standardized class documentation, user and programmer tutorials, bug / gripe handling 4. Application Development Streams (ADS) 4.1 Application Development Streams AIPS++ Application Development Streams (ADS) are semi-independent groups which are responsible for using the AIPS++ Infrastructure to develop applications relevant to particular problem domains. At the present time, three areas for ADS efforts are planned: Radio Interferometry Data ((u,v) plane data) Calibration and Imaging (UVCI), Single Dish Calibration and Imaging (SDCI), and Image Analysis (IMAL). An ADS will typically involve efforts of programmers at many sites, and must coordinate its efforts with those at the AIPS++ Center. It is worth noting that substantial application development in AIPS++ must occur away from the Project Center, close to the users and consumers of data. The goals that AIPS++ has for programmability and for wide use demand that the Project strongly encourage the development of strong programming groups outside of the Project Center. Practical considerations also encourage this approach; it is unlikely that any single group would have either expertise or the motivation to support all possible applications in a particular area. Thus adoption of this approach is dictated by the reality the project faces: many small to medium-sized institutions working together to create AIPS++. Workers in an AIPS++ ADS will develop the framework which will apply to problem domain of the ADS. Applications with wide utility to the community will become part of the framework an ADS creates; specialized applications created by individuals concerned with a particular instrument or technique will be extensions or enhancements to the standard approach of an ADS. An ADS will not usually be associated with only a single Consortium member, but could bring together a worldwide group with members from across the project (and perhaps outsiders as well). In order to help AIPS++ application writers in an ADS "over the threshold", a super-critical group for each ADS will be formed for an initial kickoff period for each stream. These groups will be hosted by some of the larger Consortium members. After working together in one place for several weeks or months, programmers are expected to be able to continue writing applications in their own institutes, and to train others. This approach has the additional advantage that they learn to speak the same language, and thus to overcome local cultural differences. In this way, the initial focused effort will result in a long term effort aimed at the problem domain of the ADS. The success of this approach depends on several conditions. An ADS must develop a clear structure before beginning its kickoff period, with 2-3 individuals to lead the process, and others to implement and extend the ideas of the leaders. The ADS leaders will carry the responsibility to coordinate internally (UVCI is an example of how we want things to go in other areas), and the Project Center will carry the responsibility to support them. The ADS must work closely with the AIPS++ Project Center, to insure both that the existing AIPS++ Infrastructure is used as designed, and to insure that shortcomings in the infrastructure are identified and corrected. The leader of an ADS must therefore be in frequent communication with the project management, to insure that the work of the ADS goes smoothly. Strong coordination between the ADS and the Project Center is essential, and is the responsibility of both the leader of the ADS and the Project Manager. The AIPS++ Center must in turn be responsive to an ADS, particularly during the intensive kick-off period, when many individuals' efforts are focused on the ADS. Finally, the ADS's will require that various parts of a competent and stable infrastructure are available at different stages of their development. An important benefit of separating application development into Application Development Streams is that small groups can be assembled to focus on particular problem domains. This approach fosters the development of applications in locations other than just the Project Center, so that AIPS++ can achieve responsiveness to the needs of its (future) user community. Major observatories must be able to control their own destinies, and can not afford a complete dependence on software developed elsewhere. The ADS approach insures that many institutes will be able to develop local or specialized applications that work within the AIPS++ environment. This avoids a situation where a single institution dominates development in a particular package, leaving other institutions to largely fend for themselves. With AIPS++, development is being strongly encouraged at sites away from the Project Center. 4.2 Interferometry ((u,v) plane) Calibration and Imaging (UVCI) The UVCI Application Development Stream will define the basic data structures used for (u,v) plane data, and define and implement the standard data models within those structures. In January 1995 a focused effort will begin which will implement this framework and also develop standard applications for (u,v) data (this effort will build on prototyping efforts which have already occurred). All Consortium members are planning to participate at various levels, so the result will be a general framework and specific applications for processing such data. This UVCI framework will be extensible to cover the special characteristics of particular Consortium instruments. These applications will be included with the Beta release of AIPS++ scheduled for mid-1995. Plans for the UVCI ADS are described in more detail in the document "Development Plan for the Interferometry (UV-plane) Calibration and Imaging (UVCI) Application Development Stream of AIPS++". 4.3 Single Dish Calibration and Imaging (SDCI) The basic goals for this development stream are to create the data structures and applications necessary for the processing and analysis of Single Dish data. This arena has been pushed forward (slightly in advance of all the necessary infrastructure) in order to create a set of example applications for the Alpha release, and to help test and identify unintended limitations in the general AIPS++ Infrastructure. Fairly extensive Single Dish capabilities will be available for the Beta release. Details of the SDCI effort are presented in the document "SDCI: Single Dish Calibration and Imaging". 4.4 Image Analysis (IMAL) The fundamental goals for the Image Analysis Application Development Stream are to implement a set of standard image processing algorithms into AIPS++ using the AIPS++ libraries and the AIPS++ Image Class as a foundation. These applications will be broadly aimed at allowing users to extract desired statistics from their images, including such operations as component fitting, moment maps, rotation curves, and other functions. In the sense used here, image analysis refers to the generalized concept of an image, thus including one dimensional spectra and three dimensional spectral image cubes as well as more traditional two dimensional images. A related goal is to create a framework which allows the development of advanced image analysis algorithms for specialized purposes. Plans for an image analysis ADS are being formulated at the time of this writing (November 1994). Ideally, the intensive kick-off effort for the IMAL group will occur in about March 1995, just after (or perhaps coincident with) the Alpha release of AIPS++ in early 1995. This development stream will eventually become very broadly based, requiring significant cooperation between numerous sites, the leader/coordinator of the IMAL effort, and the Project Center. 5. AIPS++ Aware/Compliant Applications Certain types of applications in AIPS++ (for example, advanced visualization or interaction with telescope control systems) are more easily developed if a tight coupling to the AIPS++ Infrastructure is not enforced. For these sorts of applications, a narrow but well defined interface to the rest of the AIPS++ system may allow rapid progress to be made, and may allow the creation of stand alone applications, or applications suitable for specialized high-performance hardware. The linkage will occur through the communications facilities provided by Glish, and perhaps via the mutual sharing of various classes in the AIPS++ Infrastructure. These applications need adhere strictly to AIPS++ programming standards (for documentation, interface specification, coding standards, and so on) only to the extent that the developers want ultimate support for such applications to be assumed by the AIPS++ Center. There are several possible reasons for adopting this approach. First, some applications will be extremely beneficial to AIPS++, but can also be useful to the astronomical community at large, in a stand-alone mode (note that this may also be true for some core AIPS++ applications). Second, some organizations prefer to contribute well identified pieces of a package, to satisfy local constraints. The concept of "AIPS++ aware" applications meets this need. Finally, some applications which make use of specialized (proprietary) software libraries or hardware capabilities may need a loose coupling to AIPS++ for maximum effectiveness, even though they cannot be distributed as part of the generic AIPS++ distribution. Applications written in languages such as FORTRAN or C which are designed to access AIPS++ data via Glish are also an example of when a loose coupling to AIPS++ would be beneficial. The AIPS++ Center and groups developing AIPS++ aware applications will share the responsibility for coordination, and must cooperate to specify the interface between the AIPS++ aware application and the rest of the AIPS++ system. 5.1 Visualization Applications The first example of an AIPS++ aware application will likely be the visualization tool ("AipsView") which is being developed by the AIPS++ group at the University of Illinois (part of the BIMA AIPS++ effort). This application runs in stand-alone mode at the present time (November 1994), and is being integrated with Glish so that image parameters, arrays, regions, and so on can be passed between the AipsView tool and the rest of the AIPS++ system via the Glish interface. This approach evolved because the basic concept of a visualization tool is well isolated, and at the time work on this tool began the AIPS++ Infrastructure could not support the advanced algorithms and display methods contemplated. Thus there are currently two thrusts in Visualization development in AIPS++: development of a semi-autonomous visualization application with good communications to AIPS++ (e.g., AipsView), and development of basic graphics and simpler visualization support within the infrastructure of AIPS++. The former is able to move rapidly forward with only limited links to AIPS++, while the latter must be tightly integrated into the whole of the AIPS++ Infrastructure. This approach has allowed rapid progress by the BIMA group, and means that early AIPS++ users will have access to both programmable graphics capability via the infrastructure as well as access to a high level visualization tool for image display. Details of the AipsView Visualization Application are described in a separate document "AipsView: an AIPS++ Visualization Tool"; details of the infrastructure graphics are described in the document "Infrastructure Graphics in AIPS++". An issue which is unresolved at the present time is how tight the coupling between AipsView and the AIPS++ Infrastructure graphics will be over the long term. This issue will be resolved in 1995, after the Alpha release is done. 6. Software Development Procedures 6.1 Built-in Growth and Renewal AIPS++ must have the ability to easily extend beyond the original vision of its designers. The AIPS++ development process must include mechanisms and features which allow for the continual growth and renewal of AIPS++. The following approaches are being adopted to insure that this goal is achieved: - Application development is being strongly encouraged outside the AIPS++ Center, at both other Consortium sites and at outside sites. The learning barrier for application developers will be as low as possible. In particular, AIPS++ developers who can work with existing mathematical, database, and interface classes provided by the infrastructure will be able to progress rapidly in meeting their particular requirements. The aim of AIPS++ Infrastructure development is to provide a broadly usable framework for AIPS++ application developers. - Code acceptance procedures (see below) have been adopted, providing both enforcement of coding standards and a mechanism for submitted code to be adopted into the core of AIPS++. - Application development and the AIPS++ Infrastructure are separated, in the sense that AIPS++ Infrastructure supports application development. - Stability will be vigorously pursued in two areas: AIPS++ Library stability and AIPS++ Data structure stability. The former means that applications written for the current AIPS++ Class library must continue to work, while the latter means that changes to the AIPS++ data structures should be done in ways which provide backwards compatibility. Stability does not mean stasis, however: the inheritance and polymophism features in object oriented languages like C++ mean that extensions to existing classes and structures can usually be done in ways which are compatible with existing classes and applications. 6.2 Code Acceptance Procedures Formal code acceptance procedures are essential in the distributed development environment of AIPS++. The AIPS++ project adopted a formal procedure for quality checking code in August 1994. The procedure requires that all new core source code be submitted to the AIPS++ "code cop" before it can become sanctioned AIPS++ code. Once received, the cop assigns a reviewer, who is asked to judge the code against the AIPS++ Standards and Guidelines (note 167). A dialog between the programmer and the reviewer may ensue, eventually leading to approval of the code, and its formal inclusion into AIPS++. The project plans to retrospectively review all code submitted prior to August 1994, and to complete that review by mid-year 1995. Details of the code acceptance and review procedures are presented in AIPS++ Note 167, "The AIPS++ Code Review Process", and related documents. 6.3 Change Control Formal change control procedures and/or systematic regression testing will be considered for adoption during 1995. Presently, the expected effects of infrastructure changes are assessed during oral discussions at weekly and monthly phone meetings. As AIPS++ application development begins in earnest and expands to multiple sites during 1995, formal procedures will be adopted for planning, describing, and implementing changes needed to various parts of AIPS++. Before the early 1996 release we expect to have a sufficiently mature infrastructure system in place that most changes will be possible in either a backwards-compatible mode or that straightforward upgrade procedures will be available. The goal is to provide security for code developers and prevent maintenance problems. 6.4 AIPS++ Workshops, Schools, and Meetings AIPS++ Developers' Workshops, Programmer Schools, and Users' Meetings will serve two purposes for the AIPS++ project: training new developers, and keeping the AIPS++ Infrastructure and development responsive to the user and programmer community. Currently, two or three different meetings are anticipated; these plans will evolve as AIPS++ moves into an operational phase during 1995 and 1996. To summarize: - AIPS++ Programmer Schools: Every year or two the AIPS++ project will host a school to introduce application programmers to AIPS++. Since attendees will probably have little or no exposure to C++ programming, the school will include appropriate C++ related background material and tutorials, as well as covering application programming in AIPS++. Attendees will leave the school with enough knowledge of AIPS++ to use existing class libraries to develop new high-level applications. The first of these schools will be held for a small group when the Beta release (scheduled for mid 1995) is actually completed. - AIPS++ Developers Workshops: These meetings will be for experienced AIPS++ programmers, and will provide a forum where various development issues can be explored. The goal of these meetings will be to insure the viability of the AIPS++ programming community, and to insure that the project remains responsive to the needs of the community. These workshops will be an important communication tool between the AIPS++ project and the general astronomical programming community. These meetings might be held in conjunction with a meeting like the annual Astronomical Data Analysis and Software Systems (ADASS) meetings, and be of relatively short duration. - AIPS++ Users Meetings: AIPS++ must ultimately be responsive to the needs of the astronomical community which it serves. User's meeting should occur periodically, either in association with one of the meetings described above, or perhaps in association with various (more general) astronomical meetings. 6.5 Unresolved Issues A number of issues which AIPS++ will face as it grows and develops a user community and a wider programmer community remain unresolved at the present time. These issues include: - Procedures and policies for incorporating applications developed outside of AIPS++ (in a so-called "freedom layer") into the core set of supported applications must be developed. Integrating similar applications into a coherent whole may be especially difficult. - It will become increasingly difficult for the infrastructure group to respond to the needs of the Application Development Streams, since the needs of the ADS's may conflict with the need for stability in the infrastructure. - Setting up and dealing with ADS's which aim at processing data in radically new ways, or supporting ADS's for new problem domains which place new and perhaps conflicting requirements on the AIPS++ Infrastructure, may be sources of difficulty. - Clear policies on Infrastructure code and library stability need to be developed as the Infrastructure matures during 1995. 7. AIPS++ Long Term Development Strategy 7.1 Current Consortium participation Current Consortium participants divide into two categories: Larger: These sites, characterized by three or more workers, host some of the major functions in the project, such as the AIPS++ Center, or lead one of the Application Development Streams. Smaller: These sites are characterized by a roughly 1 person level of effort. These sites either operate on a "contract" basis for smaller tasks, or are responsible to the Project Center or an Application Development Stream for particular tasks. These sites may also participate in selected design efforts, or may focus on specialized tasks or algorithm development. This level of participation and effort in the project is adequate for developing the AIPS++ Infrastructure and selected applications, but will not be optimum over the long term. 7.2 Expansion to local development groups It is essential that AIPS++ development leads to and enables local application development at observatory sites. Although many basic applications can be developed "in absentia", applications which deal most directly and fully with data from a particular instrument will be developed most effectively by programmers in close proximity to the scientific staff associated with a particular instrument. It is a major goal of AIPS++ to support this type of development activity, and provide a framework in particular application domains which supports specialized data and associated analysis and reduction routines. During 1995, application development activity within AIPS++ will be increasing, with application programmers at several sites beginning local development within AIPS++. This will lead to AIPS++ applications which will address the basic data reduction needs of AIPS++ Consortium members. The documentation system for AIPS++ will be critical for the success of this expansion effort. Programmers at small or isolated sites must have access to useful programmer-level documentation and appropriate coding samples and tutorials. To that end, documentation has been moved up in priority, and coding standards address documentation requirements. To support the distributed development activities which are essential for the success of AIPS++, the AIPS++ Center must respond to and support smaller sites with a combination of training, visits, and guidance. Similarly, smaller sites within the Consortium must also be assertive in getting attention of the Center - email, telephone, visits, focused workshops must all be used. In the longer term, it is expected that sites outside the Consortium will also invest in developing applications which its within the AIPS++ framework. Supporting and encouraging this type of activity will greatly enhance the usefulness of AIPS++ to the astronomical community. 7.3 Development of an AIPS++ Programmer Community Over the long term, one goal of the AIPS++ project is to foster the development of an AIPS++ programming community within the astronomical community. An important component of this effort will be providing access to AIPS++ programming for outside programmers. In effect, the AIPS++ Project must provide an avenue for new programmers to meet their own priorities, and create confidence that code developed for AIPS++ will remain viable. Several long- term efforts will be required to meet these goals: - AIPS++ must strive to create a system which allows programming at multiple levels, ranging from a straightforward entry level to advanced class design and development. - There must be a clear pathway into the AIPS++ documentation via tutorials, hypertext, and printed manuals. - Periodic 1-2 week summer must be used to train new programmers and programmer/astronomers into the AIPS++ way. - Programming workshops, schools, and Users meetings (as discussed above). 7.4 Outside AIPS++ Code Development As previously stated, AIPS++ must allow for built in growth & renewal as techniques advance, new instruments are developed, and advanced algorithms become available. It is likely that new applications and algorithms will be developed both within the AIPS++ Consortium as well as by outsiders; the Project will need to develop mechanisms for dealing with such code. The basic concept is that AIPS++ will distribute and support the AIPS++ Infrastructure along with a set of core applications which address the primary needs of AIPS++ users. Outside of that, we expect a "freedom layer" of applications will exist, which are developed and (perhaps) supported by programmers working outside of the AIPS++ Consortium. The needs of the community will dictate which applications (or which entire application frameworks) migrate from the freedom layer into the officially supported AIPS++ core. The existence of such a freedom layer with many active programmers creating "unofficial" AIPS++ applications will be a sign of the success of AIPS++. There are several considerations to making the concept described above work successfully: - Strong code acceptance standards for the AIPS++ core must be maintained. - There must be careful revision and change control for the AIPS++ Infrastructure. Programmers must perceive the AIPS++ environment as stable and reliable, and not subject to capricious or unexpected change. - Maintenance of the documentation system is vital. - Management of submitted code and movement of code from the freedom layer to the AIPS++ core will be required. Clear procedures for adopting submitted code into the core must be developed, documented, and perhaps even advertised. - Eventually an AIPS++ Technical Steering committee (or similar group) will be created which has the responsibility to decide when and if various pieces of infrastructure should be changed, how such changes should be implemented, how to deal with backwards compatibility, and related issues. - It may be convenient for developers and the Consortium alike if the Consortium can develop mechanisms for supporting the distribution of unofficial applications. 7.5 User Support AIPS++ will fail if it does not develop a user community and support its users. The issues of User support will be discussed in more detail in the future document on AIPS++ Operations; briefly, AIPS++ User support must address User training (there is a distinction between user training and programmer training), create appropriate user tutorials and documentation, provide support for the logistics of distribution and installation, and finally provide mechanisms for feedback from users (for example, semi-automated problem reporting, User's meetings, and so on). 8. Project Milestones 8.1 Phased Development Approach The development of AIPS++ must be viewed as a series of phased developments; completing the first phase is a prerequisite to moving on to the next phase. The end of each phase has clearly identifiable milestones, related to release plans for AIPS++. While it has not proven possible to make reliable predictions of the duration of any one phase, this approach provides a road map to the development of AIPS++, and will serve as a guide to the current status of the project. The basic phases identified for AIPS++ are as follows: - Infrastructure development: This leads up to the Alpha release, with a focus on creating libraries, documentation, and sample applications for the Alpha release. - Alpha release: This release will provide a limited but usable environment for application development, along with some sample applications. - Beta release: The package begins a consolidation phase with the Beta release, with application testing by users and developers alike. - Initial Release: This formally moves AIPS++ into an operational phase with the dual concerns of (1) supporting users and (2) providing for internal growth and renewal of the package, as the needs of the community continue to evolve. This table summarizes the broad goals for each phase: ------------------------------------------------------------------------------- Early 1995 Version 0.5 Basic User interface ("Alpha Release") Command line interface for programming Graphical User Interface prototype Core Single Dish applications (e.g. OTF Mapping) GUI tools - 1&2D display Capability of graphical feedback Sample interferometric applications: Spectral imaging Cleaning Antenna based calibration (I pol.) Sample Image Analysis applications: Image geometry correction/regridding Line and component fitting Basic documentation system Mid 1995 Version 0.9 User interfaces Command Line Interface Graphical User Interface ("Beta Release") Core Single Dish applications Core aperture synthesis applications Image analysis applications Early 1996 Version 1.0 Nearly full functionality as it exists (First full release) in AIPS, UniPOPS, packages Begin transition of users from AIPS, MIRIAD Gypsy, UniPOPS, ... to AIPS++ ------------------------------------------------------------------------------- 8.2 December 1994: Extended Review The primary aim of the Review is to allow the invited Review Panel to consider all aspects of the AIPS++ Project and provide firm suggestions and guidance to the Project where needed. All aspects of the Project are part of the review, including organization and management of the project, tactical decisions and strategic choices made by the project, and the design and technical details of the project. The appointment of a Review Panel is a recognition of the fact that the AIPS++ Steering Committee may be too close to the Project to provide a completely objective point of view. The Panel will provide an objective outside assessment of how things are going, and what should be changed. A secondary aim of the Review, which takes advantage of the variety of information being prepared for the Review, is to allow interested members of the astronomical community to learn about the project, where it stands, and what is planned for the future. Various categories of Observers have therefore been invited to attend the public sessions of the review. The review serves as the punctuation between a project emphasis on infrastructure development and an emphasis shifting to application development. 8.3 Version 0.5 (Alpha Release) The following is an itemized list of the contents planned for the Alpha release. The list represents capabilities needed to support an astronomer or develop applications using the examples listed. 1. Applications 1. Single Dish On the Fly Imaging Gain calibration Baseline fitting Multiple Gaussian fitting Moment image production Other UniPOPS-like verbs 2. Interferometry Read AIPS UVFITS files Make simple image from calibrated data Basic Image Deconvolution (Clean) 3. Image Analysis Display Color LookUp Table generation Masking/blanking, region selection Difference, statistics 4. Tools Catalog browser Table browser Documentation browser 5. AipsView for image browsing, display, visualization 2. Source data Single Dish SDFITS / SDD AIPS UVFITS FITS images 3. Data output FITS images 4. User assistance Help & Documentation systems Cataloging Parameter setting/editing History/logging 5. Documentation Users Manuals Developers Manuals Programmers Manuals: Tutorials, Class Reference Documentation, Sample Code 6. Astronomical support Common Measurement Set (MS) Coordinates/transformations PSF (Point Spread Function) class 7. Mathematical support Fitting Convolution Image processing (moments, filters, statistics, ...) 8. Command Line Interface - Glish AIPS++ Startup Class binding to Glish - FFT, Image, Table, Display AipsView binding to Glish 9. Database (AIPS++ Table system) Virtual columns Large (> memory) files 10. General support Automated testing of AIPS++ Classes Release management Installation procedures Bug/gripe handling 8.4 Version 0.9 (Beta Release) The AIPS++ Beta Release provide substantial enhancements over the Alpha release in these areas: - Enhancements and debugging of the user environment, based on user tests with the Alpha release; - Basic aperture synthesis applications for the calibration and imaging of interferometric data from a variety of instruments. - Various graphics and data visualization capabilities and enhancements, based on user feedback. - Single Dish imaging and calibration, with core functionality of UniPOPS in place for processing Single Dish data. - A few basic Image Analysis applications - Enhancements and debugging of the AIPS++ Infrastructure, including improved I/O for AIPS++ Tables, data and parameter editing enhancements, fully standardized programmer documentation, and user documentation and tutorials. The target date for the Beta release (as of November 1994) is mid-1995. Making this target date will depend on the success of the Alpha release, and on personnel available to the project. Major technical problems with the Alpha release will delay the Beta release until later in 1995, and might even require a second (improved) Alpha release. In the latter situation, the Beta release would be pushed back by about 6 months. In association with the Beta release we will consider holding an "invitation-only" AIPS++ Programmers school. This school will allow programmers outside the project (at both Consortium sites and elsewhere) to gain the basic knowledge of AIPS++ to begin application development on their problems using AIPS++. This initial school will be targeted at a relatively small group of perhaps 10 to 20 programmers. It will serve two purposes: enlarging the number of application developers for AIPS++, and provide the project with valuable experience for future AIPS++ schools in subsequent years. 8.5 Version 1.0 (First Full Release) The goal for the initial public release of AIPS++ is to provide a set of the core applications used by the majority of astronomers reducing both interferometric and single dish radio astronomy data. These core applications will be enhanced by a few selected advanced applications, as well as a variety of features that will attract users to AIPS++. The target date for the initial release is early 1996, with the date depending upon successful Alpha and Beta releases in 1995. If necessary, this release will be downgraded to a 2nd Beta release, so that the astronomical community is not unknowingly involved in the testing phase of AIPS++. Thus, if delays occur, there will still be a first or second Beta release in early 1996. Appendices: AIPS++ Policies General policies adopted by the Steering Committee are part of the this Strategic Plan, and will be summarized in this appendix: Appendix A. AIPS++ Consortium Agreement Copies of the following document have been signed by appropriate representatives from each of the AIPS++ Consortium members: _____________________________________________________________________________ Agreement for the Cooperative Development January 1992 of a New Astronomical Data Processing System The purpose of this document is to state the terms of an agreement to jointly develop a new astronomical data processing package, referred to as AIPS++. AIPS++ will be undertaken as a cooperative venture of the participating Observatories noted below. It will cover, as a minimum, the same functionality as is now contained in NRAO's AIPS software package, but it will be developed in such a manner that it can be easily extended to cover a wide variety of instruments and techniques. The guiding principle in this venture is that it will be managed in a spirit of collaboration and of working towards a common goal. The initial development, and a large part of the subsequent development will be done at the National Radio Astronomy Observatory (NRAO); the management of the project will therefore be located at the NRAO and the project manager will be an NRAO employee, appointed by the Director of NRAO, after having heard the AIPS++ Steering Committee. Each of the participants to this agreement will provide a minimum of one full time equivalent (FTE) per year for at least two years. At least half a FTE will be resident in Charlottesville, with the expense for such visits paid by the participant. Maintenance of the central presence for more than one half FTE is desirable, however, for the timely completion of the project. Subsequent compatibility of approach will be maintained through the exchange of programmers between participants, whenever reasonably possible. The NRAO will provide, for the duration of the project: a minimum of five FTE's dedicated to the project; adequate office space and computing facilities for program development and testing. The participants will be represented on an AIPS++ Steering Committee that will conduct reviews of the progress of the project and of project management plans. This Committee will set general policies, set major priorities, and generally resolve conflicts between participants. Each participant will have a single seat on the committee. The project manager chairs the committee and votes only when it is necessary to break a tie. All decision making, except as noted below, will be by simple majority. Committee meetings will be held at intervals of not less then three months and not more than six months at sites rotating among the participants. Participants will be responsible for their member's travel and accommodation costs. A meeting may be postponed by unanimous consent. At a meeting at which binding decisions can be made, at least two thirds of the participants must be represented. This agreement is entered into by the Participants for a period of two years, starting at the time of signing. At the expiration of this Agreement, it will be renewed automatically, unless one or more participants have expressed the desire (at least six months beforehand) to withdraw or renegotiate. New members can join at any time by signing the Agreement, subject to the approval of at least two thirds of the Participants. Agreement for the Cooperative Development of a New Astronomical Data Processing System - Page 2 - Signed for: Australia Telescope Dr. Ron Ekers Berkeley Illinois Maryland Array Dr. Richard Crutcher Herzberg Institute for Astrophysics (DRAO) Dr. Don Morton National Radio Astronomy Observatory Dr. Paul Vanden Bout Netherlands Foundation for Research in Astronomy Dr. Harvey Butcher Nuffield Radio Astronomy Laboratories Dr. Rod Davies Tata Institute of Fundamental Research Dr. Govind Swarup _____________________________________________________________________________ Appendix B. AIPS++ Mission Statement The key goals for AIPS++ have been laid down in the following Mission Statement, officially adopted by the AIPS++ Steering Committee in October 1993: 0. A telescope requires post-processing software for calibration, editing, image formation, image enhancement, and analysis of images and other data streams. This software is an integral part of the radio telescope engineering. The Astronomical Information Processing System (AIPS++) project is designed to produce such a software product. Although AIPS++ is primarily targeted at radio astronomy, it is anticipated that it will also be used in other branches of astronomy and for other applications in image processing and data analysis. 1. AIPS++ shall support single antenna telescopes (single dishes), including multiple beam applications. AIPS++ shall support multiple element interferometer arrays (interferometers) operating in snapshot mode or using the earth rotation aperture synthesis technique. The support for interferometers shall include specialized support for east-west arrays, non-coplanar arrays, very long baseline interferometry (VLBI), and space VLBI. The support for VLBI shall include interferometer elements which are themselves arrays. AIPS++ shall further include support for the combination of observations made with different instruments. 2. AIPS++ shall support data post-processing as least as fully as the present NRAO software packages -- i.e., the Astronomical Image Processing System (AIPS) for interferometry and UniPOPS for single dishes. 3. AIPS++ shall provide a set of routine applications (e.g., scripts and programs) whose parameters may be changed interactively and dynamically. AIPS++ shall also provide for data processing in a batch mode. 4. AIPS++ shall be developed to provide a core of application classes for use with AIPS++ applications, with access by a user- programmable interface to these classes for non-AIPS++ code. AIPS++ shall provide facilities to allow a user to write customized applications which link to the AIPS++ library functions and classes. 5. AIPS++ shall be written primarily in C++. AIPS++ shall provide programming interfaces to the most commonly used scientific computer languages (i.e., C and FORTRAN). 6. AIPS++ shall be designed to be easily programmable. AIPS++ shall be designed so as to be easy to maintain and easily extensible. 7. AIPS++ shall provide for multiple user interfaces, including graphical user interfaces. 8. AIPS++ shall be as portable as possible to different computer architectures. AIPS++ shall be a self-contained package that can be installed, maintained, and operated without the need for software packages other than the operating system and compilers for the host architecture and freely available software which is known to run on all architectures that AIPS++ supports. 9. AIPS++ shall be engineered so that the essential core functions can be freely distributed specifically to all researchers in astronomy, but further also to other research communities. Permission to copy and redistribute the code shall be under the terms and conditions derived from the Free Software Foundation (GNU) license. 10. AIPS++ shall provide a standard suite of test programs to determine the precision and performance of key applications. In the event of a conflict, portability shall take precedence over performance on any one architecture. 11. AIPS++ shall read and write standard data interchange formats. Specifically, AIPS++ shall read and write data in the Flexible Image Transport System (FITS) format. 12. AIPS++ shall be usable in a telescope operations environment. 13. AIPS++ shall provide up-to-date documentation on-line and in hard- copy for users and for programmers. This documentation shall be consistent between the different media. 14. Only the radio astronomy applications of AIPS++ shall receive high priority for development and maintenance by AIPS++ personnel. All other application areas shall be supported on a best-effort time- available basis. 15. In summary, AIPS++ shall be programmed to be flexible and versatile to use, to modify, and to enhance. Researchers other than the main support staff shall be invited and encouraged to add applications and functionality. Appendix C. Copyright and Licensing Policy AIPS++ code will be copyrighted, with the copyright held by Associated Universities, Inc. for the AIPS++ Consortium. The purpose of the copyright is to protect the Consortium's interests in the code while still allowing broad distribution of the code. There are three general categories of copyright honored and supported by the AIPS++ project: 1. Documents and code produced by and for the AIPS++ project a. Complete applications, test programs, scripts, makefiles, and documentation. b. Library code and header files 2. Copyrighted third party software which is freely redistributable. 3. Other third party software. AIPS++ Copyright Details: 1a. Complete AIPS++ applications, test programs, scripts, makefiles, and documentation will be distributed under the Free Software Foundation (GNU) General Public License as follows: Copyright (C) 1993,1994,1996 Associated Universities, Inc. Washington DC, USA. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Massachusetts Ave, Cambridge, MA 02139, USA. Correspondence concerning AIPS++ should be addressed as follows: Internet email: aips2-request@nrao.edu. Postal address: AIPS++ Project Office National Radio Astronomy Observatory 520 Edgemont Road Charlottesville, VA 22903-2475 USA 1b. AIPS++ library code and header files will be distributed using the Free Software Foundation (GNU) Library General Public License. The notice included in the files will be as follows: Copyright (C) 1993,1994,1996 Associated Universities, Inc. Washington DC, USA. This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details. You should have received a copy of the GNU Library General Public License along with this library; if not, write to the Free Software Foundation, Inc., 675 Massachusetts Ave, Cambridge, MA 02139, USA. Correspondence concerning AIPS++ should be addressed as follows: Internet email: aips2-request@nrao.edu. Postal address: AIPS++ Project Office National Radio Astronomy Observatory 520 Edgemont Road Charlottesville, VA 22903-2475 USA 2. Copyrighted software from third parties which may be freely redistributed and which is used by the AIPS++ project will be distributed as part of the AIPS++ software. The original copyright statement by the authors and their organizations will remain intact. The copyright requirements of such software will be fully honored. 3. Other third party software will not be distributed by the AIPS++ project. Appendix D. Platform support policy AIPS++ is being developed as a portable system which the AIPS++ Consortium will make available on a reasonable selection of platforms and operating systems. Development and testing under multiple system architectures is the best way to insure the portability of AIPS++. Currently, the development of AIPS++ is occurring mainly on machines built by Sun Microsystems. As a result, early releases of AIPS++ will be designed to work under both SunOS 4.2 as well as Solaris operating systems, using either the Sun CFront-based compiler or the Object Center compiler (a third-party compiler which is also CFront based). In addition, we expect that early releases of AIPS++ will be supported under IBM's AIX operating system using a recent version of their native C++ compiler. There are also several additional architectures which may be supported in early releases of AIPS++, depending on the success of vendors in developing reliable, robust C++ compilers, and on resources available to the project. These alternatives include support for Silicon Graphics Inc. (SGI) computers using SGI's new C++ compiler; porting to the new native C++ compiler being developed by Sun Microsystems; and porting to the Lucid C++ compiler under the SunOS or Solaris operating systems. We have tested the gcc compiler (a public domain compiler from the Free Software Foundation), but it proved unsatisfactory for now. Eventually, the gcc compiler may provide a very portable AIPS++ implementation. Porting of AIPS++ to other architectures, operating systems, and compilers will occur as required.