Components and Directory Structure
[PREVIOUS] [TOP] [NEXT]
VICAR is divided up into about a dozen major parts. Each part has its
own subdirectory off the VICAR root directory, containing both source code and
executable programs. See the attached VICAR directory tree diagram (last page
of this document). These parts fall into two main classes. The
executive provides the environment in which both the user and the applications operate.
The application programs provide most of the actual image processing
functions of VICAR.
Not all of the directories listed below are implemented in the UNIX version of
VICAR. They are included below for completeness, to give you a framework for
the whole system. Directories printed in italics below are not yet
available under UNIX.
- Note: Due to limitations in TAE, the directory you choose for VICAR must not have any
uppercase letters in the pathname.
The executive directories
- tae52: Version 5.2 of the Transportable Applications Environment, TAE+,
developed by the Goddard Space Flight Center. TAE provides the user environment
for VICAR. It provides the VICAR command-line interface and the subroutines
needed for programs to use it. It also provides the capability of designing and
implementing graphical user interfaces. This capability is not used in the
present version of VICAR, but it may or may not be in the future. It is
available now for experimentation.
- tae52.sun-solr: The same as tae52. This is because TAE compiles SunOS and
Solaris code into subdirectories named sun4, so they cannot coexist in the same TAE tree.
- rtl: The VICAR Run-Time Library. The RTL includes the image and label I/O
routines, the parameter processing routines, and other miscellaneous routines
that are used by the bulk of the VICAR applications.
- vrdi: The Virtual Raster Display Interface. The VRDI is the subroutine
package that allows programs to access display devices in a device-independent
manner. The same calls are used for any supported device, which makes the
task
of writing display programs much easier. Under UNIX, currently only X-windows
is supported.
- vids: The VICAR Interactive Display Subsystem. VIDS is the main display
manipulation package in VICAR. It accepts commands both from the user and
from programs, and provides many functions for displaying and manipulating images
on the display devices.
- util: Miscellaneous VICAR utilities. This directory contains the routines
that fetch VICAR from CMS (not needed for an external site), as well as some miscellaneous
files used during the build, and a couple of utility programs used by
applications. One is the application packer, which creates the .COM files
in a portable manner (they can be read on a UNIX machine). The other is called
"vimake", which creates application build files from a system-independent
description of what to build. Both of these programs ease portability between
VMS and UNIX. They are used by all portable applications.
- math77: The MATH77 library, provided by the JPL Applied Mathematics Group.
MATH77 is a collection of subroutines to do various mathematical manipulations,
used by many of the VICAR applications.
- mdms: Multimission Data Management Subsytem - manages ancillary data using
Sybase, intended as a replacement for VMS datatrieve.
The application directories
- p1: The system-level application programs and subroutines. Currently,
this
contains only MRPS, the film-recording system used at MIPL that is not
delivered externally. P1 is therefore virtually empty.
- p2: The officially supported applications. P2 contains all the supported
VICAR application programs and subroutines, which includes the familiar R2LIB
directory.
- p3: The unsupported applications. P3 contains applications and subroutines
that are provided on an as-is basis. They are not tested or supported in
any
way by MIPL.
- hw: Mars '94 specific applications (hw stands for HRSC/WAOSS, two
instruments on Mars '94). This directory should not be included unless you
are
working on the Mars '94 project.
There are two extra directories, which are
created during the build process. They contain no source code - everything
in
them is copied into them during a full build.
- olb: Object libraries. All object code libraries for all the parts
reside
here, as well as shared libraries.
- lib: The lib directory contains miscellaneous executables from the
executive. They are all gathered into one place so the TAE search list doesn't
get too big.
Each of the applications directories (p2 and p3) is further
divided into several major pieces. They are listed below. The aliases are
used
as names for the build procedures, and are given for p2 only, but p3 is exactly
the same (except for a 3 instead of a 2 in the name, of course).
- inc: The portable include files.
- sub: The portable subroutine source code, also known as p2sub.
- oldsub: The VMS-specific subroutine source code, also known as s2.
- prog: The application source code (both portable and VMS-specific),
also known as p2prog. Note: Only portable application source code is delivered
with the UNIX version of VICAR.
- lib: The executable code and PDF's. This is where r2lib resides.
(Actually, $R2LIB is a machine-specific subdirectory of lib.)
Explanation
of Directory Structure
The VICAR directory structure is designed to accommodate a heterogeneous array
of machines simultaneously, all accessing the same VICAR tree over a network
(e.g. via NFS). In order to accomplish this, every directory that contains
machine-specific files (such as object code or executables) actually contains
several subdirectories, one for each machine type. That is indicated by the
"targets..." label in the diagram. These directories contain the same files for
each machine type, and must be created by the machine in question. Most
external installations will consist of only one type of machine, so there will
be only one machine-specific subdirectory. (Note: it's machine types,
not individual machine names, that are at issue here).
The subdirectories for each machine type follow a consistent naming scheme. The
shell script vicset1.csh sets an environment variable, called $VICCPU, to the
name of the type of machine (these names are actually defined in the include
file $V2INC/xvmaininc.h). Thus, to get at the directory where the object code
libraries are stored, you would not use $V2TOP/olb, you would use
$V2TOP/olb/$VICCPU. (Of course, normally you use other environment variables
set up by vicset1.csh, rather than $VICCPU directly, but this is how
they are set).
For example, the object library directory might look like this:
% ls -CF $V2TOP/olb
hp-700/ sgi/ sun-4/ sun-solr/
% ls -CF $V2TOP/olb/hp-700
libmath77.a libp2sub.a librtl.a
% ls -CF $V2TOP/olb/sgi
libmath77.a libp2sub.a librtl.a
The valid machine types correspond with the supported machine types listed above.
- axp-vms: DEC Alpha running VMS
- sun-4: Sun 4 or SPARCstation, or clone such as Solbourne
- sun-solr: Sun Solaris
- sgi: Silicon Graphics workstation
The valid machine types correspond with the supported machine types listed below.
- alliant: Alliant FX series computer
- cray: Cray
- decstatn: DECstation (any DEC MIPS-based RISC machine) running Ultrix
- hp-700: HP 9000 Series 700 workstation
- mac-aux: Macintosh running A/UX
- mac-mpw: Macintosh running native mode w/ Mac Programmers Workbench.
- sun-3: Sun 3, any model
- tek: Tektronix workstation
- x86-solr: Intel-based PC running Solaris
The TAE directory is a special case. Though all supported versions use TAE 5.2, we must have two
separate directories for SunOS and for Solaris. TAE compiles both into subdirectories named sun4,
which means that SunOS and Solaris executables may not coexist in the same version of TAE, even
though they have common source code. Other platforms coexist with SunOS in the MIPL delivery,
although they may coexist with the Solaris version instead if SunOS is not needed. This is set up in
vicset1.csh.
Next: The Version Number
Previous: Subroutine Libraries
Top: VICAR Installation Table of Contents
Updated Tue May 6 14:06:25 1997
by Larry Bolef