Previous: Introduction
Up: No Title
Next: Documentation
Previous Page: Introduction
Next Page: Documentation
The following components can be identified within NEMO:
-
A common user interface is shared by all programs; all program are
executed from the UNIX (or equivalent) shell, and accept a keyword=value
based command line parameter list. There are program and system
parameters, the latter one shared by all programs, and control global
properties such as error handling, debug output, graphics devices etc.
This user-interface allows you to switch to a different look-and-feel
user-interface using it's plug-compatible property. Some nice examples
have been constructed in interfacing NEMO with the MIRIAD (an AIPS-like
interface) and KHOROS/CANTATA (a visual programming language) packages.
In
practice however, we find shell scripts (``batch mode'') the most
powerful, and self-documenting, mode of operation.
-
A common file-structure is shared by all programs. Data, used to
communicate between programs, is stored in files in a hierarchical structure
of name- and type-tagged items in binary format. Items can be single scalars,
multi-dimensional arrays and even arbitrary (C-type) structures. In addition
each program can have an input and output channel which is
connected to a pipe instead of a disk-file. Since many programs
transform one dataset into another, it allows for efficient
chaining to build useful new tools.
-
On top of this file-structure, a number of packages have been
defined. The most important
one is the snapshot, on which NEMO was originally based. Subsequently
images, tables and orbits were introduced, with a number
of programs that convert data between them.
-
A common graphics interface is defined on the Applications Programming
Interface (API) level. One simply needs to link with any graphics
library (e.g. mongo, pgplot, X11, postscript, suntools, GL) to create a
working program. This hides the complexity of different graphics programs,
but is of course not as flexible since a fairly low common denominator has
to be chosen for the API.
-
Programs can use a dynamic loader, in order to compile, load and run
user-specific code on the fly. This supports very flexible and powerful
analysis
tools. For example, in orbit integration a user-defined potential can be
used to integrate and analyze orbits, and for snapshots arbitrary
user-defined expressions are used for many analysis- and plotting
programs.
___________________________________________________
Previous: Introduction
Up: No Title
Next: Documentation
Previous Page: Introduction
Next Page: Documentation