Version 1.9 Build 1367

News	FAQ
Search	Home

Next: Code management Up: No Title Previous: Introduction

Directory hierarchy

In designing the aips++ directory structure, the discussion in the aips2-tools exploder seemed to reach a consensus on the following guiding principles

Only one copy of the source code should need to be present at any one site (in this context ``site'' effectively means the local area network, or LAN).
The current practice of installing $\cal {A}$ IPS and similar packages on one machine of each architecture in each LAN (or even on several machines of the same architecture!), can be circumvented by careful design of the directory tree. This will have advantages in maintainability, as well as more efficient use of disk space.
NFS (or similar) provides the mechanism for realizing this requirement.
Multiple machine architectures must be supported transparently.
This effectively means that multiple architecture-specific system areas (binaries, libraries, etc.) must be logically divorced from the aips++ code areas and from each other.
Divorcing the code and system areas will also offer end-users the option of deleting the source code once they have installed the system. In a similar vein, the BIMA user specifications require aips++ to be ``configurable'' in the sense that synthesis, single-dish, and VLBI code be separable, with the option of not installing one or other of them.
A side effect of this requirement is that architecture-specific work areas will be needed to hold the intermediate products of compilation.
The directory structure should allow logically distinct parts of aips++ to reside on file servers as is most appropriate.
This may be realized most conveniently by having the aips++ code and architecture-specific system areas stem from a single directory node, thereby allowing one machine to act as an NFS server for the code and/or system areas which clients mount on a single directory node. A machine of a particular architecture may be selected to act as NFS server of the aips++ system for other machines of similar architecture.
Likewise, the entire aips++ tree should stem from a single directory node and be relocatable.
In conjunction with the first two requirements, this requirement implies that the aips++ system be installable entirely from information contained in the code subdirectory tree.
The code subdirectory tree would be mounted read-only from the server.
Third-party software should be logically separate from the rest of the aips++ code.
It should reside in its own subdirectory or subtree.
Libraries and utilities such as PGPLOT, and GNU make which will be a required part of aips++ will be made available optionally as part of the aips++ distribution (see below). Where recipients already have the correct version of this software installed and don't want a duplicate copy, they may opt not to accept the copy distributed with aips++ and rely on their own.
Distribution of aips++ within multiple sites belonging to a single institution should be facilitated.
Many institutions have several sites where aips++ will be maintained in parallel. For $\cal {A}$ IPS Charlottesville-Socorro were such a pair for NRAO, and similarly Epping-Parkes-Narrabri for ATNF. The aips++ directory tree can be structured to facilitate support for multiple sites. In particular, site-specific system areas can hold site-specific databases, for example data aging limits or data disk bookings. In a well designed system, upgrades may consist simply of copying the whole directory tree (or deltas) from one (master) site to another (slave) site.
aips++ must support multiple hosts within a site.
Networks with dozens of workstations, each possibly with their own peripherals, are now the norm. Host-specific databases may be required to manage these peripherals, for example, and these should be supported in host-specific subdirectories.
A release and development version of the aips++ executables should be kept at consortium sites.
$\cal {A}$ IPS traditionally maintained three versions (OLD, NEW, and TST). This was the minimum required to ensure that the distributed version (OLD) was sufficiently mature, bug-fixes being applied to the NEW and TST versions, and code development restricted solely to the TST version.
However, this also meant that the $\cal {A}$ IPS programmers were always at least six months ahead of the rest of the $\cal {A}$ IPS community, and important bug fixes took at least three months to be distributed. On the other hand, bug fixes submitted by end users referred to a system long since removed from the computers at Charlottesville.
aips++ should aim for a more direct association between programmers and end-users by keeping only two versions, released and development. The slightly increased risk of distributing bugs can now be offset by distributing fixes via worldwide networks. This mechanism was not available for $\cal {A}$ IPS until well into the project. The actual mechanism of distributing code and bug-fixes is discussed below.

A possible directory hierarchy designed to satisfy the above requirements may resemble the following scheme:

                         +--- PGPLOT-4.9.tar.Z
                         +--- SLALIB.tar.Z
                         +--- ATELIB.tar.Z
         +--- import ----+--- cool.tar.Z
         |               +--- make-3.62.tar.Z
         |               +--- cvs-1.2.tar.Z
         |               +--- rcs-5.5.tar.Z
         |               +---   :
         |                
         |               +--- install ---+---
         |               |
         |               +--- kernel ----+--- include
         |               |               +-- implement
         |               |               +-----  Z
         |               |               +-----  Q
         |               |               +-----  :
         |               |               +--- scripts
         |               |               +---- data
         |               |               +----- doc
         |               |
         |               |               +--- include
         |               |               +-- implement
         |               +-- synthesis --+--- scripts
         |               |               +---- data
         +---- code -----+               +---- doc
         |               |
         |               +---- vlbi -----+...
         |               +---- dish -----+...
         |               +---- atnf -----+...
         |               +---- bima -----+...
         |               +---- drao -----+...
         |               +---- nfra -----+...
         |               +---- nral -----+...
         |               +---- nrao -----+...
         |               +---- tifr -----+...
         |               +--- contrib ---+...
         |
         +---- data -----+...
         |
         |
         |                               +----- lib
         |                               +----- libdbg
         |                               |
         |                               +----- bin
         |                               +----- bindbg
         |                               |
         |                               +----- tmp
         |                               +----- tmpdbg
         |                               |
         |                               +----- data
         |                               |
      ---+               +---- apex -----+
         |               |               +----- doc -----+--- ascii
         |               |               |               +--- info
         |               |               |               +--- manl
         |               |               |               +--- catl
         |               |               |               +---   :
         |               |               |
         |               |               |               +--- msgs
         +--- (arch1) ---+               +--- (site1) ---+--- (host1)
         |               |               |               +--- (host2)
         |               |               |               +---   :
         |               |               |
         |               |               +--- (site2) ---+...
         |               |               +---    :
         |               |
         |               +---- base -----+...
         |
         |
         +--- (arch2) ---+...
         +---   :

Example names

arch: sun4, sun3, ibm, cvex, vax, pc, etc.

site: epping, narrabri, parkes, mopra (for the ATNF installation), etc.

host: baboon, lemur, nrao1 (at Charlottesville), etc.

Notes:

ãips++/import holds public domain subroutine libraries and stand-alone utilities
ãips++/code/install holds installation scripts including template system scripts
ãips++/code/kernel holds core routines written by the aips++ group
ãips++/code/synthesis holds aips++ tasks specific to synthesis arrays
ãips++/code/vlbi holds aips++ tasks specific to VLBI processing, in addition to tasks in synthesis
ãips++/code/dish holds aips++ tasks for single dish processing
ãips++/code/{atnf,bima,drao,nfra,nral,nrao,tifr} hold instrument-specific packages
ãips++/$ARCH/base is the release version of aips++
ãips++/$ARCH/apex is the development version of aips++

The .../install directory will contain subdirectories - possibly architecture-specific - which will contain all the source code and shell scripts necessary to build the system procedure scripts and place them in the .../$ARCH/bin directories.

Division of the .../kernel subdirectory has not been considered in detail. However, the Q- and Z-routine directories at least will need to be further subdivided.

The division of aips++ tasks into synthesis, vlbi, and dish is motivated by the BIMA user requirement that the installation be configurable for these purposes. It is not clear whether any of these directories will actually need implement and include subdirectories.

The apex directories would only contain files which differ from those in the base directories. Search paths could operate for the executables, libraries, documentation, etc., so that someone wanting to run the development version of aips++ would set their search path with

ãips++/$ARCH/apex/bin:ãips++/$ARCH/base/bin:...

Search paths for documentation, and other areas may have to be implemented within aips++ itself.

The libdbg, bindbg, and tmpdbg areas are provided for debug versions of the libraries, executables, and temporaries and will be discussed in part 2 of this document.

The doc area would contain documentation compiled from the code doc areas. Since the form of the compiled text may be different for terminals, workstations, etc., it might be necessary to have subdirectories holding documentation tailored for each of these cases.

Directories should contain README files to explain their purpose. It should also be noted that POSIX.1 effectively limits file names to 14 characters, and pathnames to 255.

Next: Code management Up: No Title Previous: Introduction