%% If you do anything to change the page-breaks (like changing the
%% layout or using a different LaTeX format), the index will not be
%% correct. 

\documentstyle[makeidx%
%a4%
%,twocolumn%
%,showidx%
%,timesnew%
,11pt%
]{report}

% built-in 11 pt a4-ish size (really too wide!):
\topmargin 0 pt \textheight 646 pt \textwidth395pt

\title{\bf The Next Generation of the NSF Interactive Graphics System --- a
Preliminary Requirements Document}
\author{Dave Love\\[1ex]{\it NSF Software
  Group}\\[1ex]({\tt\normalsize d.love@daresbury})}
\date{Edition 0.1 of 1/2/91 --- drafty\\[8ex]
  \framebox{\parbox{.75\textwidth}
  {\normalsize \noindent This document is not claimed to be either
  complete or correct: it may be considered at `$\alpha$-test'.
  Comments are solicited, especially about other areas that should be
  covered, preferably with an indication of what to say since lack of
  inspiration is the reason a few aren't yet covered.  Reports of typos
  are welcome (as would be a better acronym than \nigs!).  
  % This is being
  % updated when the muse takes me or when issues come to light, hence the
  % lack of version number at present.  
  }}}

% use as \kw{keyword text for formatting and indexing} or
% \kw[indexing text]{formatting text}:
\makeatletter
\def\kw{\@ifnextchar[{\my@index}{\my@index@}}
\def\my@index[#1]#2{\index{#1}{\sl#2}}
\def\my@index@#1{{\sl#1}\lowercase{\index{#1}}}

% keywords, operations, meta-stuff
\newcommand{\op}[1]{{\sl#1}\lowercase{\index{#1@{\sl#1}}}} % operation
\newcommand{\idx}[1]{#1\index{#1}} % format item and index
\newcommand{\meta}[1]{$\langle${\sl #1}$\rangle$}
\newcommand{\acr}[1]{{\sc #1}}	% acronym

% abbreviations:
\newcommand{\ux}{{Un*x}\index{Unix}}\index{Un*x|see{Unix}}
\def\@EG{{\sc EuroGam}}
\newcommand{\EG}{\@EG\index{EuroGam@\@EG}}
\@ifundefined{selectfont}{\let\mediumseries=\relax
  \let\pmediumseries=\relax}{}
\def\@nigs{{\mediumseries \sc Nigs}}

\newcommand{\nigs}{\@nigs\index{Nigs@\@nigs}}
\newcommand{\emacs}{\acr{emacs}\index{emacs@\acr{emacs}}}

\makeatother
\setcounter{secnumdepth}{6}\setcounter{tocdepth}{6}
%\input indexing
\pagestyle{headings}
%\includeonly{}
\begin{document}
\maketitle
\tableofcontents

%\include{background}

%-*-LaTeX-*-
\chapter{Background}

\section{Raison d' \^etre}\index{raison d' \^etre}

This document attempts to define requirements for a replacement for
the current \idx{NSF interactive graphics system}
(`\nigs'\index{NIGS@\nigs})\@.  For information on the significance of
a \idx{requirements document} in the \idx{software life-cycle},
consult a book on software engineering e.g., \cite{sommerville,ince}.
This document doesn't follow the usual scheme of such things since it
is not written by the customer but rather {\em for} the
\idx{customers} to elicit comments on perceived omissions or
mis-features and to make concrete the plans for what will be provided
otherwise.  (It was not expected that the `customers' would produce
such a statement of requirements spontaneously!)  One wants to
overcome conservatism to some extent, so as to allow progress in line
with modern software, hardware and user-interface technology of which
users may not be aware.

This requirements document is unlikely to be followed by the usual
detailed \idx{specification document}, although some aspects may be
specified in detail.  User interfaces like this seem best developed
with a \idx{prototyping} approach.

\section{Interpreting this document}

The language\index{language!consistency of} used here is not
necessarily consistent.  Words such as `should' are usually meant to
be imperative.  Implementation restrictions\index{implementation
restrictions} might modify some of the requirements given.

\section{The function of \nigs{}}\index{function!\nigs{}}

The \idx{NSF} interactive graphics system provides the
\index{user!interface}user interface to acquisition and analysis
facilities for experimental data acquired at NSF or elsewhere and
analysed at any of the UK NSC-supported sites (Daresbury and several
universities).  It is a general facility; this document is not aimed
explicitly at the
\EG{} project, for instance, although \EG{} experimental
groups are expected to be major users of the future \nigs{}.  We aim
to cover all the currently-used---not necessarily all
currently-supported!---facilities and to attempt to improve,
generalise and add to them to cover a wide range of experimental work.

\section{Historical perspective}

\subsection{Concepts}

The current \nigs{} system (modulo various upgrades) has been in use for
a decade.  It draws on previous experience and facilities from the
long-dead \idx{Sigma3} acquisition/analysis system at Liverpool and
\idx{Nero} system at Manchester.  Its vintage means that a serious
re-fit should be considered in the light of progress in various areas
over the last 15 years, although it was well ahead of its
time\footnote{Some of the concepts used which have only recently
become popular are:
\begin{itemize}
\item \idx{direct manipulation} techniques with \idx{light-pen}(\slash
\idx{mouse})-selected drop-down \idx{menu}s;
\item an \idx{interpretative framework} based on \idx{JCL} rather than
monolithic programs;
\item the facilities of the graphics metafile\index{graphics!metafile}
system. 
\end{itemize}}; 
the job of specifying an improved system is made more difficult by the
fact that superior systems do not seem to have emerged in the nuclear
structure world (an early pioneer of such techniques) during the life
of the current system.  (One potentially-interesting system,
\acr{paw}\index{PAW@\acr{paw}}~\cite{paw} seems largely to provide
examples of features to avoid!)  However, lessons have been learnt
from the use and development of the system.  The most important one is
probably that the previous design was pretty well right in the
prevailing technological climate and it is in that light that you are
asked to view current proposals from a similar source where they may
be contentious.

\subsection{Hardware platform}

A more pressing need for re-development than age, though, which
provides the opportunity for new facilities and approaches is the
obsolescence of the hardware around which the current system was
designed.  This is already manifest in the forced replacement of the
\idx{Sension} displays by emulations using workstations---not
an obvious step forward.  A more traumatic change will come soon
\cite{ecgo/8-25} with the need to replace the \idx{GEC} 4000 series
`super-mini' computers with more powerful and cost-effective hardware
in the form of \kw[graphics!workstations]{graphics workstations} (not
to be confused with the old concept of the 4000s providing a
multi-user `\idx{workstation}'\index{GEC}).  The rate at which
computer hardware\index{hardware!evolution} is now evolving makes
forward planning tricky and means that one has to be prepared for a
hardware base\index{hardware!base, changing} which changes with a
period of, say, two or three years rather than the decade or so that
we have been used to.

Hardware and software \idx{constraints} on the system are outlined in
Appendix \ref{app-constraints}.

\subsection{Recent work}

There has been some recent prototyping work \index{prototype!\nigs} at
Daresbury directed towards the system discussed here which has
provided some ideas relevant to the requirements aspect of the system
and to the subsequent implementation.

%\include{purpose}

%-*-LaTeX-*-
\chapter{Purpose}

\label{intuitive}
The overall purpose\index{purpose of \nigs} of \nigs{} is to provide
fast\index{speed}, intuitive\index{intuitive facilities},
extensible\index{extensibility}, integrated,\index{integrated
facilities} \idx{interactive facilities} for
\begin{enumerate}
\item \kw{Visualisation} of experimental and related theoretical
data of types discussed in chapter~\ref{chap:database};\label{vis}
\item General \kw[data!manipulation]{manipulation} of such data (see
chapter~\ref{chap:analysis});
\item \kw{Presentation graphics} derived from the above
functions (see chapter~\ref{chap:pubgraph});\label{pubgraph} 
\item A graphical interface\index{graphical!interface} for
\kw{control} and \kw{monitoring} of (possibly remote) systems for:
\begin{itemize}
\item data acquisition\index{data!acquisition};
\item setup\index{setup!equipment} of experimental equipment;
\item \idx{sorting};
\item \idx{verification} of the systems' operation.
\end{itemize}
\end{enumerate}
There is an intentional distinction between items \ref{vis} and
\ref{pubgraph}.  The expectation is that graphics for the former will be
simpler, quicker and easier to use than the latter. \kw[integrated
facilities]{Integrated} implies that the various facilities are
coordinated and can communicate with each other.

The system should co-exist happily with other
tools\index{tools!general-purpose computing} in a \idx{general-purpose
computing} environment i.e., one should be able to run
applications---like an editor or a mail tool---other than data
analysis\index{data!analysis} at the same time on the same display.

\section{Restrictions}

\begin{itemize}
\item
Display of data will be restricted to $x$ v.\ $y$ or $z$ v.\
$(x,y)$,\index{dimensionality!of displayed
data}\index{restrictions!dimensionality of displayed data} the latter
represented as \idx{contour}s or \idx{images} rather than
`\idx{wireframes}', \idx{solid surfaces}
etc;\index{restrictions!representation of displayed data}
\item Animation\index{animation} is not required;
\item Other than red-green \idx{colour blindness}, possible disabilities
\index{user!disabled} of users e.g., deafness, will not be taken
into account; 
\item Foreign languages\index{foreign
languages}\index{language!foreign}\index{restrictions!language} will
not be supported (see \S\ref{foreign}).
\end{itemize}

%\include{structure}


% -*-LaTeX-*-
\chapter{System structure}

\section{Generalities}\label{dm-and-scripts}

The system is expected to be based on a \kw{WIMP}-orientated networked
\kw{windowing system} with \kw{multi-tasking} at the user level.  This
will fulfill the requirement that the analysis system is well
integrated with the general computing
environment\index{general-purpose computing} and will provide the
means for the most important departures of the new system from the old
one.  The primary means of interaction\index{interaction!means of}
will be by \kw{direct manipulation} (with a \idx{mouse}), but it
should be possible also to use it in a \kw{command-driven} manner (by
typing,\index{typing} commands\index{commands!typing} as possible at
present).  

Consideration should be given to providing other \index{input
devices} such as
\begin{itemize} 
\item \idx{knob}s (as on the \index{accelerator!control
system}\index{control!accelerator}accelerator control system) to make
interaction with \index{analogue!devices}analogue devices easier when
controlling apparatus\index{control!apparatus};
\item the \idx{button box} on the \idx{Sension} system to provide
customised short cuts, although keyboard function \idx{keypads} may
suffice;
\item \idx{dials} for changing range, as provided on the Liverpool
\idx{Sigma3} system. 
\end{itemize}

As well as \idx{direct manipulation}, it should also be possible to
\kw[programming]{program} the system and it is important that it be readily
\kw[extensibility]{extensible}, even by the relatively inexpert, so
that specialised or time-saving
facilities\index{facilities!time-saving} can be incorporated according
to the user's task in hand.  In particular, there should be a
well-defined interface\index{interface!system}\index{system!interface}
to the system so that application code\index{application
code!importing}\index{importing|see{application code}} may be readily
imported and adapted to use the facilities of the graphical
interface\index{graphical!interface}, \idx{data base} etc.  The
requirement to incorporate new
\idx{application code} thus (as well as experience and prevailing wisdom)
means that the existing \idx{structure} of a collection of relatively
small \idx{program}s glued\index{glue, for system components} together
with an interpretive \kw{shell} (currently \idx{GEC} {\tt
COMM}\index{COMM@{\tt COMM}}) should be maintained.  (`Shell' does not
necessarily mean a {\tt sh}\index{sh@{\tt sh}} derivative.)  Such a
feature is important to provide customisability and maintainability.

\section{Shell facilities}\index{facilities!shell}\index{shell!facilities}

The \idx{shell} must provide an interactive general (i.e.,
\idx{Turing-equivalent})\index{shell!Turing-equivalence} programming
facility, allowing control constructs\index{shell!control constructs}
like {\bf if}\dots{\bf then}\dots{\bf else} and {\bf while}.  It
should also support internal variables\index{shell!variables} of
convenient types and thus means of assigning and extracting their
values.  Its primary purpose is \kw{process control} by running
programs (using operating system facilities) and passing instructions
to parts of the interface.  For running programs it will be helpful if
it supports an interface for passing parameters\index{shell!parameter
passing}\index{parameters!passed by shell} along the lines of GEC {\tt
COMM}'s\index{COMM@{\tt COMM}} \kw{proforma} system rather than the ad
hoc parameter decoding of \ux.  The shell
language\index{language!shell} must be interpreted,\index{interpreted
language} although it may be helpful to allow \idx{compilation} for
performance-critical applications.  The choice seems to be between a
\idx{macro-processor} like {\tt COMM}\index{COMM@{\tt COMM}} or {\tt
sh}\index{sh@{\tt sh}} and an \idx{evaluating system} like \idx{Lisp}.
It is important that user-defined routines\slash macros\slash
functions\index{shell!routines\slash macros\slash functions}
(according to the implementation) are available.  Timing
facilities\index{timing facilities} are important for \idx{experiment}
control\index{control!experiment}; the ability to achieve the same
effect as {\tt COMM}'s\index{COMM@{\tt COMM}} \index{EVENT@{\tt
EVENT}}{\tt EVENT} facility is needed.

\section{Programmability\slash extensibility}

There are essentially two kinds of programming\slash
\idx{customisation}\slash \idx{extensibility} envisaged.
\kw{programmability} involves relatively trivial use of existing
facilities for purposes such as automating\index{automation} tasks
like looping through a set of spectra doing the same operation on
each.  \kw{Extensibility} means adding significant facilities like
importing\index{application code!importing} a program that writes a
paper about
\idx{superdeformation} given a $\gamma$-$\gamma$ dataset as input and
requires a graphical interface\index{graphical!interface} (presumably
only for minor editing of the output!).

Repetitive tasks\index{repetitive tasks} can be accommodated either by
allowing users to write \idx{macros} in an appropriate \kw{scripting
language}\index{language!scripting} (c.f.\ \kw[shell!scripts]{shell
scripts}) or by
\kw{learning} a set of actions consisting of \idx{direct manipulation}
with the \idx{mouse} and/or \idx{typing} of relevant input.  \emacs{}
provides a model for both facilities (and several other facilities
discussed in this document).  Both ways of handling such tasks should
be available.

Graphical \idx{extensibility}\index{graphical!extensibility} should be
provided following the \idx{HyperCard} model of
persistent,\index{persistent objects}
directly-manipulable\index{direct manipulation} interface components.
Thus one should be able to copy a `\idx{widget}' from an existing
application, paste\index{cut and paste} it into another one and then
customise\index{customisation} its behaviour with a suitable
\idx{scripting language}.

\section{Modes}\label{foreign}

It may be desirable to provide one or more \kw{modes} e.g., for expert
or na\"\i ve users\index{user}s\index{naive users@na\"\i ve
users}\index{expert users} to determine trades off of
\idx{perspicuity} against \idx{speed} and \idx{power}, for instance.
The possibility of providing \idx{foreign
languages}\index{language!foreign} modes (as, for instance with
alternative `\idx{resource files}' in \idx{MacApp} and
\acr{Gem},\index{Gem@\acr{Gem}} {\tt .Xdefaults}\index{Xdefaults@{\tt
.Xdefaults}} with \idx{X11}\index{windowing system!X11} or
\idx{NeWS}\index{windowing system!NeWS}
dictionaries\index{dictionary!NeWS}) is probably not worth the
effort\footnote{Parameterising \idx{message}s, help text etc.\ will
tend to compromise its quality in the author's opinion and fighting
this tendency will take the effort.  The existing \idx{NeWS} prototype
system does implement a polyglot\index{polyglot buttons\slash menus}
button\slash\idx{menu} system, however.};
(\index{online!dictionaries}\index{dictionary}online
dictionaries\slash
\idx{phrasebook}s may be obtainable!).  

\section{Interfaces to other systems}

\subsection{Data-acquisition/sorting system}\index{data acquisition}%
\index{sorting}

The main requirement will be to issue commands\index{commands!sorting}
to the system for tasks such as
\begin{itemize}
\item stop/start;
\item change configuration (e.g., sort commands);
\item change tape/file, premount tape;
\item save datasets to disc.
\end{itemize}

Display of parameters\index{display!parameters from acquisition\slash
sorting} such as tape status will also be required.  The display of
sorted\slash histogrammed data from such systems is automatically
included in the required uniform \index{data base!interface} data base
interface\index{interface!data base}(\S\ref{uniform-db}).  Data base
window objects\index{window!data base object} should be freely
exchangeable between the sorting and analysis systems (preferably by
some sort of
\idx{cut and paste}) to allow sort windows to be edited
graphically\index{graphical!editing}\index{editing!graphical} in
comparison with a spectrum of the relevant parameter(s).

\subsection{Apparatus control and monitoring}

\index{apparatus}\index{control}\index{monitoring}
The main need will be for graphical devices\index{graphical!devices}
for \idx{readout} and control of
\index{analogue!parameters}\index{parameters!analogue}analogue
parameters e.g., \idx{dials}, knobs\index{knob}, \idx{barcharts}.  A
physical knob would probably be useful.  It is expected that \kw{mimic
diagrams} of the system to be controlled will be available as
currently provided in the \idx{NSF} \index{accelerator!control
system}\index{control!accelerator}accelerator control system.  Such a
diagram is a schematic of the apparatus with active components of the
diagram corresponding to apparatus components which may be selected
for control or monitoring.

\subsection{Exception server}

See \S\ref{external-exceptions}.

\section{Slice server}

\index{slices}
There will be a need for a separate server to deal with operations on
\idx{large datasets}.  The criterion for being `large' is that they won't
fit realistically in main \idx{memory} in the graphics system
and\slash or would take an unacceptably long time to load into it from
mass storage (which will probably be accessed over the LAN\index{local
area network})\@.  Typical tasks for the server would be making a
projected slice of a dataset residing in its local storage for
graphical display, the parameters being defined by a
window\index{window!record}\index{editing!window} edited using the
display of a previously-obtained projection.

\section{Application programs and libraries}

Libraries\index{application libraries}\index{library!application}
(callable from Fortran77, Fortran90\index{Fortran} (when available)
and \idx{C}) must be provided to support the operations defined in
this document.  These will include \idx{data base!operations}data base
operations, control\index{control!interface components} of interface
components (e.g., window display), \idx{message} passing to other
systems, \idx{command line} \idx{argument decoding}, graphics
functions\index{graphics!functions}.  These will define a clean
\idx{interface} against which \idx{application program}s can be written or
imported.  The way this works will obviously depend on the
implementation of the \idx{shell}.

%\include{database}

%-*-LaTeX-*-
\chapter{Data base aspects}\label{chap:database}

\index{data base|(}
The system is required to deal both with data structures
(\kw{spectra}) obtained directly from experiments by \kw{sorting} or
\kw[histogram!readout]{histogram readout}\index{readout!histogram}
and with related data typically derived from \idx{analysis} of
experimental or data from theory\index{theory, data from} (e.g., fits
to the data).  This chapter describes the data types\index{data
types}\index{data base!data types} required to be stored and
operations\index{operation!data base} the data base system by which they
are accessed is required to support.

\section{Data types}

\index{data base!data types}\index{data types}
Several different types of item may occur in the data base, as follows.

\subsection{Spectra}

\subsubsection{General definition}

Spectra\index{spectra} comprise \kw{count}s associated with an array
of \kw[channel]{channels} which comprise uniformly-spaced \idx{bins}.
Spectra can only be displayed if they are
\kw[spectra!one-dimensional]{1-dimensional} ($x\mapsto
\mbox{\it counts}$) or \kw[spectra!two-dimensional]{2-dimensional
spectra} ($(x,y)\mapsto\mbox{\it counts}$).  Higher
dimensionality\index{dimensionality!higher than two} may be required,
but spectra with three or more dimensions\index{spectra!three or more
dimensions} will not be capable of being displayed.  $x$ and $y$ are
signed 16-bit integer quantities.\index{precision} {\it counts\/} are
signed 16- or 32-bit integer quantities, chosen according to the
maximum intensity of spectra.\index{spectra!precision} The range in
$(x,y)$ which may be displayed will be limited.\index{display!range of
spectra}\index{range!display}
% non-functional spec 
To visualise them it will be necessary to make lower-dimension
\kw{sections} (\kw{cuts} or \kw{slices}) which can be displayed,
either directly or following storage.

\subsubsection{Stored and live spectra}

Spectra occur in two types: 
\begin{description}
\item[\kw{Stored spectra}]\index{spectra!stored} reside in permanent
storage\index{storage!permanent} (presumably disc),\index{disc
storage} having been created by \idx{sorting},
manipulation\index{spectra!manipulation} of other spectra or
\kw[saving spectra]{saving} \idx{live spectra};\index{spectra!live}
\item[\kw{Live spectra}]\index{spectra!live} are resident in the
data-acquisition\slash\index{data acquisition!system}\index{sort
system}sorting system rather than in disc \idx{file}s in the usual
user filespace.  They are potentially continually updated, certainly
updateable, by the
acquisition\index{data!acquisition}\slash\idx{sorting} system.
\end{description}

\subsubsection{Associated entities}

Associated with spectra there may be the following optional entities:
\begin{description}
\item[A {\sl title}]\index{title}\index{spectrum!title} giving a
brief description of the spectrum.  This should be a text record at
least 80 bytes long.  It is expected to be modified by operations
which create new spectra\index{spectra!creating}\index{creating
spectra} from old ones to give e.g.,
\begin{quote}\small
\verb`Total projection, y-scaled (y'=0+.5y)`
\end{quote}
\item[\kw{Comments}]\index{spectrum!comments} giving
a more detailed description of the spectrum.
Comments\index{comments!size of} are textual records with a size
expected to be a paragraph or so describing, for instance, the
conditions under which the spectrum was generated.  (Not currently
supported);
\item[A \kw{calibration}]
\index{spectrum!calibration}\index{energy
calibration}\index{calibration!energy} which maps between channel
number and physical
units\index{units!calibration}\index{calibration!units} (typically keV
or MeV)\@.  Calibrations are allowed for any dimensionality of spectra
supported by the system, but with independent functions for each
dimension i.e., no correlations.  As a minimum, the method of
Wooff\index{Wooff, C. D.} \cite{wooff} should be employed for energy
calibration\index{calibration!energy} in terms of polynomials up to
cubic.  To generate the calibration a set of sufficient points to fit
is required, comprising channel (as a real number), corresponding
energy and errors on both.  The calibration is stored as the
coefficients of the fitted polynomial along with the error matrix.  It
has associated \kw{units}.  Software should be aware of common
\idx{conversion factors} e.g., keV$\leftrightarrow$MeV\@.  The
implementation should not preclude adding other forms for the
calibration function\index{calibration!function}, should they be
required in the future.  One possibility is a square root function if
spectra are re-binned\index{re-binning} to keep peaks roughly the same
width.  The coefficients of the polynomial may have associated errors
which must propagate through to the physical unit derived from them.
The ability to use more general function when appropriate should be
available;
\item[An {\sl efficiency calibration}]\index{efficiency
calibration}\index{calibration!efficiency} which specifies how to
correct for \idx{detector efficiency}, probably best expressed as an
interpolation function.  A weighted cubic \idx{spline} is probably
best.  It will be specified in terms of a fit to points comprising
(channel, efficiency, channel error, efficiency error) with
automatically-chosen knots so as to satisfy some smoothness criterion
which should be user-specifiable.  The \acr{nag} library \cite{nag}
provides suitable technology.  Note, however, that, error
estimates\index{error!estimates} for the resulting calibration are not
easily determined.  The fitted calibration will be stored in terms of
a variable number of knots, although there will be an upper
limit\index{limit!number of knots in efficiency function} to
this number which the fit has to observe.  This will be used by
\idx{application program}s which determine
\index{peak!intensities}peak intensities,\index{intensity, peak} for
instance.  Multi-dimensional data are treated as for energy
calibrations.  (Not currently fully supported);
\item[An {\sl error spectrum}]\index{error!spectrum} which defines the
\kw{standard error}\index{error!standard} associated with the counts in each
channel for use by analysis programs such as \idx{least-squares
fitting}\index{fitting}.  The error spectrum may be given implicitly
by specifying \kw{counting errors} i.e., the \idx{standard error} on
the counts is derived assuming they obey \idx{Poisson statistics}.
Spectra containing
\idx{negative counts}\index{count!negative} cannot have counting
errors.  Errors are real quantities.  (Not currently fully supported.);
\item[\kw{Partitions}]\index{spectrum!partitions} whereby
sections of a spectrum may be referred to by the partition name.  Each
name is associated with a range of channels.  This facility is useful
for dealing with \kw[spectra!routed]{routed} spectra\index{routed
spectra} in particular.  The current convention of referring to
partitions as
\meta{spectrum}{\tt[}\meta{partition}{\tt]} should be retained.  This
will exclude {\tt[} and {\tt]} (possibly just {\tt[}) from `normal'
names describing unpartitioned spectra.  Partitions are currently
referred to as \kw{sub-ranges}.
\end{description}

\subsubsection{Scalers}

\kw[scalers]{Scalers} are effectively degenerate spectra with only one 32-bit
channel, but need to be supported as a separate type.  They may only have
associated \kw{comments} and \kw[title]{titles}.

\subsection{Non-spectral data}

\kw[non-spectral data]{Non-spectral data}\index{data!non-spectral}
only occur in \kw[stored spectra]{stored} form, not \kw[live
spectra]{live}.  They may have associated \kw[title]{titles} and
\kw{comments} as for spectra.

\subsubsection{Graphs}

\kw[graphs!(data type)]{Graphs} comprise real $(x,y)$ data which are
not required to be uniformly binned, unlike spectra.  The data
points\index{data!points, graph} may have associated (real)
\kw[errors!graph]{errors} in $x$ and/or $y$.  The `plus' and `minus'
errors may be different.  A better term\index{graphs!better term for}
to avoid confusion with the mathematical idea of a graph would be
welcome.  (Graphs are not currently supported.)

\subsubsection{Maps}

\kw{Maps} comprise real $(x,y,z)$ data where the $x$
and $y$ values are not required to be uniformly spaced, unlike
2-dimensional spectra\index{spectra!two-dimensional}.
Errors\index{errors!map} on the $z$ values may be given\footnote{Is this
sensible?}.  The `plus' and `minus' errors may be different.  (Not
currently supported.)

\subsection{Notes}

\kw{Notes} contain text\index{text!as opposed to
data} rather than `data' in the sense usually understood by
scientists.  They provide some description of the data at the current
level of the hierarchy\index{data base!hierarchy}\index{hierarchy} as
distinct from the \idx{comments} in spectra etc.  A typical use is to
contain the sort commands\index{sort!commands} used to generate a set
of spectra.  Notes are currently not supported explicitly but are
available by using \index{text!files}text files in an
\idx{SDB}\index{spectrum data base|see{SDB}} catalogue.

\subsection{Window records}

\kw[window!record]{Window records} are used by the \index{sort
system}sort system \cite{sort-lang} to define \kw{gates} which
filter\index{data!filtering, sort}\index{filtering data} the data flow
in the \idx{sort}.  They need to be accessible by the graphics
system\index{graphics!system} as well as the \idx{sort system} so that
they can be displayed with spectra formed from the parameters that
they filter and re-defined\index{window!record!re-defining}
interactively to select the appropriate region of the spectrum.  They
are also used to define \idx{slices} of multi-dimensional
\index{spectra!multi-dimensional}spectra.  They have
\kw[title]{titles} and
\kw{comments}.  The `definitive'
version\index{window!record!definitive version} of a record presumably
does not reside in the data base under consideration here but in the
\idx{sort system}.  It will, however, be helpful to store such records
permanently along with the data they refer to.

\section{User's view and implementation implications}

\index{data base!implementation}\index{data base!users' view}
Users need to see a \index{hierarchy}hierarchical structure to the
data base.\index{data base!hierarchical structure} They will want, for
instance, to group data\index{data!grouping}\index{grouping of data}
according to \kw{experiment} and \kw{run} within that experiment.
Each component\index{data base!hierarchy component} (a hierarchy or an
individual spectrum) is referred to by a name\index{name!data base
component}\index{data base!component names} which should be able to be
fairly explanatory i.e., not too short or \idx{character
set}-restrictive.  Typical examples might be:
\begin{quote}\begin{verbatim}
Break-up_run_Jan_92
telescope1_deltaE
\end{verbatim}
\end{quote}
An individual spectrum etc.\ is referenced by a concatenation of
hierarchy names and the name of the item at the lowest level.

These required features suggest that individual spectra etc.\ should
be stored as individual \idx{file}s in the \ux{} \idx{filing system}.
Then the \index{directory!structure}directory structure provides the
\idx{hierarchy} and legal file/path names\index{file!names} may be
sufficiently general.  This approach is adopted in the current
\idx{SDB} system, albeit with the requirement of descriptive names
rather relaxed; maintaining it has benefits such as:
\begin{itemize}
\item familiarity to users both of \ux{} and the current system;
\item convenience of use and implementation---many of the required
features are already provided by the filing system, including such
advanced ones as distribution over the network.
\end{itemize}

It is thus made a \idx{non-functional requirement} that the \ux{}
\idx{filing system} provides the basis of the database\index{data
base!required to use filing system} for \kw[saved!data]{saved} data,
with \idx{spectra}\slash\idx{graphs}\slash\idx{maps}\slash\idx{notes}
stored\index{storage!data base items} one per \idx{file} (although it
might be convenient to allow several \idx{scalers} in one file).
Individual files in the database should have an
\kw[file!extension]{extension} which indicates the type of the
\index{data!items!type indication}data item (1-d or 2-d
spectrum,\index{spectra!one-dimensional}\index{spectra!two-dimensional} 
graph etc.).  This will help the implementation to present only the
relevant items for selection for a specific operation e.g., the user
should not be presented with a list containing 2-d spectra when
required to select one to overlap (\S\ref{misleading-info}).

Although most users are expected to be familiar with the filing
system, the data base interface\index{data
base!interface}\index{interface!data base} for na\"\i ve
users\index{users, na\"\i ve} should not require such familiarity.

\subsection{Live spectra}

\label{uniform-db}
The data base and display should present a uniform view to the user,
whether the data are live or saved.\index{spectra!live}\index{live
spectra} Thus for instance, it should not be necessary to operate in a
special \kw[online!mode]{online mode}\index{modes!online} to display
and analyse live spectra.  It is important from a user's point of view
that the design addresses this point carefully.

Since saved spectra\index{saved!spectra}\index{spectra!saved} are
expected to live in the \idx{filing system}, to maintain
uniformity\index{uniformity, of live and saved spectra} \kw[live
spectra]{live} spectra have at least to appear to reside in the filing
system also.  It would be most satisfactory to have them actually
accessible as a \idx{virtual filesystem}, but this is apparently
un-implementable.\index{spectra!live!appearing to be files} Thus
utilities and libraries\index{library!application} that access live
spectra should take care to treat them so that they appear to be
files, probably living in a flat directory.\index{directory!flat, for
live spectra} The assumption is made elsewhere in this document that
this is how live spectra appear.

\section{Data base operations}
\label{ops}

Various operations must be supported on the data
items\index{data!items, operations on}.  Some of these are trivially
present if the data base is based on the \idx{filing system}.  They
should all be available through a library\index{library!application}
that can be linked with \idx{application program}s.  Where operations
are allowed on \idx{sets of items}\index{data base!items!sets of} the
members of such sets should be definable by \kw{pattern-matching} of
the names.  Simple \idx{regular expression} matching may not be most
appropriate e.g., it can't pick out a general \idx{numerical range}
like `15--23'.  The user will optionally be asked for confirmation
when requesting a \idx{destructive
operation}\index{operation!destructive} like a \index{deletion!of data
base items}deletion or \idx{over-writing} or one awkward to
\idx{undo} like a multiple re-calibration.

\subsection{Atomic operations}

\index{operation!atomic}\index{atomic operations}
These operations relate to entire \idx{data structures} in the data
base, which may be \idx{spectra}, \idx{graphs}, \idx{maps},
\idx{notes} or \index{hierarchy}hierarchies.  In some cases the
operation is considered to be obvious with no further explanation
given.  (See also \S\ref{more-ops}.)

\subsubsection{Copying}

\index{copying, data base items}\index{data base!operations!copying}
There are two cases:
\begin{enumerate}
\item Copying at the same level (the same directory).  In this
case the user or application\index{application program} must supply a
new name\index{new!name}\index{name!new};
\item Copying to a different level.  The copy's
location must be given and the name is maintained.
\end{enumerate}

\subsubsection{Deletion}

\index{deletion!of data base items}\index{data base!operations!deletion}
The name of the item to be deleted should optionally be subject to
\idx{confirmation}.

\subsubsection{Creation}

\index{creation of data base items}\index{data base!operations!creation}
It must be possible to create new (empty)\index{empty items} instances
of item types.  Usually this will be done by \idx{application
program}s, often automatically.  It is likely that users will require
to be able to select different \kw[policy!name generation]{policies}
for generating names\index{name!generation of} automatically in
situations like \idx{re-scaling} data\index{data!re-scaling}.  A
typical such policy is to increment a trailing number\index{trailing
number (in item name)} in the item's name such that it is unique at
the current level of \idx{hierarchy} or, if the name does not already
end in a number append `{\tt 1}' or `{\tt 01}'.  Alternatively a new
name\index{name!new} may be solicited from the user; this will
probably always be done if it is a new
\idx{sub-tree} of the hierarchy that is being created.

\subsubsection{Interrogation}

\index{interrogation of data base items} \index{data
base!operations!interrogation} The \idx{parameters} of the item must
be accessible, such as a spectrum's maximum\index{maximum counts} and
minimum\index{minimum counts}\index{count!maximum and minimum}
$(x,y,z)$ values, \idx{calibration}, \idx{dimensionality} etc.  In the
case of a node\index{node of hierarchy} of the \idx{hierarchy} it may
be desirable to extract the names of its \idx{siblings}, but this is
the only such information it is sensible to require.  This might be
considered a \idx{non-atomic operation}\index{operation!non-atomic}
(\S\ref{non-atomic}).

\subsection{Non-atomic operations}

\label{non-atomic}\index{operation!non-atomic}\index{non-atomic operation}
These operations are intended to read or write {\em part\/} of the
data structure\index{data!structure, part of}.  Again, some are
thought to be self-explanatory.

\subsubsection{General}

\begin{description}
\item[\op{Write title}];\index{operation!write title@{\sl
write title}}
\item[\op{Read title}];\index{operation!read title@{\sl read title}}
\item[\op{Write comment}]\index{operation!write comment@{\sl
write comment}} adds a comment to the item; 
\item[\op{Read comments}]\index{operation!read comment@{\sl
read comment}} Since \idx{multiple comments}\index{comments!multiple}
are allowed in an item, this operation should return all of them as a
list;
\item[\op{Delete comment}]\index{operation!delete
comment@{\sl delete comment}} deletes a comment specified by
its position in the list as returned by \op{read comments}.
\end{description}

\subsubsection{Spectra}

\index{spectra}\index{operation!partitioned spectra}
In the case of \idx{partitions} the channel specifications for the
operations below are relative to the partition origin.

\begin{description}
\item[\op{Read channel contents}];\index{operation!read channel
contents@{\sl read channel contents}}
\item[\op{Write channel contents}];\index{operation!write channel
contents@{\sl write channel contents}}
\item[\op{Read channel block}]\index{operation!read channel
block@{\sl read channel block}}\index{block!read channel@{\sl read
channel}} returns an \idx{array of channel contents} rather than a
single content (for convenience and efficiency).  It requires a
starting channel, the number of channels to read and an array to fill.
The earlier dimensions of multi-dimensional
spectra\index{spectra!dimension order}\index{dimension order of
spectra}\index{order!spectrum dimensions} vary fastest, as per the
\idx{Fortran} convention;
\item[\op{Write channel block}] as per \op{read channel
block};\index{operation!write channel block@{\sl write
channel block}}
\item[\op{Read channel error}];\index{operation!read channel
error@{\sl read channel error}}
\item[\op{Write channel error}];\index{operation!write channel
error@{\sl write channel error}}
\item[\op{Read error block}] similar to \op{read channel
block};\index{operation!read error block@{\sl read error block}}
\item[\op{Write error block}];\index{operation!write error
block@{\sl write error block}}
\item[\op{Read calibration}] [The format of a calibration needs
defining]; \index{operation!read calibration@{\sl read
calibration}}
\item[\op{Write calibration}];\index{operation!write
calibration@{\sl write calibration}}
\item[\op{Read efficiency calibration}]; \index{operation!read
efficiency calibration@{\sl read efficiency calibration}}
\item[\op{Write efficiency calibration}]; \index{operation!write
efficiency calibration@{\sl write efficiency calibration}} 
\item[\op{Copy calibration}] Copies the calibration from one spectrum
to another of the same dimensionality or to all those of this
dimensionality beneath a specified level in the
hierarchy;\index{operation!copy efficiency calibration@{\sl
copy efficiency calibration}}
\item[\op{Copy efficiency calibration}] Similar to \op{copy
calibration}. \index{operation!copy efficiency
calibration@{\sl copy efficiency calibration}};
\end{description}

Actual energy\index{calibration!energy} or efficiency
calibration\index{efficiency!calibration}\index{calibration!efficiency}
of individual channel contents\index{channel!contents} will be
provided by the application library\index{library!application} from
the extracted calibration.

\subsubsection{Graphs and maps}

Since we expect \idx{graphs} and \idx{maps} to have relatively few
data points operations are only supported to read\slash write the
entire dataset.

\begin{description}
\item[\op{Read graph data}] returns the number of data points and
errors, given arrays to fill with them; \index{operation!read graph
data@{\sl read graph data}}
\item[\op{Write graph data}] write data and \idx{errors}, specifying the
number of points and type of error\index{error!type of} ($x$, $y$ or
$x$/$y$); \index{operation!write graph data@{\sl write graph data}} 
\item[\op{Read map data}] as per graphs; \index{operation!read map
data@{\sl read map data}}
\item[\op{Write map data}] as per graphs. \index{operation!write map
data@{\sl write map data}}
\end{description}

\subsubsection{Window records}

\index{window!record}
Records are expected to be accessed whole, rather than at the level of
individual \kw{gates}.
\begin{description}
\item[\op{Read window}];\index{operation!read window@{\sl
read window}} 
\item[\op{Write window}].\index{operation!write window@{\sl
write window}}
\end{description}

\section{Data integrity}

\index{data!integrity}\index{integrity of data}
Since the system is expected to operate on top of a
\index{distributed!filing system}distributed filing
system\index{filing system!distributed} it is possible for items like
spectra to be modified (even deleted) underneath an
\idx{application program} that is trying to deal with them.  It doesn't seem
possible to prevent this in a sensible way.  Some means of dealing
with files\index{file!changed} that have changed this way has to be
provided, however, if they are going to be updated by an application.
At least the approach taken by \emacs{} should be adopted.  This
remembers the \idx{modification time}\index{file!modification time} on
files that it has read in and warns, for instance, if a file onto
which it is about to write back has been modified since it was read.
Solutions involving \idx{locking} seem too vulnerable to the lock not being
undone, and, anyway one is hoping to be able to use standard system
utilities on the files comprising the data base and so cannot prevent
them being altered at will by anyone with write access.

\section{External representation}

\index{ER|(}
An \kw[external representation|see{ER}]{external representation} (ER)
of internal data structures\index{internal!data structures}
\index{data structures!internal} is required that will allow easy
\idx{portability} of data to sites with different systems.  (The
\kw[internal!representation]{internal representation}
(IR\index{IR|see{internal representation}}) is expected itself to be
conveniently and efficiently transportable
\index{data!transporting}\index{transporting data} (e.g., by
\idx{NIFTP}) between \idx{NSF-supported sites}, especially if it is
just based on the \idx{filing system}.)  The requirements for the ER
are outlined in the following.  The current ER\index{SDB} is described
in~\cite{sdb-er}.

\subsection{Scope}

The ER should support all the features of the data base such that
transforming from \index{internal representation}IR to ER and then
back to IR has no effect.  Thus, in particular, the ER should be
able to express the
\idx{hierarchy} of the \index{internal representation}IR\@.  This is
not currently done~\cite{sdb-er}.\index{SDB} It is not clear to what
extent this can be done properly portably.  Utilities\index{utilities}
such as {\tt tar}\index{tar@{\tt tar}} and {\tt arc}\index{arc@{\tt
arc}} provide a model for transporting hierarchies\index{hierarchy}
(directory trees\index{directory!tree}), but some systems (e.g.,
\idx{MVS}) have
\idx{flat file stores} that would prevent mapping the ER hierarchy
conveniently onto the host file store on unpacking.

\subsection{Portability considerations}

\index{portability}
The ER should contain only printable\index{printable characters}
\acr{ascii}\index{ascii@\acr{ascii}}\index{character set} characters
(apart from those delimiting record boundaries).  It should contain
\kw{records} no more than 80 bytes long.  The ER may contain either
\kw{fixed length records} or \kw{variable length records} as
appropriate for the
\index{target system}\index{system!target}target system.  Where
\index{hierarchy}hierarchies are involved {\tt tar}\index{tar@{\tt
tar}} format should probably be used since a \idx{GNU} implementation
of the program is generally available.  Where the ER is transported on
magnetic or other storage media\index{storage!media}, the format of
the media should conform to the \acr{ansi} standard\index{ANSI
standard@\acr{ansi} standard!tape labels} for labelled tapes
\cite{ansi-tape} or to the {\tt tar}\index{tar@{\tt tar}} format
\index{tape format}\index{format!tape}\cite{tar}.  Block
lengths\index{block length} should be no more than 8\,k\,bytes.

Requiring \idx{portability} will obviously compromise what it is
sensible to transport this way---it is not envisaged that a
4k$\times$4k channel dataset\index{transporting data}\index{large
datasets} would be transported in a \idx{text} representation.  The ER
is aimed at applications like taking home saved copies of `small'
online histograms\index{online!histograms}.  The onus will be on the
foreign site to do any necessary translation of the \index{internal
representation}IR for very
\idx{large datasets}; the IR
\index{internal!representation!documentation
of}\index{documentation!of IR} should be appropriately documented to
allow this.

\subsection{Ease of translation}

\index{translation}
The structure of the ER should be designed for easy interpretation and
extraction of the data.  An existence proof of this should be
available in the form of standard Fortran77\index{Fortran!Fortran77}
routines for translating ER data types to Fortran arrays.  The
current scheme\index{SDB} \cite{sdb-er} makes life difficult by mixing
a format largely compatible with Fortran
`\idx{free-format}'\index{format!free} with {\tt CHANNEL}
statements,\index{channel statements@{\tt CHANNEL} statements} which
are not.

\subsection{External representation operations}

\label{more-ops}
In addition to the operations\index{operation!ER} on items detailed in
\S\ref{ops}, operations must obviously be provided for transforming
data between the internal\index{internal!representation} and external
representations.

\subsection{Window records}

The ER for \index{window!record}window records should be taken from
the sort language\index{sort!language}\index{language!sort} definition
\cite{sort-lang}.
\index{ER|)}

\section{Compatibility with present system}

\index{compatibility!with SDB}
The new system will be required to run in parallel with the present
one in some overlap period.  This means that the new data base should
be in a form that can be made to work with the old one, \idx{SDB}
\cite{sdb}, (if necessary by small modifications to SDB to avoid
compromising the new design).  This is another reason for requiring
that the data base is implemented on top of the \idx{filing system}.

% \section{Internal representations and dataset sizes}
% 
% \index{internal representation}
% It is likely that very \idx{large datasets}\index{dataset!large} will
% have a different IR\index{internal representation} from normal since
% they are likely to be sparse\index{dataset!sparse}\index{sparse data}.
% If this is the case, the interface should be transparent to the
% internal representation; thus it should be irrelevant whether the
% section of spectrum asked for is stored as a simple array, a binary
% tree,\index{tree, binary} partially ordered list or whatever.  A limit
% will clearly have to be imposed on the size of section that can be
% dealt with by the \idx{graphics system}, however.
% 
\index{data base|)}

%\include{display}

%-*-LaTeX-*-
\chapter{Displaying data}

\section{Data Boxes}

\index{data boxes|(}
Data are to be displayed in a number of \kw[boxes, data]{boxes}.
There is a pre-defined \index{limit!number of displayed boxes}limit on
the number which may be displayed together, proposed as 12.  \kw{One
dimensional} ($(x,y)$) or
\kw[two-dimensional!data]{two-dimensional} ($(x,y,z)$) data may be
displayed in these.  One-dimensional datasets (e.g., \idx{spectra},
\idx{fits}) may be overlapped\index{overlapped!items} in a box;
\idx{two-dimensional!data}two-dimensional data may not\footnote{A
decision is needed about whether spectra
\index{overlapping!policy}\index{policy!overlapping} should be
overlapped according to corresponding channels, as at present, or,
more logically, according to corresponding
\idx{calibration}.  In the latter case, it is either forbidden to
overlap calibrated and \idx{uncalibrated spectra} or one should assume
that uncalibrated ones have the same calibration as, say, the last
calibrated one to be added.}.  Other objects may be displayed in
boxes, viz.\ \kw{markers}, \kw{window}s and \kw{fits}.  Boxes have attached
\kw{annotation} showing their limits (e.g., upper and lower channels)
and the \kw{name} of the \kw[current!dataset]{current dataset} or, if
there is not a current one, the last selected\index{last selected
dataset}.  Overlapped datasets may be distinguished by \idx{colour} or
display style\index{display!style} e.g., \kw{histogram}, \kw{dashed
histogram}, \kw{polymarker}.  Boxes may optionally have \kw{axes}
(\kw[annotation]{annotated} in terms of channel number or an
appropriate \idx{calibration}).  In the absence of axes, the minimum
and maxmimum $x$ and $y$ values should be indicated.  The name of the
current dataset should be displayed in the box.

Various operations\index{operation!on displayed box contents} are
required on the contents of the boxes.  These fall into two
categories: changing the display \idx{parameters} (e.g., \kw{panning}
and \kw{zooming}) and changing the data (e.g., overlapping or
removing).  When more than one box is displayed many of these
operations are applicable either to a particular box or to all the
boxes at once.  Either type of operation should be easily selectable
(preferably without having to change some `option' in a special
window, analogous to the present system).  Some sort of \kw{control
panel} separate from the data boxes will be required for \idx{global
operations} and will have to fulfill some of the functions of a
window manager\index{window!manager}.
\index{data boxes|)}

\section{Contents of data boxes}

\index{objects!displayed}
Boxes may contain the following objects.  Those of different
dimensions are mutually exclusive.
\begin{description}
\item[\idx{one-dimensional spectra}] usually displayed as
\idx{histogram}s.  These should be displayed so as to give an accurate
impression of the local minimum and maximum
excursions\index{excursions in $y$} in $y$---note that
\idx{re-binning} the data to one channel\slash \idx{pixel} does not do
so;
\item[two-dimensional spectra]\index{two-dimensional!data} usually
displayed as \idx{grey-scale} or \idx{false-colour}\index{colour}
\idx{images}\footnote{Care is required regarding false colour.
Medical physics\index{medical physics} wisdom seems to be that
grey-scale is preferable to avoid a misleading picture.  Certainly,
arbitrary assignments of colours to contour levels should be treated
circumspectly.}.  It may be necessary to re-bin\index{re-binning} them
for display when more than one channel\slash pixel would otherwise be
displayed (c.f.\ one-dimensional histograms).  The maxmimum size of a
2-d spectrum that can be displayed needs to be specified in terms of a
sensible screen area and the screen resolution;
\item[\idx{markers}] on channels of one- or two-dimensional spectra.
These should indicate the channel, energy if appropriate, channel
contents and marker type (current, peak marker etc.);
\item[\idx{polylines}] (sets of arbitrary $(x,y)$ points joined by
straight line segments);
\item[\idx{spline}s] (as polylines, but joined with a spline instead of
straight lines and possibly multi-valued);
\item[\idx{polymarker}s] (points as for polylines but indicated with a
\kw{marker character} and not joined by lines; not to be confused with
channel markers\index{channel!markers}\index{markers!channel});
\item[\idx{window regions}]\index{region!window}\index{window!region}
as a set of \idx{markers} in the one-dimensional case and as a closed
\idx{polygon} for \index{two-dimensional!spectra}two-dimensional spectra;
\item[\idx{annotation}] in the form of \idx{axes}, dataset
names\index{name!dataset}\index{dataset!name} etc.\ to convey
information about what is displayed;
\item[\idx{fits}] Special types of one-dimensional \idx{spectra}
generated from the function fitted to a spectrum (\S\ref{fitting})
which are transient\index{transient object}.
\end{description}

\section{Box management}

Data boxes\index{data boxes!management} are not independent (even if
they are implemented as separate \idx{window}s) but rather, subject to
central control particularly regarding positioning when they are added
or deleted.  It should be possible to choose the \kw{policy} for such
positioning such that boxes either \kw[tiling of data boxes]{tile} a
fraction of the display or \kw[overlapped!items]{overlap} (with
the most recently selected ones nearest the top but with borders of
all visible for selection).  From the \kw{box manager}'s point of view
boxes differ only in their contents and position; they are initially
displayed all the same size, for instance, but may be subsequently
re-sized\index{data boxes!re-sizing} individually by the user.

The following operations are required on the box collection:
\begin{description}\index{data boxes!operations on collection}
\item[Add a box];
\item[Remove a selected box];
\item[Remove all boxes];
\item[Re-size all boxes];
\item[Move all boxes].
\end{description}

\section{Box operations}

\index{data boxes!local operations}
The following operations are required to be available \kw[]{local} to
individual boxes and, where stated, also \kw[data box!local
operations]{global} on all the boxes displayed.

\subsection{Tag channel}

\index{channel!tagging}\index{tagging channels}
A mouse hit on a channel moves the \kw[current!marker]{current marker}
to that channel.  The box and spectrum thus selected become
\kw[current!box]{current} and should be indicated as such, for
instance by a \idx{colour} change.  Criteria for \kw[hitting,
channel]{hitting} a particular channel with the \idx{mouse} need to be
experimented with: e.g., \index{tolerance on mouse hits} how close in
\idx{pixel}s to the defined channel position is acceptable and how is
a channel decided upon when more than one channel\slash pixel is
displayed?

\subsection{Region changing}

\index{region!changing}
Region changing should be available locally and globally, including:
\begin{description}
\item[\op{Panning}] left/right and up/down;
\item[\op{Zooming}] in/out in $x$ for one-dimensional boxes, in $x$ and $y$
for two-dimensional ones;
\item[\op{Expansion}] to a given $x$ or $y$ \idx{region};
\item[\op{Reset}] to the \kw{natural expansion} for the box.
This is defined to include the full range of all
overlapped\index{overlapped!datasets} rather than just the first one
added to the box as at present.
\end{description}
The amount by which \idx{panning} and \idx{zooming} changes the \idx{region}
(e.g., by a factor of two for zooming) should be resetable at the
user's discretion.  A \kw[ring of region specifications]{ring} of
\index{region!specifications}region specifications should be kept so
that limited re-tracing is possible back through a set of changes to
the \idx{displayed region}\index{region!displayed}.  Separate rings
should be maintained locally and globally.  It should also be possible
to store the \index{current!expansion}current expansion specification
separately from the ring and to retrieve it.  Thus we also have these
operations:
\begin{description}
\item[\op{Revert}] to \idx{previous expansion} on the ring;
\item[\op{Retain}] \index{current!expansion}current expansion;
\item[\op{Restore}] \idx{retained expansion} (not updating the ring).
\end{description}

\subsection{Changing count range}

Changing \index{count!range}count range works differently for one- and
\index{two-dimensional!data}two-dimensional data.  In the former case,
\idx{panning} and \idx{zooming} in $y$ affects the range of counts
displayed.  Two other convenient functions are required on the $y$
scale:
\begin{description}
\item[\op{Times 2}] {\em halves} the range displayed (so that the {\em data}
appear to be magnified by 2);
\item[\op{Divide by 2}] doubles the range.
\end{description}
The $z$ display\index{z display@$z$ display} in the
two-dimensional\index{two-dimensional!data} case is described in terms
of \kw[contour!levels]{contour levels} (even if the data are not
displayed in contour form).  Appropriate operations on the levels are:
\begin{description}
\item[\op{Specify contour levels}] Explicit values are given by the user
for the number of contour ranges\index{contour!ranges, number of}
supported---eight is suggested as a sensible limit.  The default for
the contours is equally-spaced between the maximum and minimum $z$ of
the dataset displayed;
\item[\op{Contour up}] Only applicable if the contours are
equally-spaced,\index{contour!equally-spaced} in which case the
spacing is subtracted from each level;
\item[\op{Contour down}] As for \kw{contour up}, but adding the spacing to
each level;
\item[\op{Times 2}] Halve the value of each level;
\item[\op{Divide by 2}] Double the value of each level;
\item[\op{Default contours}]\index{contour!default} Reset them to the
default values. 
\end{description}

\subsection{Transformation}

\index{transformation!linear or logarithmic}
The $x$ and $y$ (and $z$ where appropriate) scales of boxes may be
chosen locally or globally to be either linear\index{linear!scaling} or
logarithmic\index{logarithmic scaling}, subject to the logarithm of
the data being well-defined.

\subsection{Changing box contents}

\begin{description}
\item[\kw{Overlap dataset/window}] Either the existing and
\index{overlapped!items}overlapped items must be one-dimensional
(spectra or graphs) or the overlapped item may be a two-dimensional
\idx{window};
\item[\kw{Un-overlap dataset/window}]\index{window} The item to remove
from the overlapped collection is chosen;
\item[{\sl New data}]\index{new!data} A single selected dataset
replaces any displayed in the box.
\end{description}

\subsection{Others}

\begin{description}
\item[\kw{Markers}] should be able to be added to the display, removed from
it and moved;
\item[\kw{Information}] The \idx{parameters} of the \index{current
dataset}current dataset are displayed (e.g., its \\idx{range}s); 
\item[\kw{Remove fits}] All \idx{fits} and \idx{markers} associated
with fitting are cleared.
\end{description}

\section{Display dependencies and refresh}

It should be possible to define a \kw{dependency} for each data
box\index{data boxes} such that when a component of the dependency
changes the box display is updated accordingly.  Typical dependencies
might be of a slice\index{slices} upon the position of a window or of
a \kw{linear combination} of spectra upon the coefficients.  

A special case is of a live\index{spectra!live} \index{spectra!online}
(online) spectrum upon a \kw{timer} to implement an automatic
\kw{refresh mechanism}.\index{operation!refresh@{\sl refresh}}  This
mechanism should be available globally on the \idx{data boxes},
overridden locally with a specified period\index{period!refresh}
(which may be infinite).  It should be possible for data with another
dependency to be auto-refreshed.  The user should be able to trigger a
refresh independently of the timer.

%\include{analysis}

%-*-LaTeX-*-
\chapter{Data analysis and manipulation functions}\label{chap:analysis}

\index{operation!on data}
The following operations on data should be provided in addition to
those listed in \S\ref{ops},~\ref{more-ops}.

\section{One-dimensional spectra}
\index{spectra!one-dimensional}
\subsection{Creating new spectra}

\index{spectra!creating}\index{creating spectra}
These operations (which create new spectra rather than over-writing a
spectrum that is altered) must propagate the error
spectra\index{error!spectrum} appropriately and write 16- or 32-bit
results as appropriate.  Any \idx{precision} or mixture thereof is
acceptable on input.  New spectra have a name generated according to
the currently-selected \kw{policy} and a title\index{title!new} which
indicates the input spectra\slash spectrum and the operation
performed.
\begin{description}
\item[{\sl Linear combination}]\index{linear!combination} of an
arbitrary number of spectra as 
provided currently by {\tt ADDSEQUENCE}\index{addsequence@{\tt
ADDSEQUENCE}}; 
\item[\kw{Re-scaling}] A linear
transformation\index{linear!transformation} of either the $x$ or $y$
scale.  The former means \kw{re-binning} the channel contents
smoothly, the latter merely changing them.  Currently provided by {\tt
XSCALE}\index{xscale@{\tt XSCALE}}, {\tt YSCALE}\index{xscale@{\tt
XSCALE}};
\item[\kw{Editing}] Either:
\begin{description}
\item[\kw{Content changing}] A range of channels may be set to have all the
same value (occasionally useful e.g., where \idx{overflows} have occurred).
Currently provided by {\tt CHANGECHANNELS}\index{changechannels@{\tt
CHANGECHANNELS}}; 
\item[{\sl Range changing}]\index{range!changing} The channel
range\index{channel!range} may be truncated or expanded.  This is not
the same as $x$-scaling since channels out-of-range are ignored on
truncation and extra channels filled with zeroes on expansion.
\end{description}
\item[\kw{Smoothing}] using \idx{binomial weighting} as currently provided by
{\tt SMOOTH}; \index{smooth@{\tt SMOOTH}}
\item[{\sl Other operations}] \dots\ like \idx{unfolding},
\idx{non-linear re-scaling} (e.g., square root)?;
\end{description}

\subsection{Analysis}

\label{sect-analysis}
The functions below should optionally write results to the
\kw[journal!file]{journal file} (\S\ref{journal}) as well as
displaying them on the screen.

\subsubsection{Background and peak fitting} 

\label{fitting}\index{fitting}
The \kw{background} in a selected set of regions may be fitted by
various sorts of functions which are supposedly physically meaningful
in different situations.  Parameters\index{parameters!fit} of one or
more \kw{peak}(s) may then be determined in another region relative to
this background, either by fitting a function or by a simple
calculation like that used in \kw{integration}.  Peak and background
regions must all be disjoint.  The possible types of \idx{background fit}
function\index{fitting!function} are:
\begin{description}
\item[None] A degenerate case for use when there really isn't any
background or to allow the peak fit to do all the work;
\item[Flat];
\item[Sloping];
\item[Polynomial] of order 0, 1, 2 or 3;
\item[Exponential].
\end{description}
\kw[]{Polynomial} and \kw[]{exponential} fit the same function in all the
regions.  \kw[]{Flat} and \kw[]{sloping} fit an appropriate linear
function independently on each side of the peak region and extrapolate
it to the edges of the peak region.  They have two varieties:
\begin{description}
\item[Line] where the background function used in the peak region is
obtained by linear interpolation\index{linear!interpolation} of the
extrapolated values at the peak region boundaries;
\item[Smooth] where the interpolation is done smoothly in this region,
the value being determined by a running integral over the peak area
above the background starting from the lower limit of the peak region.
This is appropriate in cases where the background below a peak is
heavily influenced by the peak's intensity.
\end{description}

Peak fitting functions\index{fitting!function} may be either those
supplied by the system or defined by a
user-supplied\index{fitting!user-defined} routine that must be
linked\index{link editing}\index{editing!linkage} with the fitting
program.  User-supplied functions may be non-linear functions of their
parameters.  The system-supplied ones are of two types:
\begin{itemize}
\item a summation of Gau\ss ians\index{gaussian@Gau\ss ian} (one for
each peak supposed to be present) with optional \kw{skew} to account
for \idx{tails on peaks} due to detector imperfections.  The
parameters (centroid, width and skew) for each peak may fixed or
fitted and the peak area calculated.  The fit may be constrained to
have the same parameters or the parameters varied for each
independently.  If the centroid values are to be fitted initial
guesses\index{guesses for peak position} are either supplied by the
user or chosen rather arbitrarily by the program.  Width guesses are
supplied automatically;
\item an exponential folded with a Gau\ss ian\index{gaussian@Gau\ss
ian}\footnote{Fitting \idx{sums of exponentials} is a poorly-defined
problem \cite{nag}, so fitting an exponential with exponential
background should not be allowed.}.
\end{itemize}
Other commonly-used functions may be supplied according to demand
(e.g., \idx{optical lineshapes}?).

Fitting produces temporary \kw{fit objects} corresponding to the
fitted functions for the peak and background in the regions over which
they are defined.  These will be overlapped on the display to indicate
the quality of fit achieved.  They may be saved as permanent spectra
and subsequently used, for instance, to generate
\idx{background-subtracted spectra}.

Fitting is only possible if the spectrum concerned has associated
\kw{errors}, which determine the $\chi^2$\index{chi@$\chi^2$} and
error estimates\index{error!estimates}error estimates on the fitted
parameters.  The latter should not include contributions from the
background fit since they are independent.  Area estimates extracted
from the fits are supplied asis and (for spectra with an efficiency
calibration\index{efficiency!calibration}) also efficiency
corrected\index{efficiency!correction} using the efficiency
appropriate at the centroid.

Features described here are partly as provided by the current {\tt
BACKPEAK}\index{backpeak@{\tt BACKPEAK}} program, but this needs
re-writing.  The functionality of {\tt DECAYS}\index{decays@{\tt
DECAYS}} is incorporated into the system-supplied functions.

\subsubsection{Other}

\begin{description}
\item[Integration]\index{integration} A simple calculation of peak and
background areas, peak centroid and width between two channel limits
as currently provided by {\tt INTEGRATION}\index{integration@{\tt
INTEGRATION}};
\item[Automatic peak estimation]\index{peakfinding} The current {\tt
PEAKFIND}\index{peakfind@{\tt PEAKFIND}} program, or an equivalent,
should be available to provide estimates of peak centroids and areas,
particularly for use with \idx{labelled plots};
\item[Peak identification]\index{peak!identification} Facilities for
identifying peaks in reaction spectra with particular $\gamma$-ray or
charged-particle decays should be provided.  These will rely on
appropriate \idx{nuclear data bases}\index{data base!nuclear} like the
current {\tt GAMMADB}\index{gammadb@{\tt GAMMADB}};
\item[Peak-to-total calculation] for easy determination of the quality
of Compton suppression in $\gamma$-ray detectors as per {\tt
PEAKTOTOTAL}\index{peaktototal@{\tt PEAKTOTOTAL};}; 
\item[Escape peaks]\index{escape peaks} identification (peaks 511 or
1022 keV below another) as per the present {\tt
ESCAPES}\index{escapes@{\tt ESCAPES}};
\end{description}

\section{Two-dimensional spectra}
\begin{description}
\item[Slicing] should be possible by \kw{projecting} the data onto the
$x$ and/or $y$ axes in the region specified by a window.  A special
case where the window is the whole displayed region should be allowed;
\item[Integration] of data in a region specified by a window.  Details
need to be worked out (e.g., how to define a background, if at all);
\item[Re-scaling];
\item[Linear combination].\index{linear!combination}
\end{description}

\section{Graphs}

\begin{description}
\item[Fitting] with user-defined functions as for spectra (without
consideration of a background);
\item[Interpolation] It should be possible to interpolate a graph's
points, for instance to form a histogram from it;
\item[Combination] It should probably be possible to combine graphs in
linear combinations,\index{linear!combination} for instance.  This
will require definition of what happens when the $x$ values don't
coincide.
\end{description}

\section{Maps}

As for graphs.

\section{Windows}

Windows should be editable by moving the component markers in the
one-dimensional case and by moving the vertices with
\kw{rubber-banding} in the two-dimensional case.  Creating a window
from scratch is a special case.

%\include{interface}

%-*-LaTeX-*-
\chapter{User interface principles}

\index{principles!user interface|(}\index{user!interface!principles|(}
This chapter discusses some principles which the implementation of the
user interface should follow.  These are based on general interface
wisdom, experience with the current system and some attempted insight.
It is important to get the `feel'\index{feel@`feel'} of the system
right, since this is what makes it usable.  Unfortunately, this is
just the area that is hardest to get right!  More principles than
thought of here should emerge on detailed specification or
implementation.  It is debatable whether these issues are requirements
or belong in a design document, but they are included as they
(should!)\ have a big influence on how users perceive the system.
A useful user interface meta reference is~\cite{thimbleby}.

\section{Meta-principles}

\index{principles!meta}\label{user-range}
The aim is that the system will be able do what a sophisticated
user\index{user!sophisticated} would expect and in a way that is
comfortable for the na\"\i ve\index{user!naive@na\"{\i}ve}.  As
previously stated, we have to aim at a wide range of users with
different degrees of sophistication and experience.  However, we
should regard them as being technically competent\index{user!technical
competence of} and not feel it necessary to nurse-maid them to the
extent that might be necessary with commercial applications aimed at
general users\index{user!commercial}.  (That would be too
time-consuming anyway.)  The primary aim is {\em not\/}
`user-friendliness'\index{user-friendliness@`user-friendliness'} but
rather an interface that is powerful, flexible, consistent,
maintainable and, perhaps, hard to go wrong with.  Subject to that it
is, of course, intended that it should be as easy as possible to for
the intended users to learn and use.

Principles that are decided on (e.g., the ability always to be able to
do with a command language what you can do with \idx{direct
manipulation}) should be made explicit in the \idx{documentation} and
adhered to consistently.  Any exceptions\index{exception!to principle}
would need a good excuse and would need to be pointed out carefully
where they occur.  I suggest a \idx{touchstone} for whether things are
right is the complete operation of doing and displaying the results of
a peak\slash \index{background!fit}background fit with several fitting
regions and a few mistakes.\label{principles}

\section{Use of display facilities}

\subsection{Colour/shading}

The requirement to support \idx{monochrome}\index{display!monochrome}
displays restricts an implementation in its use of \idx{colour} and
\idx{shading}.  Choices should be made only from the set known to be
sensibly (distinguishably) rendered (by \idx{dithering}) on the
hardware targets.  Such rendering,\index{display!monochrome!problems}
however, is often going to fail (notably with one-pixel-thick lines),
so that distinctions by colour on the display should not be relied
upon.  Attention should be paid to common \idx{colour blindness}---we
have a test subject!  Since \idx{dithering} slows the display, it may
be useful to allow the user to turn off attempts to render it on
monochrome displays.\index{display!monochrome}\index{mode}

\subsection{Sound}

Platforms such as the \idx{SparcStation} would allow use to be made of
\kw{sound}---even in stereo\index{stereo sound}---for instance to
alert the user to \idx{exception}s.  It is possible to envisage
applications like `\idx{recorded messages}'\index{message!recorded}
giving warnings\index{warning} or \idx{explanation}, rather than
disrupting the screen interaction with visual \idx{message}s.  This
is, however, regarded as bad design in systems designed for
\index{public use}`public' use and should be avoided unless users are
willing to experiment with using \idx{headphones}.  Sound should be
restricted to beeps\index{beep} in the case of \idx{error} conditions
(e.g., to warn that the operation attempted has been ignored) and
perhaps sounds of greater insistence and persistence for serious
exceptions reported at a display running an experiment
(\S\ref{sect-errors}).

\section{Commands/Icons}

Commands and icons should be chosen carefully to avoid
\idx{confusion}---in particular, confusion with a \idx{destructive
operation}\index{operation!destructive}.  Thus {\sl delete\/}- or {\sl
clear\/}-type commands or buttons should be well \index{isolation of
commands}isolated syntactically or spatially from others.  (There are
counter-examples in the current system.)  The sensitivity to such
confusion has to be determined partly in the light of user
\idx{feedback}.  Icons\index{icon} should have an obvious significance
(by common consent of users---which probably rules out most
pictures!), otherwise a \idx{text}ual label\index{label!textual}
should be used.

\section{Interaction in general}
\index{interaction}
The principles discussed in some sections below are clearly
interrelated. 
\subsection{Pre-emption}

\kw{Pre-emption} of the user by the interface involves the user being
forced into a certain course of action at some time e.g., having to
answer a question in a \idx{dialogue box} but being unable to access the
tool to provide the information.  This tends to happen in the present
system due to its single-tasking nature.  It should obviously be
avoided.  Sensible use of \idx{multi-tasking} in the \idx{windowing
system} will help to avoid it.  Avoiding pre-emption is a reason for
having a multi-tasking \idx{windowing system}.

\subsection{Modes}\label{modes}

\kw{Modes} should be avoided as far as possible.  They tend to lead to
confusion, especially where there are subtle bugs in the interface
logic, as has sometimes become apparent in the present system.  In
some situations they will be helpful, however (see \S\ref{foreign}).
Modes can lead to \idx{pre-emption}.

\subsection{Hidden information (WYSIWYG)}

\index{hidden information}\index{information!hidden}
For na\"\i ve users\index{users!na\"\i ve}, at least, it is helpful
for the \idx{interface} to adopt \kw[WYSIWYG]{WYSIWYG}
(`what-you-see-is-what-you-get') tactics as far as practicable.  Thus,
for instance, appropriate operations should be visible as
\index{menu!pop-up}menus, \idx{button}s, etc.\ and pop-up menus are
discouraged, definitely if they aren't indicated by a change in the
\idx{cursor} appearance, and likewise with \idx{mode}s
(\S\ref{modes}).  This principle may be relaxed substantially for
expert users\index{user!expert} since WYSIWYG also equates to
`what-you-see-is-all-you-get' and may hinder effective use.  (This is
a somewhat unconventional interpretation of WYSIWYG\@.)

\subsection{Proper determination}

It is necessary to strike a balance between \idx{over-determination},
where the user is trapped into rigid dialogue (probably connected with
\idx{pre-emption}) and \idx{under-determination}, where the user
doesn't know what to do next.  Having \idx{mode}s for different levels
of experience helps here (\S\ref{foreign}).\index{users!range of}

\subsection{Direct manipulation and scripting}

To be more specific about the requirement (\S\ref{dm-and-scripts}) for
\idx{direct manipulation} and \idx{scripting}, we may adopt the
principle that any DM operation should have a direct equivalent in the
\idx{scripting language}.

\subsection{Least astonishment}

Design decisions should be guided by the principle of \kw{least
astonishment}, such that the interface's behaviour is intuitive
(\S\ref{intuitive}).  Where in doubt the behaviour should be
`canonical',\index{canonical behaviour} which probably means following
the old system or a commonly-used tool.

\section{Misleading information}\label{misleading-info}

The \idx{interface} should not display \idx{misleading
information}\index{information!misleading}, encouraging the user to
invoke an operation\index{operation!inappropriate} or select
data\index{data!inappropriate for selection} that would be
inappropriate.  Thus, for instance, if a 2-dimensional spectrum is
displayed, the menu item for the \op{overlap} operation should not be
selectable; if a 1-dimensional spectrum is displayed, \op{overlap}
should present the user with a selection of items to overlap, all of
which are appropriate (not 2-dimensional, for instance).  The idea is
to avoid as much as possible the situation in the present system of
selecting something and being told it was wrong subsequently.

\section{Speed}

\index{speed}
An estimate is needed of speeds acceptable to users for representative
operations to guide the implementation (if the requirements can
actually be satisfied!).

%
\index{principles!user interface|)}\index{user!interface!principles|)}

%\include{presentation}

%-*-LaTeX-*-
\chapter{Presentation graphics and hardcopy}\label{chap:pubgraph}

\section{Graphics editor}\index{graphics!editor}\index{editing!graphical}
\label{presentation}

An \kw[]{object-oriented graphical editor} is required for composition
of \kw{presentation graphics}.  This should provide the canonical
operations of such tools (modelled on \idx{MacWrite}) and others as
necessary to tailor it to the types of graphical object used in
\nigs{} (e.g., \idx{spectra}, \idx{axes}).  It should be possible to
\kw{cut and paste} objects from the normal \idx{visualisation} display
into the editor and manipulate them directly to compose the required
picture.  This might typically be a collection of labelled spectra,
perhaps with fits and a graph derived from them.  Modes should be
available for specialised functions like drawing \kw{decay schemes}
along the lines of the {\tt LEVELS}\index{levels@{\tt LEVELS}} program
in the current system.  As well as composing pictures interactively,
it should be possible to write commands in a
language\index{graphics!editor!command language} designed to achieve
the same result so that pictures may be generated automatically and
subsequently edited interactively.

Such a facility does not currently exist.  Note that a command-driven
system like that provided by \acr{paw}\index{PAW@\acr{paw}} \cite{paw}
is not proposed, but rather one like {\tt fig}\index{fig@{\tt fig}}
\cite{fig} with a \idx{direct manipulation} interface and a high level
intermediate graphics representation.  Some examples of the sort of
operations required are provided by the facilities of the current {\tt
PSSKETCH}\index{PSSKETCH@{\tt PSSKETCH}} and {\tt
gnuplot}\index{gnuplot@{\tt gnuplot}} program \cite{gnuplot}.
Pictures should be composable by direct manipulation and by {\tt
PSSKETCH}-type commands.  This functionality and the requirement to
cope with objects like \idx{spectra} precludes using a
commonly-available tool (like {\tt fig}) to do the job, but it may be
sensible to extend existing facilities rather than producing another
from scratch.  One possibility would be to merge something {\tt
fig}-like with something {\tt gnuplot}-like and cope with arbitrary
data objects by providing a mechanism to pipe any data file into the
program through an arbitrary filter.

\section{Hardcopy}

Hardcopy\index{hardcopy} is required both of the \idx{presentation
graphics} and \idx{plots} of data in a different form for
\idx{visualisation} purposes.  The latter will typically need to be
high resolution plots of spectra with \idx{axes} labelled by channel and
energy (at a size and frequency that would not be appropriate for
\idx{presentation graphics}) and with peaks automatically labelled (all as
currently provided by the {\tt SPECTRA}\index{SPECTRA@{\tt SPECTRA}}
program).  Complete dumps\index{display!dump} of the display are
required and dumps of part of it (e.g., only that relevant to
data-taking and analysis) should be available.  As stated in
\S\ref{postscript} all such graphical output should ultimately be
available in \acr{PostScript}\index{PostScript@\acr{PostScript}} form.

%\include{misc}

%-*-LaTeX-*-
\chapter{Miscellaneous functions}

\section{Dataset selection}

\index{dataset!selection}
Some care needs to be devoted to the part of the interface that
selects datasets from the data base for display or other operations.
Subject to the uniform structure based on the filing system which has
been advocated earlier, this is essentially a file-selection facility.
The files available for selection for use with an operation should
only be those appropriate to the operation.

A \idx{mode} of the file selector\index{file!selector} might, however,
be provided to give information (like their titles and sizes) on all
files in a directory as currently available.  Manipulation functions
(copying, re-naming etc.)\ as described in \S\ref{ops} should be
available from the file selector.  These information and manipulation
functions should be available at any time, particularly between the
file selector being displayed and a dataset being selected.  It should
be possible to move quickly between a number of
\idx{previously-visited} points in the directory
\idx{hierarchy}.


\section{Journalling/logging}
\label{journal}
The facility should be provided to record two different types of
\idx{transcript} information from the session in the form of a
\begin{description}
\item[\kw{Journal}] intended to record the results of \idx{analysis}
operations (\S\ref{sect-analysis});
\item[\kw{Logbook}] intended to record information during an
experiment, including:
\begin{itemize}
\item error messages\index{error!messages};
\item notes (general explanations\slash excuses etc.\ that you might write
in a \idx{run book});
\item saves and deletions of \index{online!spectra}online spectra;
\item tape mounts and file opens;
\item stops and starts.
\end{itemize}
Logbook entries should be time-stamped\index{time-stamping, logbook
entries}.
\end{description}
Separate \idx{streams} should be available to record both types of
information and any application should be able to copy its output to
either.  (It is expected that all such output will be a {\em copy\/}
of information displayed on the screen, or at least a paraphrase of
it.)

\section{Exception/warning reporting}

\label{sect-errors}\index{exception|(}
\kw[exception]{Exceptions} (errors) and warnings may arise either
within \nigs{} itself or be reported to it by another system to which
it provides the interface (typically to do with experiments).

\subsection{Internal}

Exceptions arising from operations within \nigs{} should not be logged
unless they indicate system malfunction (see \S\ref{sect-bugs}).  If
\idx{mode}s are available for different levels of expertise they
should be able to report exceptions differently.  An expert mode will
give a brief indication of the error---perhaps just a beep---without
holding up further work, whereas a novice mode is likely to put up a
dialogue box giving an explanation of the exception and requiring
action to proceed.  Although the way reporting is done may be
different depending on whether it arose from direct manipulation or a
\idx{script}, it should be done consistently in each case.

\subsection{External}\label{external-exceptions}

\kw[]{External} exception events arise asynchronously.  \nigs{} must
`listen' for them and take appropriate action when one occurs.  They
are expected to be generated by an external
\kw[exception!server]{exception server} (it's not supposed actually to
generate exceptions itself!).  The user must be alerted to them,
depending on their degree of urgency (which information the server
should provide).  Various schemes for doing this are possible and
probably different ones are appropriate for different severities.  For
severe errors probably a window should pop up (away from the area the
user was just about to hit with the mouse!)\ and there should also be
a suitably insistent audible indication (more than just a beep) if the
workstation can generate it (Sparcs\index{SparcStation} can).  The
user does not then actually have to be looking at the display or awake
to be alerted.  Error reports should be entered in the logbook journal
file\index{journal!file}.  Where there are multiple outstanding
messages, these should be scrolled so that the user can view them all,
up to an appropriate buffer limit.  Having looked at them, the user
should be able to clear this scroll area/buffer for when more arrive.
Some mechanism has to be provided to avoid being swamped by huge
numbers of messages if something is badly broken, but probably this is
the server's job.

It will probably be helpful to have some semi-\idx{expert system} to
help with diagnosis of fault conditions from the exception report(s).
Again this is probably the server's ultimate responsibility, but
\nigs{} will need to provide a suitable interface to
it.\index{interface!exception} 

External exception reports should be made clearly distinguishable from
internal ones.
\index{exception|)}

\section{Bug reporting}

\label{sect-bugs}
\index{feedback}
A built-in facility to report \kw[bugs, reporting]{bugs} should be
provided as done currently with the {\tt HARDWARE}\index{HARDWARE@{\tt
HARDWARE}} and {\tt SOFTWARE}\index{SOFTWARE@{\tt SOFTWARE}} report
facilities.  This should be done by automatic \idx{e-mail} to the
maintainers.  In some cases it may be possible for the system to
detect fault conditions internally and attempt to dump\index{dump!of
error context} the relevant context and forward it to the
\idx{maintainers}.  In any case, the bug-reporting facility should be
integrated where possible with error reporting\index{error!reporting}
(\S\ref{sect-errors}) at least to the extent that the user making the
report doesn't have to copy down details of the last error message
but, rather, can retrieve it from some buffer.  Version
numbers\index{version numbers} of programs should be readily available
(preferably generated automatically from the last error report).

Note that `bug' ought to include commonly perceived \idx{mis-features}
which---like the placement of objects on the screen, for instance,
slow\index{speed} down users or make them error-prone.

\section{Instrumentation}

It will be helpful if \kw{instrumentation} can be included in the
system so that information on its use can be extracted automatically
to provide objective guidance in making \idx{improvements}.  Such
information might include the frequency of use of commands, most
common settings of options and logs of particular
\index{error!messages}error messages.

%\include{documentation}

%-*-LaTeX-*-
\chapter{Documentation and help facilities}

\section{Overview}

The information about and inside \nigs{} must cater for the range of
users it is expected to have (\S\ref{user-range}), in other words it
should be usable at a variety of levels with differing degrees of
difficulty as far as possible.  The complete \idx{tyro} needs to be
able to get going quickly and find the way around as necessary;
experts need to be able to remind themselves about more esoteric
aspects equally quickly and easily.  Obviously catering satisfactorily
for the complete range of users\index{user!range of} is a difficult
problem, but one which needs to be attempted.

As far as possible, the system is expected to be
\kw{self-documenting}\index{documentation} so that either the way it
works is obvious or it is simple to get it to tell you the way it
works.  The present system attempts this with certain elegant
features, but these have not been well-maintained latterly.  It is
necessary also to have offline
documentation\index{documentation!offline} so that one can learn about
the system without sitting at it if necessary.

A good example of the general facilities one should try to provide is
given by \emacs{} `the advanced, self-documenting \dots\ editor'
\cite{emacs}.  Another example is provided by \idx{The
Publisher} \cite{publisher}.

It is important to maintain \kw[verity of
information]{verity}\index{information!verity} in the information
facilities---they should be updated and easily updatable whenever
changes are made.  As far as possible this should be automated and
facilities to allow it built into the system.

\section{Online documentation}

The online documentation\index{documentation!online} facilities needed
are of two types, although it is preferable to derive them from the
same source: an \kw[]{online reference manual} and
\kw{context-sensitive help}\index{help}.  Online documentation should
be such that there is no need to consult the printed manual when at
the terminal.  

\subsection{Manual}

The \idx{manual} gives a general view of facilities and should allow
one to find the appropriate strategy for doing something without
having to work one's way down a tree\index{tree!menu} of \idx{menu}s
etc.\ to find something that looks as though it might do the job.  The
manual is expected to make use of \kw{hypertext} facilities (to make
following \index{cross-references in manual}cross-references easy) and
appropriate \index{pictorial material in manual}pictorial material,
display of which the hardware will be able to support.  This can
probably be done using \TeX{}\index{TeX@\TeX} as the formatter with
suitable mark-up and a hacked previewer\index{previewer, \TeX}.

\subsection{Context-sensitive help}

\index{context-sensitive help}\index{help}
It should always be possible to get help on the various ways of doing
things in a given context even if \idx{menu}s, \idx{icon}s etc.\ are
supposedly intuitive\footnote{It should be remembered that supposedly
`friendly' systems like the \idx{Macintosh} can be quite baffling even
to sophisticates when they encounter them for the first time and
aren't tuned in to the twisted mind of the icon designer!}.  Thus
explanation of selectable items and an indication and explanation of
allowable alternatives where typed commands are required should be
available.  This might consist of a link into the hyper manual.
Graphics should be available in this situation to allow the best
explanation of the interface.  Any exceptions\index{exception!to
principle} to established principles (\S\ref{principles}) must be
obvious in context.

\section{Offline documentation}

The \idx{offline documentation}\index{documentation!offline} is
expected to be derived (printed) from the same source as the online
one in the same way as the \idx{GNU} \kw{texinfo} system so that the only
significant difference between them is the \idx{hypertext} facilities and
possibility of \idx{colour}, motion etc.\ in the online version.  The
offline version is required so that people may learn about the system
without sitting in front of it.

\section{Tutorial system}

A \idx{tutorial system} is helpful to new users and should be provided,
although at lower priority.  It should guide new users through the
facilities they are most likely to use (sufficient to be able to cope
with a night shift!).  The tutorial might usefully be extended to
cover things other than the graphics system itself, principally the
mechanisms for controlling experiments.

\appendix
%\include{platform}

%-*-LaTeX-*-
\chapter{Constraints}

\label{app-constraints}

\section{Hardware and software platform}

This section covers some of the \kw{non-functional
requirement}s\footnote{`Non-functional' requirements define
constraints under which the system should operate \cite{sommerville}.}
of the new system dictated by the current state of technology and
finance and enshrined in recent \index{policy!statements}policy
statements \cite{ecgo/8-25,grants91-3}.

\subsection{Hardware}

\index{hardware|(}
The only realistic cost-effective \idx{hardware} platform at present
is in the form of \kw[graphics!workstations]{graphics
workstations}\index{workstation} as provided, for instance, by
\idx{Sun Microsystems}.  (There are competing systems
from \idx{DEC}, \idx{Hewlett Packard} etc.)  These provide both the
\idx{cpu power} and the graphical display capabilities needed.  They
are expected to operate in a distributed
environment\index{distributed!environment}, sharing resources such as
mass storage over a \kw{local area network}.  Alternative approaches
based on central systems driving \idx{X/NeWS
terminals}\index{windowing system}, for instance,
do not seem realistic or cost-effective at present.

\label{cpu-spec}
We take the Sun \idx{SLC1}\index{SparcStation} as defining the minimum
sort of hardware facilities available for systems on which \nigs{}
should run.  This means:
\begin{itemize}
\item $\sim$10\,MIPS, $\sim$1\,MFLOPS \idx{cpu power};
\item `sufficient' real \idx{memory} ($\ge$12Mb) to support a
\idx{windowing system}, application software\index{application code}
and significant amounts of data related to the
\idx{display!characteristics};
\item a \idx{monochrome} screen of resolution\index{resolution!of
screen} $\sim$1000$\times$1000 \idx{pixel}s (although \idx{colour}
displays are expected to be the norm);
\end{itemize}
A graphics
accelerator\index{graphics!accelerator}\index{accelerator!graphics} is
not assumed.  The performance of the LAN\index{LAN|see{local area
network}} and file server\index{file server} is assumed sufficiently
good that swift \idx{file} access is not a problem.

\label{postscript}
\kw[hardcopy]{Hardcopy devices} for use with the system are expected
to support \acr{PostScript}\index{PostScript@\acr{PostScript}}
primarily.  There should be a means of
translating\index{translation!to \acr{PostScript}} any output meant
for hardcopy to \acr{PostScript} if it is generated in another form.
The next release of \idx{GNU} {\tt ghostscript}\index{ghostscript@{\tt
ghostscript}} is expected to be good enough to drive devices that
don't support \acr{PostScript} directly (e.g., the HP\index{Hewlett
Packard} \idx{PaintJet} colour plotter) should the need arise.
\index{hardware|)}

\subsection{Software}

\subsubsection{Operating system}

The only reasonable type of \idx{operating system} to consider is
\kw[Unix]{Unix} (or `Unix-like' e.g., \idx{Mach}) even if one could run
something else on the \idx{hardware} provided.  There are many
varieties of Unixes and where it is important to distinguish between
them one should insist on \idx{Posix}-compatibility\footnote{Posix is
a standards effort in this area.  [Is \idx{SunOs} Posix-compliant?]}
\cite{posix}.  This will be capable of distributed operation, at least
to the extent of a distributed filestore\index{filing system!distributed}
based on \idx{NFS}\@.

\subsubsection{Languages}

\index{language!for application software}
Application software\index{application code} should be written in
standard \idx{C} and/or \idx{Fortran} or some other language for which
freely-available, portable implementations are available, like {\tt
awk}\index{awk@{\tt awk}}, \idx{Scheme} or \idx{shell} scripts, for
instance.  The standard for \idx{C} should be the
\acr{ansi}\index{ANSI standard@\acr{ansi}
standard!C}\index{C!standard} one \cite{ansiC} where this conflicts
with the de facto `\idx{Kernighan and Ritchie} standard'.  (The
\acr{ansi} standard is supported by the freely-available \idx{GNU}
\index{gcc@{\tt gcc}}{\tt gcc}.)  The standard for Fortran should be
Fortran77\index{Fortran!Fortran77}\index{ANSI standard@\acr{ansi}
standard!Fortran}
\cite{ansiF77} since solid Fortran90\index{Fortran!Fortran90}
compilers are unlikely to be quickly available.  We assume that
appropriate libraries\index{library!licensing} can be licensed where
appropriate (for instance \acr{NAG}\index{NAG} for numerical analysis
\cite{nag}).

\subsubsection{Windowing system}

The \idx{graphics} system is expected to be built on top of a multi-tasking,
\kw{WIMP}-orientated \idx{windowing system}.  The choice is probably between
X windows\index{X windows|see{X11}} and \idx{NeWS} \cite{x/news} but
the choice between them is an implementation decision.  (A requirement
like the ability to cut objects and paste\index{cut and paste} them to
the presentation graphics editor\index{graphics!editor}
(\S\ref{presentation}) would, however, appear easier to implement in
\idx{NeWS}\index{windowing system!NeWS}, as would general
communication between independent applications running in their own
windows.)

\section{Distribution}

The system will operate in a \kw[distributed!environment]{distributed
environment}.  For
\idx{analysis}\slash \idx{visualisation} purposes it is expected that
usually only the data will be non-local, not application
programs---the \idx{workstation}s upon which the system runs are
expected to provide the necessary computational ability\index{cpu
power} (\S\ref{cpu-spec})---but the ability to run \idx{application
program}s on a system remote to the graphical
interface\index{graphical!interface} should be provided.  For
apparatus
\idx{control} etc.\ it will be necessary to communicate with remote
processes.  Ideally it should be possible to distribute components
across the \kw{wide area network}.  This is expected to be
particularly useful for remote experts to diagnose and fix problems
with the local system (especially \idx{apparatus}).

%\bibliography{req}
%\bibliographystyle{unsrt}

\begin{thebibliography}{10}

\bibitem{sommerville}
Ian Sommerville.
\newblock {\em Software {E}ngineering}.
\newblock International {C}omputer {S}cience {S}eries. Addison Wesley,
  Wokingham, England, third edition, 1989.

\bibitem{ince}
Darrell~C. Ince.
\newblock {\em An {I}ntroduction to {D}iscrete {M}athematics and {F}ormal
  {S}ystem {S}pecification}.
\newblock Oxford University Press, Oxford, UK, 1988.

\bibitem{paw}
R.~Brun et~al.
\newblock {\em PAW: Physics Analysis Workstation}, 1989.
\newblock CERN program library entry Q121.

\bibitem{ecgo/8-25}
E.~Owen.
\newblock Data {A}cquisition and {E}lectronics {E}stimates and {F}orward {L}ook
  (91--96).
\newblock Data acquisition working party document, 1990.
\newblock ECGO/8--25.

\bibitem{wooff}
C.~D. Wooff.
\newblock {\em Nucl. Instrum. Meth.}, 214:419, 1983.

\bibitem{nag}
NAG Ltd.
\newblock Nag numerical analysis library.

\bibitem{sort-lang}
Liverpool software systems group.
\newblock {\em \EG{} Project: Sorting Language}.

\bibitem{sdb-er}
NSF {S}oftware {S}ystems {G}roup.
\newblock {\em {NSF} {D}ata {H}andling {S}ystem: {S}pectrum {D}atabase}.
\newblock Edition 2.3.

\bibitem{ansi-tape}
Ansi tape labelling.

\bibitem{tar}
Jay Fenlason.
\newblock {\em {{\tt tar}: The GNU tape archive}}.
\newblock Free Software Foundation, Inc., 1990.

\bibitem{sdb}
Introducing the {SDB} spectrum access system.
\newblock NSF {S}oftware {S}ystems {G}roup.
\newblock Edition 1.2.

\bibitem{thimbleby}
Harold Thimbleby.
\newblock {\em User Interface Design}.
\newblock ACM Press Frontier Series. Addison Wesley, Wokingham, England, 1990.
\newblock ISBN 0--201--41618--2.

\bibitem{fig}
Micah Beck and A.~Siegel.
\newblock Transfig: Portable graphics for {\TeX}.
\newblock {\em {\sc TUGboat}}, 11(3):373, 1990.

\bibitem{gnuplot}
Thomas Williams et~al.
\newblock {\em {GNUPLOT}: An Interactive Plotting Program}.
\newblock {T}he {F}ree {S}oftware {F}oundation, Cambridge, Mass., USA.
\newblock Version 2.0. Available from GNU depositories (see \cite{emacs}).

\bibitem{emacs}
Richard Stallman.
\newblock {\em {GNU} {E}macs Manual}.
\newblock Cambridge, Mass., USA, fifth ({E}macs version 18) edition, 1986.
\newblock User guide to the Emacs editor, an example of a large, customisable
  system worked on by people all over the world using various good interface
  techniques. See also the manual for its programming language. Part of the
  Emacs distribution from GNU depositories like {\tt prep.ai.mit.edu}.

\bibitem{publisher}
{\sc ArborText inc}.
\newblock {T}he {P}ublisher, version 3.0.3.
\newblock Available on Daresbury Suns.

\bibitem{grants91-3}
V.~Pucknell.
\newblock University grants 1991/1993.
\newblock Data acquisition working party document, September 1990.

\bibitem{posix}
Posix reference.

\bibitem{ansiC}
Brian~W. Kernighan and Denis~M. Ritchie.
\newblock {\em The {C} Programming Language}.
\newblock Prentice Hall, second edition, 1988.
\newblock ISBN 0--13--110362--8.

\bibitem{ansiF77}
American National Standards Institute.
\newblock {\em American National Standard: programming language {FORTRAN}},
  1978.
\newblock {ANSI X3.9--1978} {ISO 1539--1980(E)}.

\bibitem{x/news}
{\em X11/{NeWS} {V}ersion 2 {S}erver {G}uide}.
\newblock Part Number: 800--4898--10. See also references therein.

\end{thebibliography}

%\printindex

\begin{theindex}

  \item accelerator
    \subitem control system, 7, 8
    \subitem graphics, 30
  \item {\tt ADDSEQUENCE}, 19
  \item analogue
    \subitem devices, 7
    \subitem parameters, 8
  \item analysis, 10, 26, 31
  \item animation, 6
  \item annotation, 16, 17
  \item \acr{ansi} standard
    \subitem C, 30
    \subitem Fortran, 31
    \subitem tape labels, 15
  \item apparatus, 8, 31
  \item application code, 7, 30
    \subitem importing, 7, 8
  \item application libraries, 9
  \item application program, 9, 11, 13, 14, 31
  \item {\tt arc}, 15
  \item argument decoding, 9
  \item array of channel contents, 13
  \item \acr{ascii}, 15
  \item atomic operations, 13
  \item automation, 8
  \item {\tt awk}, 30
  \item axes, 16, 17, 25

  \indexspace

  \item background, 19
    \subitem fit, 22
  \item background fit, 19
  \item background-subtracted spectra, 20
  \item {\tt BACKPEAK}, 20
  \item barcharts, 8
  \item beep, 23
  \item binomial weighting, 19
  \item bins, 10
  \item block
    \subitem {\sl read channel}, 13
  \item block length, 15
  \item box manager, 17
  \item boxes, data, 16
  \item bugs, reporting, 27
  \item button, 23
  \item button box, 7

  \indexspace

  \item C, 9, 30
    \subitem standard, 30
  \item calibration, 10, 13, 16
    \subitem efficiency, 11, 14
    \subitem energy, 10, 11, 14
    \subitem function, 11
    \subitem units, 10
  \item canonical behaviour, 23
  \item {\tt CHANGECHANNELS}, 19
  \item channel, 10
    \subitem contents, 14
    \subitem markers, 17
    \subitem range, 19
    \subitem tagging, 17
  \item {\tt CHANNEL} statements, 15
  \item character set, 12, 15
  \item $\chi^2$, 20
  \item colour, 16, 17, 22, 29, 30
  \item colour blindness, 6, 22
  \item command line, 9
  \item command-driven, 7
  \item commands
    \subitem sorting, 8
    \subitem typing, 7
  \item comments, 10--12
    \subitem multiple, 13
    \subitem size of, 10
  \item compatibility
    \subitem with SDB, 15
  \item compilation, 7
  \item confirmation, 13
  \item confusion, 23
  \item constraints, 5
  \item content changing, 19
  \item context-sensitive help, 28
  \item contour, 6
    \subitem default, 18
    \subitem equally-spaced, 18
    \subitem levels, 18
    \subitem ranges, number of, 18
  \item {\psl contour down}, 18
  \item contour up, 18
  \item {\psl contour up}, 18
  \item control, 6, 8, 31
    \subitem accelerator, 7, 8
    \subitem apparatus, 7
    \subitem experiment, 7
    \subitem interface components, 9
  \item control panel, 16
  \item conversion factors, 11
  \item {\psl copy calibration}, 14
  \item {\psl copy efficiency calibration}, 14
  \item copying, data base items, 13
  \item count, 10
    \subitem maximum and minimum, 13
    \subitem negative, 11
    \subitem range, 18
  \item counting errors, 11
  \item cpu power, 30, 31
  \item creating spectra, 10, 19
  \item creation of data base items, 13
  \item cross-references in manual, 28
  \item current
    \subitem box, 17
    \subitem dataset, 16
    \subitem expansion, 17
    \subitem marker, 17
  \item current dataset, 18
  \item cursor, 23
  \item customers, 4
  \item customisation, 8
  \item cut and paste, 8, 25, 31
  \item cuts, 10

  \indexspace

  \item dashed histogram, 16
  \item data
    \subitem acquisition, 6, 10
    \subitem analysis, 6
    \subitem filtering, sort, 12
    \subitem grouping, 12
    \subitem inappropriate for selection, 24
    \subitem integrity, 14
    \subitem items
      \subsubitem type indication, 12
    \subitem items, operations on, 13
    \subitem manipulation, 6
    \subitem non-spectral, 11
    \subitem points, graph, 11
    \subitem re-scaling, 13
    \subitem structure, part of, 13
    \subitem transporting, 14
  \item data acquisition, 8
    \subitem system, 10
  \item data base, 7, 10--15
    \subitem component names, 12
    \subitem data types, 10
    \subitem hierarchical structure, 12
    \subitem hierarchy, 12
    \subitem hierarchy component, 12
    \subitem implementation, 12
    \subitem interface, 8, 12
    \subitem items
      \subsubitem sets of, 13
    \subitem nuclear, 20
    \subitem operations, 9
      \subsubitem copying, 13
      \subsubitem creation, 13
      \subsubitem deletion, 13
      \subsubitem interrogation, 13
    \subitem required to use filing system, 12
    \subitem users' view, 12
  \item data box
    \subitem local operations, 17
  \item data boxes, 16, 18
    \subitem local operations, 17
    \subitem management, 17
    \subitem operations on collection, 17
    \subitem re-sizing, 17
  \item data structures, 13
    \subitem internal, 14
  \item data types, 10
  \item dataset
    \subitem name, 17
    \subitem selection, 26
  \item DEC, 30
  \item decay schemes, 25
  \item {\tt DECAYS}, 20
  \item {\psl default contours}, 18
  \item {\psl delete comment}, 13
  \item deletion
    \subitem of data base items, 13
  \item dependency, 18
  \item destructive operation, 13, 23
  \item detector efficiency, 11
  \item dialogue box, 23
  \item dials, 7--8
  \item dictionary, 8
    \subitem NeWS, 8
  \item dimension order of spectra, 14
  \item dimensionality, 13
    \subitem higher than two, 10
    \subitem of displayed data, 6
  \item direct manipulation, 4, 7, 8, 22, 23, 25
  \item directory
    \subitem flat, for live spectra, 12
    \subitem structure, 12
    \subitem tree, 15
  \item disc storage, 10
  \item display
    \subitem characteristics, 30
    \subitem dump, 25
    \subitem monochrome, 22
      \subsubitem problems, 22
    \subitem parameters from acquisition\slash sorting, 8
    \subitem range of spectra, 10
    \subitem style, 16
  \item displayed region, 17
  \item distributed
    \subitem environment, 30, 31
    \subitem filing system, 14
  \item dithering, 22
  \item {\psl divide by 2}, 18
  \item documentation, 22, 28
    \subitem of IR, 15
    \subitem offline, 28, 29
    \subitem online, 28
  \item dump
    \subitem of error context, 27

  \indexspace

  \item e-mail, 27
  \item editing, 19
    \subitem graphical, 8, 25
    \subitem linkage, 20
    \subitem window, 9
  \item efficiency
    \subitem calibration, 14, 20
    \subitem correction, 20
  \item efficiency calibration, 11
  \item {\psc emacs}, 8, 14, 28
  \item empty items, 13
  \item energy calibration, 10
  \item ER, 14--15
  \item error, 23
    \subitem estimates, 11, 20
    \subitem messages, 26, 27
    \subitem reporting, 27
    \subitem spectrum, 11, 19
    \subitem standard, 11
    \subitem type of, 14
  \item errors, 14, 20
    \subitem graph, 11
    \subitem map, 11
  \item escape peaks, 20
  \item {\tt ESCAPES}, 20
  \item {\psc EuroGam}, 4, 32
  \item evaluating system, 7
  \item {\tt EVENT}, 7
  \item exception, 22, 26--27
    \subitem server, 27
    \subitem to principle, 22, 29
  \item excursions in $y$, 16
  \item {\psl expansion}, 17
  \item experiment, 7, 12
  \item expert system, 27
  \item expert users, 8
  \item explanation, 22
  \item extensibility, 6--8
  \item external representation, \see{ER}{14}

  \indexspace

  \item facilities
    \subitem shell, 7
    \subitem time-saving, 7
  \item false-colour, 16
  \item feedback, 23, 27
  \item `feel', 22
  \item {\tt fig}, 25
  \item file, 10, 12, 30
    \subitem changed, 14
    \subitem extension, 12
    \subitem modification time, 14
    \subitem names, 12
    \subitem selector, 26
  \item file server, 30
  \item filing system, 12--15
    \subitem distributed, 14, 30
  \item filtering data, 12
  \item fit objects, 20
  \item fits, 16--18
  \item fitting, 11, 19
    \subitem function, 19, 20
    \subitem user-defined, 20
  \item fixed length records, 15
  \item flat file stores, 15
  \item foreign languages, 6, 8
  \item format
    \subitem free, 15
    \subitem tape, 15
  \item Fortran, 9, 14, 30
    \subitem Fortran77, 15, 31
    \subitem Fortran90, 31
  \item free-format, 15
  \item function
    \subitem \nigs{}, 4

  \indexspace

  \item {\tt GAMMADB}, 20
  \item gates, 12, 14
  \item Gau\ss ian, 20
  \item {\tt gcc}, 31
  \item GEC, 5, 7
  \item \acr{Gem}, 8
  \item general-purpose computing, 6, 7
  \item {\tt ghostscript}, 30
  \item global operations, 16
  \item glue, for system components, 7
  \item GNU, 15, 29--31
  \item {\tt gnuplot}, 25
  \item graphical
    \subitem devices, 8
    \subitem editing, 8
    \subitem extensibility, 8
    \subitem interface, 6--8, 31
  \item graphics, 31
    \subitem accelerator, 30
    \subitem editor, 25, 31
      \subsubitem command language, 25
    \subitem functions, 9
    \subitem metafile, 4
    \subitem system, 12
    \subitem workstations, 5, 30
  \item graphs, 12--14
    \subitem (data type), 11
    \subitem better term for, 11
  \item grey-scale, 16
  \item grouping of data, 12
  \item guesses for peak position, 20

  \indexspace

  \item hardcopy, 25, 30
  \item {\tt HARDWARE}, 27
  \item hardware, 30
    \subitem base, changing, 5
    \subitem evolution, 5
  \item headphones, 23
  \item help, 28
  \item hidden information, 23
  \item hierarchy, 12--13, 15, 26
  \item histogram, 16
    \subitem readout, 10
  \item hitting, channel, 17
  \item HyperCard, 8
  \item hypertext, 28, 29

  \indexspace

  \item icon, 23, 28
  \item images, 6, 16
  \item implementation restrictions, 4
  \item importing, \see{application code}{7}
  \item improvements, 27
  \item information, 18
    \subitem hidden, 23
    \subitem misleading, 24
    \subitem verity, 28
  \item input devices, 7
  \item instrumentation, 27
  \item integrated facilities, 6
  \item integration, 19, 20
  \item {\tt INTEGRATION}, 20
  \item integrity of data, 14
  \item intensity, peak, 11
  \item interaction, 23
    \subitem means of, 7
  \item interactive facilities, 6
  \item interface, 9, 23, 24
    \subitem data base, 8, 12
    \subitem exception, 27
    \subitem system, 7
  \item internal
    \subitem data structures, 14
    \subitem representation, 14, 15
      \subsubitem documentation of, 15
  \item internal representation, 14, 15
  \item interpretative framework, 4
  \item interpreted language, 7
  \item interrogation of data base items, 13
  \item intuitive facilities, 6
  \item IR, \see{internal representation}{14}
  \item isolation of commands, 23

  \indexspace

  \item JCL, 4
  \item journal, 26
    \subitem file, 19, 27

  \indexspace

  \item Kernighan and Ritchie, 30
  \item keypads, 7
  \item knob, 7, 8

  \indexspace

  \item label
    \subitem textual, 23
  \item labelled plots, 20
  \item LAN, \see{local area network}{30}
  \item language
    \subitem consistency of, 4
    \subitem for application software, 30
    \subitem foreign, 6, 8
    \subitem scripting, 8
    \subitem shell, 7
    \subitem sort, 15
  \item large datasets, 8, 15
  \item last selected dataset, 16
  \item learning, 8
  \item least astonishment, 23
  \item least-squares fitting, 11
  \item {\tt LEVELS}, 25
  \item library
    \subitem application, 9, 12--14
    \subitem licensing, 31
  \item light-pen, 4
  \item limit
    \subitem number of displayed boxes, 16
    \subitem number of knots in efficiency function, 11
  \item linear
    \subitem combination, 19, 21
    \subitem interpolation, 20
    \subitem scaling, 18
    \subitem transformation, 19
  \item linear combination, 18
  \item link editing, 20
  \item Lisp, 7
  \item live spectra, 10--12
  \item local area network, 9, 30
  \item locking, 14
  \item logarithmic scaling, 18
  \item logbook, 26

  \indexspace

  \item MacApp, 8
  \item Mach, 30
  \item Macintosh, 28
  \item macro-processor, 7
  \item macros, 8
  \item MacWrite, 25
  \item maintainers, 27
  \item manual, 28
  \item maps, 11--14
  \item marker character, 17
  \item markers, 16--18
    \subitem channel, 17
  \item maximum counts, 13
  \item medical physics, 16
  \item memory, 9, 30
  \item menu, 4, 8, 28
    \subitem pop-up, 23
  \item message, 8, 9, 22
    \subitem recorded, 22
  \item mimic diagrams, 8
  \item minimum counts, 13
  \item mis-features, 27
  \item misleading information, 24
  \item mode, 22, 23, 26
  \item modes, 8, 23
    \subitem online, 12
  \item modification time, 14
  \item monitoring, 6, 8
  \item monochrome, 22, 30
  \item mouse, 4, 7, 8, 17
  \item multi-tasking, 7, 23
  \item multiple comments, 13
  \item MVS, 15

  \indexspace

  \item NAG, 31
  \item na\"\i ve users, 8
  \item name, 16
    \subitem data base component, 12
    \subitem dataset, 17
    \subitem generation of, 13
    \subitem new, 13
  \item natural expansion, 17
  \item negative counts, 11
  \item Nero, 4
  \item new
    \subitem data, 18
    \subitem name, 13
  \item NeWS, 8, 31
  \item NFS, 30
  \item NIFTP, 14
  \item \nigs, 4
  \item {\pmediumseries \psc Nigs}, 0, 4, 6, 25--28, 30
  \item node of hierarchy, 13
  \item non-atomic operation, 13
  \item non-functional requirement, 12, 30
  \item non-linear re-scaling, 19
  \item non-spectral data, 11
  \item notes, 11--13
  \item NSF, 4, 8
  \item NSF interactive graphics system, 4
  \item NSF-supported sites, 14
  \item nuclear data bases, 20
  \item numerical range, 13

  \indexspace

  \item objects
    \subitem displayed, 16
  \item offline documentation, 29
  \item one dimensional, 16
  \item one-dimensional spectra, 16
  \item online
    \subitem dictionaries, 8
    \subitem histograms, 15
    \subitem mode, 12
    \subitem spectra, 26
  \item operating system, 30
  \item operation
    \subitem atomic, 13
    \subitem {\sl copy efficiency calibration}, 14
    \subitem data base, 10
    \subitem {\sl delete comment}, 13
    \subitem destructive, 13, 23
    \subitem ER, 15
    \subitem inappropriate, 24
    \subitem non-atomic, 13
    \subitem on data, 19
    \subitem on displayed box contents, 16
    \subitem partitioned spectra, 13
    \subitem {\sl read calibration}, 14
    \subitem {\sl read channel block}, 13
    \subitem {\sl read channel contents}, 13
    \subitem {\sl read channel error}, 14
    \subitem {\sl read comment}, 13
    \subitem {\sl read efficiency calibration}, 14
    \subitem {\sl read error block}, 14
    \subitem {\sl read graph data}, 14
    \subitem {\sl read map data}, 14
    \subitem {\sl read title}, 13
    \subitem {\sl read window}, 14
    \subitem {\sl refresh}, 18
    \subitem {\sl write calibration}, 14
    \subitem {\sl write channel block}, 14
    \subitem {\sl write channel contents}, 13
    \subitem {\sl write channel error}, 14
    \subitem {\sl write comment}, 13
    \subitem {\sl write efficiency calibration}, 14
    \subitem {\sl write error block}, 14
    \subitem {\sl write graph data}, 14
    \subitem {\sl write map data}, 14
    \subitem {\sl write title}, 13
    \subitem {\sl write window}, 14
  \item optical lineshapes, 20
  \item order
    \subitem spectrum dimensions, 14
  \item over-determination, 23
  \item over-writing, 13
  \item overflows, 19
  \item {\psl overlap}, 24
  \item overlap dataset/window, 18
  \item overlapped
    \subitem datasets, 17
    \subitem items, 16--18
  \item overlapping
    \subitem policy, 16

  \indexspace

  \item PaintJet, 30
  \item panning, 16--18
  \item {\psl panning}, 17
  \item parameters, 13, 16, 18
    \subitem analogue, 8
    \subitem fit, 19
    \subitem passed by shell, 7
  \item partitions, 11, 13
  \item pattern-matching, 13
  \item \acr{paw}, 5, 25
  \item peak, 19
    \subitem identification, 20
    \subitem intensities, 11
  \item {\tt PEAKFIND}, 20
  \item peakfinding, 20
  \item {\tt PEAKTOTOTAL};, 20
  \item period
    \subitem refresh, 18
  \item persistent objects, 8
  \item perspicuity, 8
  \item phrasebook, 8
  \item pictorial material in manual, 28
  \item pixel, 16, 17, 30
  \item plots, 25
  \item Poisson statistics, 11
  \item policy, 17, 19
    \subitem name generation, 13
    \subitem overlapping, 16
    \subitem statements, 30
  \item polyglot buttons/\penalty \exhyphenpenalty menus, 8
  \item polygon, 17
  \item polylines, 17
  \item polymarker, 16, 17
  \item portability, 14, 15
  \item Posix, 30
  \item \acr{PostScript}, 25, 30
  \item power, 8
  \item pre-emption, 23
  \item precision, 10, 19
  \item presentation graphics, 6, 25
  \item previewer, \TeX, 28
  \item previous expansion, 17
  \item previously-visited, 26
  \item principles
    \subitem meta, 22
    \subitem user interface, 22--24
  \item printable characters, 15
  \item process control, 7
  \item proforma, 7
  \item program, 7
  \item programmability, 8
  \item programming, 7
  \item projecting, 21
  \item prototype
    \subitem \nigs, 5
  \item prototyping, 4
  \item {\tt PSSKETCH}, 25
  \item public use, 23
  \item purpose of \nigs, 6

  \indexspace

  \item raison d' \^etre, 4
  \item range
    \subitem changing, 19
    \subitem display, 10
  \item re-binning, 11, 16, 19
  \item re-scaling, 13, 19
  \item {\psl read calibration}, 14
  \item {\psl read channel block}, 13, 14
  \item {\psl read channel contents}, 13
  \item {\psl read channel error}, 14
  \item {\psl read comments}, 13
  \item {\psl read efficiency calibration}, 14
  \item {\psl read error block}, 14
  \item {\psl read graph data}, 14
  \item {\psl read map data}, 14
  \item {\psl read title}, 13
  \item {\psl read window}, 14
  \item readout, 8
    \subitem histogram, 10
  \item recorded messages, 22
  \item records, 15
  \item refresh mechanism, 18
  \item region, 17
    \subitem changing, 17
    \subitem displayed, 17
    \subitem specifications, 17
    \subitem window, 17
  \item regular expression, 13
  \item remove fits, 18
  \item repetitive tasks, 8
  \item requirements document, 4
  \item {\psl reset}, 17
  \item resolution
    \subitem of screen, 30
  \item resource files, 8
  \item {\psl restore}, 17
  \item restrictions
    \subitem dimensionality of displayed data, 6
    \subitem language, 6
    \subitem representation of displayed data, 6
  \item {\psl retain}, 17
  \item retained expansion, 17
  \item {\psl revert}, 17
  \item ring of region specifications, 17
  \item routed spectra, 11
  \item rubber-banding, 21
  \item run, 12
  \item run book, 26

  \indexspace

  \item saved
    \subitem data, 12
    \subitem spectra, 12
  \item saving spectra, 10
  \item scalers, 11, 12
  \item Scheme, 30
  \item script, 26
  \item scripting, 23
  \item scripting language, 8, 23
  \item SDB, 12, 14, 15
  \item sections, 10
  \item self-documenting, 28
  \item Sension, 5, 7
  \item sets of items, 13
  \item setup
    \subitem equipment, 6
  \item {\tt sh}, 7
  \item shading, 22
  \item shell, 7, 9, 30
    \subitem control constructs, 7
    \subitem facilities, 7
    \subitem parameter passing, 7
    \subitem routines\slash macros\slash functions, 7
    \subitem scripts, 8
    \subitem Turing-equivalence, 7
    \subitem variables, 7
  \item siblings, 13
  \item Sigma3, 4, 7
  \item skew, 20
  \item SLC1, 30
  \item slices, 8, 10, 12, 18
  \item {\tt SMOOTH}, 19
  \item smoothing, 19
  \item {\tt SOFTWARE}, 27
  \item software life-cycle, 4
  \item solid surfaces, 6
  \item sort, 12
    \subitem commands, 12
    \subitem language, 15
  \item sort system, 10, 12
  \item sorting, 6, 8, 10
  \item sound, 22
  \item SparcStation, 22, 27, 30
  \item specification document, 4
  \item {\psl specify contour levels}, 18
  \item {\tt SPECTRA}, 25
  \item spectra, 10, 12, 13, 16, 17, 25
    \subitem creating, 10, 19
    \subitem dimension order, 14
    \subitem live, 10, 12, 18
      \subsubitem appearing to be files, 12
    \subitem manipulation, 10
    \subitem multi-dimensional, 12
    \subitem one-dimensional, 10, 12, 19
    \subitem online, 18
    \subitem precision, 10
    \subitem routed, 11
    \subitem saved, 12
    \subitem stored, 10
    \subitem three or more dimensions, 10
    \subitem two-dimensional, 10--12
  \item spectrum
    \subitem calibration, 10
    \subitem comments, 10
    \subitem partitions, 11
    \subitem title, 10
  \item spectrum data base, \see{SDB}{12}
  \item speed, 6, 8, 24, 27
  \item spline, 11, 17
  \item standard error, 11
  \item stereo sound, 22
  \item storage
    \subitem data base items, 12
    \subitem media, 15
    \subitem permanent, 10
  \item stored spectra, 10, 11
  \item streams, 26
  \item structure, 7
  \item sub-ranges, 11
  \item sub-tree, 13
  \item sums of exponentials, 20
  \item Sun Microsystems, 30
  \item SunOs, 30
  \item superdeformation, 8
  \item system
    \subitem interface, 7
    \subitem target, 15

  \indexspace

  \item tagging channels, 17
  \item tails on peaks, 20
  \item tape format, 15
  \item {\tt tar}, 15
  \item target system, 15
  \item \TeX, 28
  \item texinfo, 29
  \item text, 15, 23
    \subitem as opposed to data, 11
    \subitem files, 12
  \item The Publisher, 28
  \item theory, data from, 10
  \item tiling of data boxes, 17
  \item time-stamping, logbook entries, 26
  \item timer, 18
  \item {\psl times 2}, 18
  \item timing facilities, 7
  \item title, 10--12
    \subitem new, 19
  \item tolerance on mouse hits, 17
  \item tools
    \subitem general-purpose computing, 6
  \item touchstone, 22
  \item trailing number (in item name), 13
  \item transcript, 26
  \item transformation
    \subitem linear or logarithmic, 18
  \item transient object, 17
  \item translation, 15
    \subitem to \acr{PostScript}, 30
  \item transporting data, 14, 15
  \item tree
    \subitem menu, 28
  \item Turing-equivalent, 7
  \item tutorial system, 29
  \item two-dimensional
    \subitem data, 16, 18
    \subitem spectra, 17
  \item typing, 7, 8
  \item tyro, 28

  \indexspace

  \item un-overlap dataset/window, 18
  \item uncalibrated spectra, 16
  \item under-determination, 23
  \item undo, 13
  \item unfolding, 19
  \item uniformity, of live and saved spectra, 12
  \item units, 11
    \subitem calibration, 10
  \item Unix, 7, 12, 30
  \item user, 8
    \subitem commercial, 22
    \subitem disabled, 6
    \subitem expert, 23
    \subitem interface, 4
      \subsubitem principles, 22--24
    \subitem na\"{\i}ve, 22
    \subitem range of, 28
    \subitem sophisticated, 22
    \subitem technical competence of, 22
  \item `user-friendliness', 22
  \item users
    \subitem na\"\i ve, 23
    \subitem range of, 23
  \item users, na\"\i ve, 12
  \item utilities, 15

  \indexspace

  \item variable length records, 15
  \item verification, 6
  \item verity of information, 28
  \item version numbers, 27
  \item virtual filesystem, 12
  \item visualisation, 6, 25, 31

  \indexspace

  \item warning, 22
  \item wide area network, 31
  \item widget, 8
  \item wimp, 7, 31
  \item window, 16--18
    \subitem data base object, 8
    \subitem manager, 16
    \subitem record, 9, 12, 14, 15
      \subsubitem definitive version, 12
      \subsubitem re-defining, 12
    \subitem region, 17
  \item window regions, 17
  \item windowing system, 7, 23, 30, 31
    \subitem NeWS, 8, 31
    \subitem X11, 8
  \item wireframes, 6
  \item Wooff, C. D., 10
  \item workstation, 5, 30, 31
  \item {\psl write calibration}, 14
  \item {\psl write channel block}, 14
  \item {\psl write channel contents}, 13
  \item {\psl write channel error}, 14
  \item {\psl write comment}, 13
  \item {\psl write efficiency calibration}, 14
  \item {\psl write error block}, 14
  \item {\psl write graph data}, 14
  \item {\psl write map data}, 14
  \item {\psl write title}, 13
  \item {\psl write window}, 14
  \item WYSIWYG, 23

  \indexspace

  \item X windows, \see{X11}{31}
  \item X/NeWS terminals, 30
  \item X11, 8
  \item {\tt .Xdefaults}, 8
  \item {\tt XSCALE}, 19

  \indexspace

  \item $z$ display, 18
  \item zooming, 16--18
  \item {\psl zooming}, 17

\end{theindex}

\end{document}