\documentclass[10pt]{article}
\usepackage{EVLADocumentationStandard}
\usepackage{color}
\newcommand{\isotoday}{\space\number\year-{\ifcase\month\or
   Jan\or Feb\or Mar\or Apr\or May\or Jun\or
   Jul\or Aug\or Sep\or Oct\or Nov\or Dec\fi}-{\ifnum\day<10
   0\number\day \else \number\day \fi}}
%\newcommand {\red}    {\color[rgb]{1,0,0}}

%
%\date{2003-07-03}
\date{\isotoday}
\DocumentType{Requirements}
\DocumentNumber{SW-002}
\Revision{1.2.1}
\ContactAuthor{Steven T. Myers}
\title{DRAFT --- EVLA Data Post-Processing Software Requirements}
\author{{\em EVLA Software Science Requirements Committee:}\\
        S. Myers, B. Butler, C. Chandler, B. Clark, F. Owen, 
        M. Rupen, C. Brogan, R. Perley, P. Napier}
\sloppy
\owner{Steven T. Myers \href{mailto:smyers@nrao.edu}{(\tt smyers@nrao.edu)}}
\keywords{Requirements, Offline, Software, Science, Calibration}
\rhead{Offline Requirements}
%
\usepackage{color}
\usepackage[pdftitle={EVLA Data Post-Processing Requirements},
            bookmarks,bookmarksnumbered,
            letterpaper,
            debug]{hyperref}
\usepackage{typehtml}
\newenvironment{reddish}{\red}{}
\SGMLdef<red>{\begin{reddish}}
\SGMLdef</red>{\end{reddish}}
%
% --- modifications to the standard LaTeX styles
%
% Root of Use Cases html files.
% 
\newcommand{\ucroot}{/home/sandrock/smyers//VLA/EVLA/}
\newcommand{\htmlinputtarget}[1]{
	\hypertarget{#1}{}
	\htmlinput{\ucroot/#1} }
\makeatletter
\def\HTML@dosrc#1#2{\hyperlink{#1}{#2}}
\def\HTML@doname#1#2{\hypertarget{#1}{#2}}
%
% Change in enumerate because of high nesting in Use Cases.
%
\renewcommand\theenumi{\@arabic\c@enumi}
\renewcommand\labelenumii{\theenumii.}
\renewcommand\theenumii{\@arabic\c@enumii}
\renewcommand\theenumiii{\@arabic\c@enumiii}
\renewcommand\theenumiv{\@arabic\c@enumiv}
\@definecounter{enumv}
\@definecounter{enumvi}
\def\enumerate{
  \ifnum \@enumdepth >5\@toodeep\else
    \advance\@enumdepth\@ne
    \edef\@enumctr{enum\romannumeral\the\@enumdepth}
      \expandafter
      \list
        \csname label\@enumctr\endcsname
        {\usecounter\@enumctr\def\makelabel##1{\hss\llap{##1}}}
  \fi}
\let\endenumerate =\endlist
%
% Page size parameters.
%
\parindent 0pt
%\textheight 650pt
%\textwidth 460pt
%\oddsidemargin 0pt
%\evensidemargin 0pt
%\marginparwidth 50pt
%\topmargin 0pt
\brokenpenalty=10000
\parskip 2mm
\renewenvironment{itemize}
{\list{---}{\itemsep 0pt \parsep 0pt \topsep 0pt} }
{\endlist}
% 
% requirement numbering and referencing
% From Bryan Butler's EVLA SSR doc
%
\makeatletter
\newcounter{reqseci}
\newcounter{reqsecii}[reqseci]
\newcounter{reqseciii}[reqsecii]
\newcounter{reqseciv}[reqseciii]
\newcounter{reqsecv}[reqseciv]
%
\renewcommand*{\thereqseci}{%
   \ifnum\c@subsection=\z@
      \thesection%
   \else
      \ifnum\c@subsubsection=\z@
         \thesubsection%
      \else
         \thesubsubsection%
      \fi
   \fi
   -R\arabic{reqseci}%
   }
\renewcommand*{\thereqsecii}{\thereqseci.\arabic{reqsecii}}
\renewcommand*{\thereqseciii}{\thereqsecii.\arabic{reqseciii}}
\renewcommand*{\thereqseciv}{\thereqseciii.\arabic{reqseciv}}
\renewcommand*{\thereqsecv}{\thereqseciv.\arabic{reqsecv}}
%
\newcommand*{\labelreqseci}{\textbf{\thereqseci}}
\newcommand*{\labelreqsecii}{\textbf{\thereqsecii}}
\newcommand*{\labelreqseciii}{\textbf{\thereqseciii}}
\newcommand*{\labelreqseciv}{\textbf{\thereqseciv}}
\newcommand*{\labelreqsecv}{\textbf{\thereqsecv}}
%
\newcount\@reqdepth \@reqdepth = 0
%
\def\reqlist{%<--can be nested
   \ifnum \@reqdepth >4\relax\@toodeep\else
      \advance\@reqdepth\@ne
      \edef\@reqctr{reqsec\romannumeral\the\@reqdepth}%
      \expandafter\list\csname label\@reqctr\endcsname
        {\usecounter\@reqctr%
         \renewcommand\makelabel[1]{##1\hfill}%<- roll your own
%         \settowidth{\labelwidth}{\csname label\@reqctr\endcsname}%<-ditto
         \setlength{\labelwidth}{5truemm}
         \setlength{\leftmargin}{\labelwidth}%
         \addtolength{\leftmargin}{\labelsep}%
        }%
   \fi}
\let\endreqlist=\endlist
\makeatother
%
% ---COMMAND FOR EVLA PRIORITIZATION
%
\newcommand{\priority}[2]{\par\noindent{\em Priority:~#1}\ {\em Timescale:}~#2}
%
% ---NEW COMMANDS FOR EVLA Audit
%
\newcommand{\Funct}[1]{\par\noindent{\it Functionality:}~{#1}}
\newcommand{\Use}[1]{\par\noindent{\it Useability:}~{#1}}
\newcommand{\Doc}[1]{\par\noindent{\it Documentation:}~{#1}}
\newcommand{\Com}[1]{\par\noindent{\em Comments:} #1}
%
% ---NULL COMMANDS FOR EVLA Audit
%
% To supress the evaluation labels, uncomment the following:
%\newcommand{\Funct}[1]{}
%\newcommand{\Use}[1]{}
%\newcommand{\Doc}[1]{}
%\newcommand{\Com}[1]{}
%
% ---deal with deep nesting
%
\setcounter{secnumdepth}{4}			%% dss
\setcounter{tocdepth}{4}			%% dss
%
% ---OLD COMMANDS
%
\newcommand{\reqpri}[1]{\par\noindent{\em Priority:~#1}}
\newcommand{\reqprip}[1]{ ({\em Priority:~#1})}
%
% ---end of modifications to the standard LaTeX styles
%
\begin{document}
\maketitle
\newpage
\begin{center}
{\it Change Record}\\[5mm]
\begin{tabular}{|l|l|l|l|l|}
\hline
Revision & Date & Author & Section/ & Remarks \\
         &      &        & Page affected  &         \\
\hline
1.0& 2002-09-09 & S.T. Myers & All & initial version   \\
1.1& 2003-05-01 & S.T. Myers & All & start pre-SSR edit \\
1.1.1& 2003-05-20 & S.T. Myers & All & end pre-SSR edit \\
1.2& 2003-06-06 & S.T. Myers & All & SSR edit \\
1.2.1& 2003-07-03 & S.T. Myers & 9.5, 5.4, 5.5 & WB pulsar, STM imaging \\
\hline
\end{tabular}
\vfill
\verb|$Id: evla_offline.tex,2003/07/03 myers Exp myers $|

\end{center}
\newpage
\tableofcontents
%---------------------------------------------------------------
\newpage
\section*{Introduction}
\addcontentsline{toc}{section}{\numberline{}Introduction}

This document describes the requirements for offline data processing software
packages in order to be able to handle the EVLA data output.
This document provides additional requirements to those delineated in the
\href{http://www.aoc.nrao.edu/~smyers/evla/evla_requirements.pdf}
{\sc EVLA Software Science Requirments} document.

Some of the content of this document is based on the AIPS++ User 
specifications Memo 115 found at:

\href{http://aips2.nrao.edu/stable/docs/specs/specs.html}
{\tt http://aips2.nrao.edu/stable/docs/specs/specs.html}

\subsection*{Nomenclature}
\addcontentsline{toc}{subsection}{\numberline{}Nomenclature}

The subject of these EVLA Data Post-Processing
Requirements is referred to as the {\it Package} or {\it Offline Package}.
This is intended as a set of tools or programs, believed adequate for EVLA
reductions, and used by observers and archive users for science and by EVLA
staff for array testing and monitoring.  It may be that more than one Package
fulfills the requirements and thus can be
considered as suitable for EVLA processing.  The requirements will state that
the Package will be available for installation on the observer's own computer
systems as well as present at NRAO.  In the EVLA baseline plan, the Package
is AIPS++, though AIPS will likely fulfill many of the requirements of the
EVLA as it does for the VLA.

The user of the Package may be referred to as {\it user} or {\it observer}, 
and may be the actual proposer or a staff member or an archive user.  
In automated modes, the user may actually be another tool or program, such
as in Pipeline use.

The {\it Archive} refers to the totality of the EVLA data storage and consists
of possible different physical archives.

Definitions of various terms, such as {\it scans}, are given in 
\href{http://www.aoc.nrao.edu/~smyers/evla/evla_requirements.pdf}
{\sc EVLA Software Science Requirments}.

\subsection*{General Considerations}
\addcontentsline{toc}{subsection}{\numberline{}General Considerations}

\begin{description}

\item [A.] Two integral aspects of the EVLA not dealt with
specifically in this document are the Archive and the non-science
Pipelines (Calibration and Quick-look).  We have included the topic
``Interaction with Archive'' (\S\ref{sec:ol:dh:arc}) dealing with the
interaction of the Offline Package with the Archive.  The requirements
for the non-science Pipelines and Archive are given in the
\href{http://www.aoc.nrao.edu/~smyers/evla/evla_requirements.pdf} {\sc
EVLA Software Science Requirments} document.  Science Pipeline considerations
are given in \S\ref{sec:ol:pl}.

\item [B.] There is no fundamental difference between spectral-line and
continuum observations, merely number of channels and bandwidths coming out of
the correlator.  Due to the nature of the EVLA WIDAR correlator, most of the
special calibration needs of traditional spectral line observations (e.g.\
bandpass calibration) are also applicable to continuum observations (continuum
is built up through summation of spectral channels taken at low resolution).
We will assume that all data will be effectively taken in spectral line mode.

\item [C.] There is no fundamental distinction needed for polarization data,
merely consideration of the number of polarization products or polarization
states needed for processing.  The model we consider here is the processing of
one or more Stokes parameters and thus polarization is integrated into all the
topics.  One complication that must be considered is the combination of the
array (antenna polarization correlation products) and single-dish data 
(the antenna polarization outputs).

\item [D.] We use a system of prioritizing with codes:

We have developed a 2 dimensional priority scheme, which encompasses 
both the importance and the timescale for a particular requirement.

The importance can have the following values:

\begin{description}
   \item [1] = essential
   \item [2] = important
   \item [3] = desirable, but not critical
\end{description}

It is intended that Priority 1 items must be present and work with high 
efficiency.  Priority 2 items should be present, though there may have 
to be sacrifices in performance or availability may be delayed.  
We expect that the software will fulfill all Priority 1 and 90\% or 
more of Priority 2 requirements.  Priority 3 items should be considered 
for upgrades or development. 

The timeframe of deployment is matched to the EVLA Phase I Project 
schedule (see the {\it EVLA Project Book}).  The timescale phases are:

\begin{description}
   \item [A] transition phase (2004 Q2)
   \item [B] prototype correlator (2005 Q4)
   \item [C] shared-risk Science operations (2007 Q2)
   \item [D] full science operations, completion of EVLA Phase I (2010 
      Q2)
   \item [E] ``eventually'' sometime after completion (ongoing)
\end{description}

These are the same as the priorities which will be used in
{\it EVLA Science Software Requirements}.

\item [E.] Specific requirements are broken into sub-cases or
instances (e.g.\ R1 R1.1, R1.2) for clarity.  These sub-requirements
are either special cases of the main requirement (often with different
priority) or itemized instances or examples related to the requirement.

We have done our best to be complete in our enumerations of features in the
sub-requirement and sub-sub-requirement lists.  However, we anticipate that
as the project progresses, we will discover new desirable features that 
should be added to these lists.  Therefore, one should consider these
lists not as all-inclusive checklists, but as our best attempts at listing the
important features for the requirements in question at this early time in
the project.

\item [F.] There are a number of instances where certain specifications,
such as data formats supported, are designated as being in a list maintained
by the EVLA project.  There are other points in the requirements that
refer to ``standard modes'', which implies a detailed list (tbd) also
maintained by the project.  These cases are indicated in {\bf boldface}
to aid in determining which lists will need to be constructed.  We are unable
to fully specify these items at the current time, and the definition of these
will be an ongoing effort for the SSR and the EVLA Project.

\item [G.] We have done our best to make the requirements quantitative, and 
to clearly define the meaning of qualifiers and adjectives.  However, there
are instances where the substance of particular requirements is 
necessarily subjective (e.g.\ ``ease of use'' and ``robustness'' type
requirements).  Rather than spelling these out in detail, we have have
left these ``squishy'' requirements as-is, and will rely upon the SSR and
Package representatives to take these properly into account during the 
evaluation process.

There are also a number of places, such as the headers to sections,
where we discuss the philosophy behind our choice of requirements.  In those
cases, the discussions are given as {\it italicized} text and are not meant as
requirements in and of themselves.
 
\item [H.] The guidelines for the evaluation of proposed Offline Packages
based on the requirements given in this document will be given in a
separate EVLA SSR Auditing document.
 
\end{description}

\newpage

\section{General and Operational Requirements}\label{sec:ol:ops}

{\it Note: An EVLA Data Post-Processing Package (or ``the Package'') is
primarily intended to enable end-users of the EVLA (e.g.\ observers or Archive
users) to produce scientifically viable results that involve EVLA data
products.  The secondary use is to enable EVLA staff to assess the state of
the array and derive calibration parameters for the system. }

\subsection{Operational Issues}\label{sec:ol:gen:ops}

\begin{reqlist}

\item There must be an Offline Data Processing Package that fulfills the
requirements laid forth in this document. 
\priority{1}{A}

\item All standard observing modes, data sizes and data rates produced by the
EVLA must be processable by the Package, including:

   \begin{reqlist}

   \item data produced during the transition phase; 
         \priority{1}{A} 

   \item data produced by the prototype correlator; 
         \priority{1}{B}

   \item basic modes supported during shared-risk observing
         (16384 channels, 10 MB/s); 
         \priority{1}{C} 

   \item majority of modes at completion of Phase I; 
         \priority{1}{D}

   \item full capability of the correlator and system; 
         \priority{1}{E} 

   \end{reqlist}

\item The Package shall be installable at the users home institution and
available at NRAO (both locally and remotely).  It shall be
portable to {\bf supported platforms designated by the EVLA Project},
including systems without network connections and laptops. 
\priority{1}{D}

\item The performance of the Package shall be quantifiable and commensurate
with the data processing requirements of EVLA output and the scientific needs
of users at a given time.  The timing and reproducibility of results for 
a fiducial set of reduction tasks on specified test data will be benchmarked
(e.g.\ ``AIPSmarks'') and compared against other packages and {\bf a 
list of benchmark specifications provided and maintained by the Project}. 
\label{req:perf} \priority{1}{D}

\item Installation of the Package by an end user must be straightforward, 
preferably without special (e.g.\ root) user permission. 
\priority{1}{D} 

\item Error reporting and handling shall be user-understandable and
non-destructive at all levels in the Package:

   \begin{reqlist}

   \item There must be provision for job control such as interrupt and
         abort. \priority{1}{D} 

   \item Error reporting messages shall be written for end users, not
         programmers. \priority{2}{D}

   \item Error handling shall be non-destructive (data shall not be left
         corrupted, and recovery of recent changes be available). Common 
         failure modes (as enumerated: invalid application
         parameters, exceeding of resource limits (disk/memory), and 
         algorithm failure modes (e.g.\ no convergence) should be handled
         gracefully. \priority{2}{D}

   \item Code traceback of execution errors shall be available.  This should
	 be geared to the effective reporting of failure modes and bugs
	 by the user. \priority{3}{D}

   \end{reqlist}

\item There shall be comprehensive handling of multiple users and
multi-tasking with access and process control.
\priority{1}{D}

\item The Package providers shall provide support for the Package, with 
bug-fixing on timescales appropriate to the severity level of the defect
(e.g.\ 1 week or less for catastrophic bugs with no work-around).  {\bf These
defect levels and timescales should be delineated by the EVLA project}.
\priority{1}{D}

\item The Package providers shall provide timely improvements and updates
based on user feedback.  There shall be a path for the EVLA Project, for
its own use and as a proxy for the users, to influence the development
cycle of the Package.  It is the responsibility of the Project to negotiate
needed improvements with the Package providers.
\priority{1}{D}

\item Backward compatibility of core package components should not be broken
without compelling scientific reasons.  Tools should be provided to parse user
scripts and warn of package changes.
\priority{2}{D}

\item Source code for the astronomical routines in the Package shall be
available to the user.
\priority{2}{D}

{\it Notes: This does allow for the use of some proprietary data handling, 
output formatting, and special processing (e.g.\ Pixon) routines.}

\item Initial startup of the Package (e.g.\ memory use, caching, modules
loaded), once installed, should be straightforward for the user to optimize
for their specific machine to minimize run time.
\priority{2}{D} 

   \begin{reqlist}

   \item It shall be possible to save the current state for subsequent 
         startup. 
         \priority{2}{D}

   \item It should be possible for the user to reconfigure run-time
         options in ASCII by editing a personal setup file. 
         \priority{3}{D}

   \end{reqlist}

\item User installation of the basic package shall not be restricted by other
issues such as expensive or unduly restrictive licenses.  The Package
license should convey all other necessary licenses (such as GNU) or they
should be available to the user for only a nominal fee. 
\priority{2}{D}

{\it Comment: This allows for the use of commercial components.  However,
a balance must be struck between excessive costs to the project and requiring
some cost to be borne by the user, should this issue arise.}

\item There shall be the provision for the development and incorporation
of user-supplied code.
\priority{2}{D}

\item The use of the Package for end-to-end processing of common
EVLA observations shall not entail an excessive learning curve. 
Average users, with experience with the current generation of packages
(e.g.\ AIPS, also GILDAS, IRAF, MIRIAD) shall be able to become proficient in
the Package use in a timescale of approximately 24 hours dedicated use, and
truly neophyte users (e.g.\ graduate students) should be reach proficiency with
an investment not exceeding 40 hours of dedicated use.  This should
be possible based upon the Package provided documentation and not rely
upon the availability of tutorials or personal help by the Package
providers. 
\priority{2}{D}

\end{reqlist}

\newpage

\section{Interface}\label{sec:ol:ui}

\subsection{General User Interface Requirements}\label{sec:ol:ui:gen}

\begin{reqlist}

\item User must be able to choose from a variety of interface styles,
including: 

   \begin{reqlist}

   \item A Command Line Interface (CLI) must be provided, with access
	 via both an interactive input and via script.
         \priority{1}{A}

   \item A Graphical User Interface (GUI) must be provided for
	 interactive processing.  Actions taken under the GUI must
	 be loggable, editable, and executable by the CLI.
         \priority{1}{C}

   \end{reqlist}

\item Both GUI-based and CLI tools shall be available for reduction
of data taken in all standard EVLA observing modes.
\priority{1}{D}

\item The user shall be able to interact with the host operating
system with command sequences invoked from the UI. 
\priority{1}{D}

\item Multitasking for all interfaces shall be available where
appropriate. It must be possible to run one or more long-running
calculations in the background. While background tasks 
are running normal interactive activities must be possible.
\priority{1}{D}

\item It shall be possible for the user to configure certain default
interface options at startup, such as browser, level of help, and default
viewer or pgplotter options.
\priority{2}{D}

\end{reqlist}

\subsection{Graphical User Interface (GUI)}\label{sec:ol:ui:gui}

{\it Note: The GUI is intended to be the primary interactive mode for
users, especially neophyte users, and thus should be tailored for clarity
and ease of use.  Use of the Package GUIs should be a pleasurable, not a
frustrating, experience!}

\begin{reqlist}

\item The GUI shall provide real-time feedback via standard compact displays:

   \begin{reqlist}

   \item Window updating must be fast (less than $0.1$s on same host). 
         \priority{1}{C}

   \item Moving and resizing of all windows must be available, robust, 
         and easy. 
         \priority{2}{D}

   \item Windows shall not take up excessive screen space, with full GUI
	 controls visible on a window one-third the size of a standard
	 view surface (or approximately $800\times800$ pixels).
         \priority{2}{D}

   \item Users shall have the choice of cascading windows or re-use of a
	 single window for new operations.
         \priority{2}{D}

   \item There shall be a master control GUI for process
   	 control which keeps track of sub-windows and tools.
         \priority{3}{D}

   \end{reqlist}

\item It must be easy to run GUIs remotely from the host machine
(e.g.\ via X displays). 
\priority{1}{D}

\item The use of the GUI shall not entail an excessive learning curve. 
Average users, with experience with the current generation of packages
(e.g.\ AIPS, also GILDAS, IRAF, MIRIAD) shall be able to become proficient in
GUI use in a timescale of approximately 12 hours dedicated use, and truly 
neophyte users (e.g.\ graduate students) should be reach proficiency with
an investment not exceeding 40 hours of dedicated use.
\priority{2}{D}

\item The look and feel of the GUI, including plotting and graphical
displays, shall be uniform throughout the entire package. Interfaces
shall have similar look and feel to reduce the learning curve.
\priority{2}{D}

\item The look and feel of the GUI must be acceptable to both novice
and more advanced users.  The GUI mode might be customizable (perhaps
through menu selection for ``novice'' or ``advanced'' mode) or a different
simpler set of GUI tools might be available for beginners.  The GUI features
for beginner mode shall include: 

   \begin{reqlist}

   \item built-in help facility with access to novice-oriented help
         documents (e.g.\ sections in the cookbook);
         \priority{2}{D}

   \item sensible defaulting of values for parameters, with guidance for
         user choices where needed;
         \priority{2}{D}

   \item integrated functionality built around common data analysis tasks 
         (e.g.\ single-field spectroscopic observations with fast switching,
         OTF mosaicing in continuum mode, snapshot observations of a large
         number of targets in single-field continuum mode);
         \priority{2}{D}
         
   \end{reqlist}

\item All data processing functionality (as opposed to scripting control,
or system-level operations) available in the CLI mode shall also be available
in GUI mode.
\priority{2}{D}

\item It is shall be easy for users to develop and include
their own custom GUIs in the Package.
\priority{3}{D}

\end{reqlist}

\subsection{Command Line Interface (CLI)}\label{sec:ol:ui:cli}

{\it Note: the CLI is the primary mode for automatic reduction for EVLA,
and it is anticipated that there will be a suite of ``standard'' scripts
developed to help users in data reduction tasks.  Thus it is important
that the Package support all of its critical modes in the CLI.}

\begin{reqlist}

\item The interface must have the facility to read in command files
for batch processing of a sequence of CLI commands.
\priority{1}{C}

\item The CLI shall have command-line recall and editing.
\priority{1}{D}

\item All functionality of the GUI must also be available in CLI mode
(although possibly with loss of simplicity in instances where the graphical
selection is important). 
\priority{2}{D}

\item The CLI shall be usable remotely over low-speed (14400 baud) modem lines
or network connections, with ASCII terminal emulation.
\priority{3}{D}

\item The CLI shall have name completion where appropriate. 
\priority{3}{E}

\item A menu or other means of displaying and editing function input
parameter values in CLI mode is desirable.
\priority{3}{E}

\end{reqlist}

\subsection{Interface Programming, Parameter Passing and Feedback }
\label{sec:ol:ui:prog}

\begin{reqlist}

\item The UI must have basic programming facilities including but not
limited to:

   \begin{reqlist}

   \item variable assignment and evaluation; \priority{1}{C}

   \item conditional statements; \priority{1}{C}

   \item control loops; \priority{1}{C}

   \item string manipulation; \priority{1}{C}

   \item array handling;  \priority{1}{C}

   \item user-defined functions and procedures with argument or parameter
         passing; \priority{1}{C}
   
   \item process control, interrupts, error handling; \priority{1}{D}

   \item standard mathematical operations and functions; \priority{1}{D}

   \item efficient special vector and matrix operations; \priority{2}{D}

   \item user-defined data structures; \priority{3}{D}

   \end{reqlist}

\item Parameters shall be passable between applications, tasks, or functions.
\priority{1}{D}

   \begin{reqlist}

   \item values shall be storable in user-defined variables, which can be 
         passed to tasks or functions;
         \priority{2}{D}

   \item the user and/or programmer shall have control over whether variables
         are local (to tasks or functions) or global (and thus inherited
         between functions);
         \priority{3}{D}
 
   \end{reqlist}

\item Parameter inputs to tools shall be stored for later recall:

   \begin{reqlist}

   \item Tool inputs shall be saved on closure, and reinstated on
         the next instantiation of the tool.
         \priority{2}{D}

   \item It shall be possible for the user to save the state of the 
         parameters for the entire package, as well as for individual
         tools, as a named set (e.g.\ SAVE/GET in AIPS), and to recall 
         these when desired.
         \priority{3}{D}

   \end{reqlist}

\item Input parameter and syntax checking shall be effected upon function
calling or parsing with reporting of incorrect, suspicious or dangerous 
choices before execution where possible.
\priority{2}{D}

\item Application variables shall be named consistently and as clearly as
possible indicating their intended use using astronomical terms where
appropriate.
\priority{2}{D}

\end{reqlist}

\subsection{Session Logging}\label{sec:ol:ui:log}

\begin{reqlist}

\item There shall be session logging, including the following features:

   \begin{reqlist}

   \item logging of commands and user inputs shall be provided from both
         the CLI and GUI; 
         \priority{1}{C}

   \item logging of tool results such as success or error, files
         written, time of completion shall be provided; 
         \priority{2}{D}

   \item logging of tool output such as summaries of results shall be
         provided;
         \priority{2}{D}

   \item the session log shall be readable by the user (i.e.\ in a
         text file, not in a binary format);
         \priority{2}{D}

   \item session logs shall be executable by the package UI, reproducing
         the entire session;
         \priority{2}{D}

   \end{reqlist}

\end{reqlist}

\subsection{Documentation and Help Facility }\label{sec:ol:ui:doc}

\begin{reqlist}

\item The Package creators must ensure the documentation is up-to-date
and complete for all parts of the Package.
\priority{1}{C}

\item There shall be a variety of help levels and documentation formats
accessible from the UI and over the Internet, applicable to novices, experts,
and technical users.  These shall include:

   \begin{reqlist}

   \item application descriptions and reference manual (with all inputs to
	 functions and tools); \priority{1}{C}

   \item user cookbooks with extensive examples; \priority{1}{D}

   \item bug reports and tracking; \priority{1}{D}

   \item Script library with adequate documentation and comments in
   	 the scripts for the intermediate-level user; \priority{2}{C}

   \item online help, FAQ, email contacts (these shall be updated on
   	 a timely basis, e.g. with each public release); 
         \priority{2}{D}

   \item programmer references and guides; \priority{2}{D}

   \item release history, patch descriptions;  \priority{2}{D}

   \item data format descriptions; \priority{3}{D}

   \item algorithm descriptions; \priority{3}{D}

   \item newsletters, email exploders, notes series; \priority{3}{D}

   {\it Note: these would be maintained by the Package providers, with
	help from the EVLA project.}

   \end{reqlist}

\item Help materials shall be available online, via the Web.
\priority{1}{C}

   \begin{reqlist}

   \item The top-level organization of the help documentation on the
         web should be easy to navigate for the new user.
         \priority{2}{D}

   \end{reqlist}

\item Help materials shall also be available when the user is offline.
\priority{1}{C}

\item Help materials shall also be available in printable formats, including

   \begin{reqlist}

   \item standard document formats (pdf, postscript);
         \priority{1}{C}

   \item printer-friendly versions of HTML pages; \priority{2}{D}

   \item popular proprietary formats (MS-Word); \priority{3}{D}

   \end{reqlist}

\item Help shall be context-sensitive where relevant.

   \begin{reqlist}

   \item Both the GUI and CLI-based help levels should be appropriate
         for the beginning user and should be consistent (e.g. GUI and CLI
         help should provide the same documentation links or information).
         \priority{2}{D}

   \item In GUI mode, fly-over banners should indicate use of buttons and
         fields, and clickable help buttons should be available on all GUI
         windows. \priority{2}{D}

   \item In GUI mode, help functions shall direct a browser to a Web page.
         \priority{2}{D}

   \item In CLI mode, the Package must support in-line text based help.
         \priority{2}{D}

   \end{reqlist}

\item Full search capability must be built into the documentation library. 
\priority{2}{D}

\end{reqlist}

\newpage

\section{Data Handling} \label{sec:ol:dh}

\subsection{EVLA Data Import and Export}\label{sec:ol:dh:imp}

\begin{reqlist}

\item A variety of data formats must be supported by the Package:

   \begin{reqlist}

   \item The {\bf EVLA standard archival data format} must be supported
         for input without loss of functionality or information.
         \priority{1}{C} 

   \item The {\bf VLA standard archival data format} must be supported
         for input without loss of functionality or information. 
         \priority{1}{C} 

   \item Standard FITS format (uv and image) shall be supported
         for both input and output without loss of functionality or
         information.
         \priority{2}{D}

   \end{reqlist}

\item Disk-based data storage must be supported. 
      \priority{1}{C}

   \begin{reqlist}

   \item File sizes shall not have artificial (e.g. OS-imposed 2GB) 
         limits that are visible to the user.
         \priority{2}{D}

   \end{reqlist}

\item Offline data storage (e.g.\ DAT, DDS, DLT) must be supported.
\priority{1}{D}

\item The Package must be able to handle, efficiently and gracefully,
datasets larger than main memory of the host system. 
\priority{1}{D}

\item The Package internal data format, which may be independent of
other supported formats, must not be ``bloated'' and the required
storage should not exceed by more than $1.5\times$ the raw data format. 
\priority{1}{D}

\item The option to drop flagged data on inport and export shall be
included. 
\priority{2}{D}

\item There shall be a facility for dropping data from baselines
involving shadowed antennas, with the ability to specify the allowable
shadowing (including negative values).
\priority{2}{D}

\item Averaging of data over time, interferometer hour angle, IFs, and
spectral channels shall be possible, for:

   \begin{reqlist}

   \item data filled from a standard (EVLA,VLA,Package Internal) format
         upon import;
         \priority{2}{D}

   \item data written to a standard (EVLA,VLA,Package Internal) format upon
         export; 
         \priority{2}{D}

   \end{reqlist}

\item The history information filled with the data must be preserved, 
if requested by the user. 
\priority{2}{D}

\item Calibration and ancillary monitoring data (e.g.\ weather information,
WVR data, GPS data, pointing) that are filled with the data must be
preserved, if requested by the user. 
\priority{3}{D}

\item Compression of the data, with a selectable level of loss, shall
be possible at:

   \begin{reqlist}

   \item the filling or import stage; \priority{3}{D}

   \item arbitrary stages of the processing path. \priority{3}{E}

   \end{reqlist}

\item Correlation products accumulated at multiple bit depths (16-bit,32-bit)
or compressed data must be supported transparently. 
\priority{3}{E}

\end{reqlist}

\subsection{Import and Export of Images and Other Data Products}

\begin{reqlist}

\item Standard multi-dimensional images must be supported, including:

   \begin{reqlist}

   \item Spectra and image slices (1D);
         \priority{1}{D}

   \item Planar images (2D);
         \priority{1}{D}

   \item Spectral and time cubes (3D);
         \priority{1}{D}

   \item Higher-dimensional images (4D+).
         \priority{2}{D}

   \end{reqlist}

\item Blanking or masking of pixels shall be maintained through the processing
of images. \priority{1}{D}

\item Other standard derived data products must be supported, including:

   \begin{reqlist}

   \item Point (CLEAN) models; \priority{1}{D}

   \item Pixel (gridded image) models; \priority{1}{D}

   \item Elliptical Gaussian models; \priority{1}{D}

   \item Uniform (optically thick) disk models; \priority{2}{D}

   \item Optically thin disk models; \priority{2}{D}

   \item wavelets; \priority{3}{E}

   \item Pixons; \priority{3}{E}

   \end{reqlist}

\item The package shall support all standard projections, including:
\label{req:project}

   \begin{reqlist}

   \item sine or slant orthographic (SIN); \priority{1}{C}

   \item tangent or gnomonic (TAN); \priority{2}{D}

   \item cylindrical plate carr\'{e}e (CAR); \priority{3}{E}

   \item Mercator (MER); \priority{3}{E}

   \item stereographic (STG); \priority{3}{E}

   \item Hammer-Aitoff (AIT); \priority{3}{E}

   \item Molleweide (MOL); \priority{3}{E}

   \end{reqlist}

\end{reqlist}

\subsection{EVLA Data Objects}\label{sec:ol:dh:obj}

{\it We refer to the sum total of the data and meta-data necessary to process 
EVLA observations as an ``EVLA Data Object''.  Ideally, these would all be
contained in tables and/or links to files that are carried along with the 
data.  However, in the simplest form the user keeps track of this themselves,
as in most current packages.}

\begin{reqlist}

\item The Package must support data taken in any of the standard EVLA
observing modes. 
\priority{1}{D}

\item The Package shall be able to handle the integrated data objects
corresponding to the observational programs carried out by the EVLA.  These
objects may be implemented in any manner appropriate, though relations between
the components of the object should be maintained through some mechanism.
These include:

   \begin{reqlist}

   \item program header information; \priority{1}{C}

   \item antenna information, including:

      \begin{reqlist}

      \item antenna identifier (e.g.\ number, pad or station name); 
            \priority{1}{C}

      \item antenna locations (XYZ, in astrometrically useable form);
            \priority{1}{C}

      \item antenna feed type; \priority{1}{D}

      \item antenna feed polarization parameters; \priority{2}{D}

      \item antenna (and receiver) calibration parameters 
            (e.g.\ temperature, efficiency); \priority{2}{D}

      \item antenna gain curves; \priority{3}{D}

      \end{reqlist}

   \item field (pointing) information, including:

      \begin{reqlist}

      \item field (pointing) identifier (e.g.\ number, name); \priority{1}{C}

      \item field (pointing) direction; \priority{1}{C}

      \item interferometer phase center; \priority{1}{C}

      \item scanning pattern (e.g. for OTF mapping); \priority{3}{D}

      \item offset from target field (e.g. for fast switching); \priority{3}{D}

      \end{reqlist}

   \item source (target) information, including:

      \begin{reqlist}

      \item source (target) identifier (e.g.\ number, name); \priority{1}{C}

      \item source (target) coordinates; \priority{1}{C}

      \item source (target) position as function of time (for moving sources);
            \priority{2}{D} 

      \end{reqlist}

   \item interferometer baseline information, including:

      \begin{reqlist}

      \item baseline identifier (e.g. antenna pair); \priority{1}{C}

      \item u, v, w coordinates; \priority{1}{C}

      \end{reqlist}

   \item polarization (interferometer products or single-dish state);
         \priority{1}{C}

   \item spectral channels; \priority{1}{C}

   \item frequency bands and/or IFs; \priority{1}{C}

   \item Coherence function (visibility) data from the interferometer,
	 including:

      \begin{reqlist}

      \item cross-correlations; \priority{1}{C}

      \item auto-correlations; \priority{1}{C}

      \item uncorrected and/or online WVR corrected (if available and
            chosen by user); \priority{1}{D}

      \item phased-array data (if available and chosen by user);
            \priority{2}{D}

      \end{reqlist}

   \item interferometer subarray identifier; \priority{1}{C}

   \item weights and/or data uncertainties; \priority{1}{C}

   \item flagging data or masks; \priority{1}{C}

   \item a priori calibration data, including:

      \begin{reqlist}

      \item source flux densities; \priority{1}{C}

      \item antenna gain parameters; \priority{1}{C}

      \item atmospheric optical depth corrections; \priority{1}{C}

      \item antenna feed polarization parameters; \priority{1}{D}

      \item bandpasses; \priority{2}{D}

      \end{reqlist}

   \item derived calibration data, including:

      \begin{reqlist}

      \item gain solutions; \priority{1}{C}

      \item bandpasses; \priority{1}{C}

      \item source flux densities; \priority{1}{D}

      \item antenna feed polarization parameters; \priority{1}{D}

      \end{reqlist}

   \item processing history; \priority{1}{D}

   \item ancillary calibration information, as function of time, including:

      \begin{reqlist}

      \item system temperatures; \priority{2}{D}

      \item weather information; \priority{2}{D}

      \item tropospheric monitoring (e.g. path delay); \priority{3}{D}

      \item ionospheric monitoring (e.g. TEC); \priority{3}{D}

      \end{reqlist}

   \item images and/or models produced from data; \priority{2}{D}

   \item states indicating special modes, such as:

      \begin{reqlist}

      \item solar observing mode; \priority{2}{D}

      \item pulsar gating; \priority{2}{D}

      \item OTF scanning; \priority{3}{D}

      \end{reqlist}

   \item diagnostic (e.g.\ monitor and control) data and errors; 
         \priority{3}{D}

   \item maintenance information or forms; \priority{3}{D}

   \item observing schedule; \priority{3}{D}

   \item observation program status information; \priority{3}{D}

   \end{reqlist}

\item There must be a selection mechanism integrated within tools to choose
between the various available data subsets such as:

   \begin{reqlist}

   \item source names, field names, id numbers, and user specified data 
         qualifiers (with wildcarding); \priority{1}{C}

   \item time (ranges); \priority{1}{C}

   \item baselines; \priority{1}{C}

   \item antennas; \priority{1}{C}

   \item polarization products or channels; \priority{1}{C}

   \item bands (frequency bands, IFs); \priority{1}{C}

   \item spectral channels; \priority{1}{C}

   \item u, v, w coordinates (e.g. uv radius range); \priority{1}{D}

   \item subarrays; \priority{2}{D}

   \item mosaic or scanning pointing centers (e.g. by position); 
         \priority{2}{D}

   \item WVR-corrected or uncorrected visibilities (if available); 
         \priority{2}{D}

   \end{reqlist}

\item For polarization products, transformation must be provided to the
desired Stokes output parameter(s). \priority{1}{D}

\item All standard time systems shall be supported, including:
\label{req:times} 

   \begin{reqlist}

   \item Universal Time (UT), also UT1; \priority{1}{C}

   \item Coordinated Universal Time (UTC); \priority{1}{C}

   \item International Atomic Time (IAT); \priority{1}{C}

   \item Local Sidereal Time (LST, at antenna or array center); \priority{1}{C}

   \item Julian Date (JD), also Modified Julian Date (MJD); \priority{1}{D}

   \item Greenwich Mean Sidereal Time (GMST); \priority{2}{D}

   \item Dynamical Times (TDT, TDB, ET Ephemeris Time); \priority{2}{D}

   \end{reqlist}

\item All standard coordinate systems shall be supported, including:
\label{req:coord}

   \begin{reqlist}

   \item equatorial (RA, DEC); \priority{1}{C}

   \item terrestrial (AZ, EL, at antenna or array center); \priority{1}{D}

   \item ecliptic (ELON, ELAT); \priority{2}{D}

   \item galactic (GLON, GLAT); \priority{2}{D}

   \item helioecliptic (HLON, HLAT); \priority{3}{D}

   \item supergalactic (SLON, SLAT); \priority{3}{D}

   \end{reqlist}

\item All standard coordinate reference frames and equinoxes
shall be supported, including:
\label{req:reframe}

   \begin{reqlist}

   \item J2000 (and other FK5 equinoxes); \priority{1}{C}

   \item B1950 (and other FK4 equinoxes); \priority{1}{C}

   \item 'Apparent Place': geocentric coordinates of date; \priority{1}{D}

   \item 'Local Place': topocentric coordinates of standard equinox;
         \priority{2}{D}

   \item 'Topocentric Place': topocentric coordinates of date;
         \priority{2}{D}

   \item International Celestial Reference System (ICRS) using the
         International Celestial Reference Frame (ICRF) extension to
         FK5;
         \priority{2}{D}

   \end{reqlist}

\item All standard velocity definitions shall be supported, including:
\label{req:veldef}

   \begin{reqlist}

   \item radio velocity; \priority{1}{C}

   \item optical velocity (and redshift); \priority{2}{D}

   \end{reqlist}

\item All standard velocity frames shall be supported, including:
\label{req:velframe}

   \begin{reqlist}

   \item topocentric; \priority{1}{C}

   \item geocentric; \priority{1}{C}

   \item barycentric; \priority{1}{C}

   \item kinematic LSR; \priority{1}{C}

   \item dynamic LSR; \priority{1}{D}

   \item heliocentric; \priority{3}{D}

   \item galactocentric; \priority{3}{D}

   \item local group; \priority{3}{D}

   \item with respect to a user-specified system of rest. \priority{3}{D}

   \end{reqlist}

\item Coordinates and locations (e.g.\ of the antennas, or the array center)
defined with respect to the standard frames shall be supported, including:
\label{req:posframe}

   \begin{reqlist}

   \item topocentric; \priority{1}{C}

   \item geocentric; \priority{1}{C}

   \item ITRF; \priority{3}{D}

   \end{reqlist}

\item Any existing flagging mask or table must be filled along with the data 
and be available for use in the Package.
\priority{1}{D}

   \begin{reqlist}

   \item The flagging mask or table must be maintained and associated
         with the data it refers to during any subsequent operations 
         (such as splitting of data sets). \priority{2}{D}

   \item The flagging mask or table shall be transferable to other equivalent
         data sets (e.g. flags derived for a continuum dataset should be
         transferable to a line dataset derived from the same
         observations). \priority{2}{D}

   \end{reqlist}

\item Merging (e.g.\ concatenation) and splitting of datasets shall 
supported:

   \begin{reqlist}

   \item Extraction of specified subsets of data (e.g.\ by source, time,
         band, subarray) shall be supported. \priority{1}{D}

   \item Merging and reinsertion of data subsets (e.g.\ combination of
         epochs, configurations, subarrays, frequency offsets, mosaic 
         pointings) shall be supported. \priority{1}{D}

   \item The merging and splitting process, including selection of data to be
         merged (e.g.\ merging of frequency channels which may be differently 
         labeled) shall be straightforward and not overly complex. 
         \priority{2}{D}

   \item The use of merged or split data in the Package shall be robust and
         transparent to the user.  Subsequent operations shall work the same,
         whether the data is in its original form or built from merged
         data subsets, where possible.
         \priority{2}{D}

   \item The tools shall be able to operate on multiple data objects,
         including multiple subsets of multiple objects, without
         explicit concatenation (ie. allow operations on unions of
         objects) seamlessly.
         \priority{3}{D}

   \item The appropriate calibration and ancillary monitoring
         data for the merged or split data (e.g.\ keeping only the data 
         relevant to sources split out) shall be preserved.
         \priority{3}{E}

   \end{reqlist}

\item Users shall have access to, and the ability to change, all
aspects of the data including the header. \priority{1}{D}

\item The Package must support locking data files so that there is no
possibility of one process corrupting a file that is also being written to by
another process in the Package. The default model should be: 
``one writer, multiple readers.'' \priority{1}{D}

\item Distinctions between ``single-source'', ``multi-source'', single-dish,
and interferometer datasets shall be avoided with context built into the
dataset or header. \priority{2}{D}

\end{reqlist}

\subsection{Data Examination} \label{sec:ol:dh:exam}

{\it Note: This section covers the non-graphical tools for looking at
the state of the data (graphical methods are in Visualization),
e.g. summaries of what physically is there in the data set
(AIPS LISTR type functions).}

\begin{reqlist}

\item The Package should provide easy access to, and printable output for,
summaries of the data set, including: 

   \begin{reqlist}

   \item header information (e.g.\ AIPS IMHEAD); 
         \priority{1}{C}

   \item source and field summaries (e.g.\ AIPS LISTR option SCAN); 
         \priority{1}{D}

   \item scan summaries (e.g.\ AIPS LISTR option SCAN); 
         \priority{1}{D}

   \item antenna locations (e.g.\ AIPS PRTAN);
         \priority{2}{D}

   \end{reqlist}

\item The User should be able to determine the current state of the
data set at any time in a straight forward manner, with printable 
output, including:

   \begin{reqlist}

   \item listings of calibration tables present (e.g.\ AIPS IMHEAD);
         \priority{1}{D}

   \item convenient listing of the visibility data as a function of time,
         with optional averaging (AIPS LISTR option LIST);
         \priority{1}{D}

   \item convenient listing of the calibration data for a specified
         calibration table as a function of time (AIPS LISTR option GAIN);
         \priority{1}{D}

   \item summary of ``columns'' present in a specified table of the
         dataset; \priority{2}{D}

   \item convenient listing of the contents of a specified column for
         a table of the data; \priority{2}{D}

   \item matrix-style listing of the data with time, and scan, averaging
         (AIPS LISTR option MATRIX). \priority{3}{D}

   \end{reqlist}

\item The User shall have access to the processing history of the dataset,
including:

   \begin{reqlist}

   \item The history must be displayable (e.g.\ on screen or in a browser),
         and printable.
         \priority{1}{D}

   \item The history must be searchable, with selection by task or function,
         date, or type of information desired.
         \priority{2}{D}

   \item The history must be exportable (both as tables and as plain text).
         \priority{3}{D}

   \end{reqlist}

\end{reqlist}

\subsection{Foreign Data}\label{sec:ol:dh:for}

\begin{reqlist}

\item Data produced by other interferometers and single dishes in similar
observing modes shall be importable and processable if provided in 
{\bf EVLA Archive data format} or an {\bf EVLA supported data format}
\priority{3}{E}

\item Imaging data in standard formats (e.g.\ FITS) from astronomical
instruments at different wavelengths shall be importable, with the ability to
combine (coadd) these with EVLA data where appropriate. This should be through
a set of widely used formats, with a {\bf minimal list of supported standards
established by the project}.
\priority{3}{E}

\end{reqlist}

\subsection{Interaction with the Archive}\label{sec:ol:dh:arc}

\begin{reqlist}

\item Access from the EVLA Archive (when such access is granted, e.g.\ when
Package is run by EVLA staff) must be supported.
\priority{2}{D}

\item The interface between the Package and archive must be able to provide
data access (when such access is granted) without interfering with other
access to the archive.
\priority{2}{D}

\item Security and integrity of the archive must be ensured during these
operations.
\priority{2}{D}

\end{reqlist}

\newpage

\section{Calibration and Editing}\label{sec:ol:cal}

\subsection{General Calibration and Editing Requirements}
\label{sec:ol:cal:gen}

{\it The view is that interactive data editing, calibration, and display of
calibration quantities shall be largely graphical and intuitive.  The
GUIs should be designed with this in mind.}

\begin{reqlist}

\item Quantities for general editing, calibration and display shall include:

   \begin{reqlist}

   \item data quantities including:

      \begin{reqlist}

      \item amplitude and phase; \priority{1}{C}

      \item real and imaginary; \priority{1}{D}

      \item phase delay and rate; \priority{3}{D}

      \item closure quantities; \priority{3}{D}

      \end{reqlist}

   \item specification of data by selection on observational parameters,
	 and/or plotting versus these parameters, including:

      \begin{reqlist}

      \item field name or id; \priority{1}{C}

      \item antenna; \priority{1}{C}

      \item baseline; \priority{1}{C}

      \item time range; \priority{1}{C}

      \item frequency band or IF; \priority{1}{C}

      \item frequency channel; \priority{1}{C}

      \item uv range; \priority{2}{D}

      \item position; \priority{2}{D}

      \item subarray; \priority{2}{D}

      \item azimuth, elevation; \priority{3}{D}

      \item hour angle range; \priority{3}{D}

      \item parallactic angle; \priority{3}{D}

      \end{reqlist}

   \item display of and selection on monitor data quantities (e.g.\ 
	$T_{atm}$, $T_{amb}$). \priority{3}{D}

   \end{reqlist}

\item Calibration, editing, flagging, and correction of data shall be easily
reversible within the Package (i.e.\ not requiring re-reading of the data from
the archive). 
\priority{2}{D}

\item Data calibration, correction and flagging shall be possible based upon
standard or user-defined models, including:

   \begin{reqlist}

   \item point source parameters (flux density and position); 
         \priority{1}{C}

   \item tabular form (e.g. point or Gaussian clean components); 
         \priority{1}{D}

   \item images; 
         \priority{1}{D}

   \item Gaussian source parameters (flux density, position, size); 
         \priority{2}{D}

   \item disk (e.g. planetary) models;
         \priority{2}{D}

   \item user-specified functions or scaling of data; 
         \priority{3}{D}

   \end{reqlist}

\end{reqlist}

\subsection{Flagging and Editing}
\label{sec:ol:cal:edit}

{\it In general, we use the word ``editing'' to describe interactive 
indication and excision of bad data based on visual inspection, and 
``flagging'' to refer to either automated excision or non-interactive
specification of proscribed data ranges (e.g. AIPS UVFLG).}

\begin{reqlist}

\item Editing and flagging shall be robust, accountable and non-destructive.

   \begin{reqlist}

   \item Editing and flagging shall not modify raw data unless requested
         specifically by the user. \priority{1}{C}

   \item Logging of editing steps will be clearly marked in a history table or
         data object (possibly distinct from a more readable history).
         \priority{2}{D}

   \item Individual edit undo is desirable. \priority{3}{E}

   \end{reqlist}

\item Editing display types shall include:

   \begin{reqlist}

   \item X-Y editing and display, e.g.\ quantity vs. time 
         on each baseline (e.g.\ Difmap vplot);
         \priority{1}{C}

   \item display as image, e.g.\ quantity vs. time-baseline 
         (e.g.\ AIPS TVFLG);
         \priority{1}{D}

   \item display as histogram, e.g.\ for setting of clipping levels;
         \priority{3}{D}

   \end{reqlist}

\item Control of the editing display shall include:

   \begin{reqlist}

   \item interactive zoom; 
         \priority{1}{D}

   \item auto-scaling and user-specified scaling of axes;
         \priority{2}{D}

   \item auto-scaled and user-specified colormap or greyscale;
         \priority{2}{D}

   \item inclusion and marking of flagged data in plots and in auto-scaling;
         \priority{2}{D}

   \end{reqlist}

\item There shall be provision for direct non-interactive editing of data
based user-specified ranges for the same quantities that are available for
plotting or editing in interactive mode;
\priority{1}{C}

\item In addition to direct display and editing of quantities, there shall
be the facility to edit based on processed versions of the data, including:

   \begin{reqlist}

   \item statistical quantities, including: 

      \begin{reqlist}

      \item a data point versus a running mean over a timescale or 
            spectral range; 
            \priority{2}{D}

      \item an rms scatter in a time or spectral range;
            \priority{2}{D}

      \end{reqlist}

   \item computed difference versus a model;
         \priority{2}{D}

   \item time, band and/or channel averaged versions of the data; 
         \priority{3}{D}

   \end{reqlist}

\item There shall be provision for automated editing with tunable criteria for
automated selection of parameter ranges, including:

   \begin{reqlist}

   \item amplitude of data (e.g. outside a prescribed range);
         \priority{2}{D}

   \item rms scatter of data in a time or spectral range;
         \priority{2}{D}

   \item deviation of data (amplitude or phase) versus a running mean over a
         timescale or spectral range; 
         \priority{2}{D}

   \item deviation of data (amplitude or phase) versus a running mean over a
         uv region; 
         \priority{2}{D}

   \item difference of data versus model;
         \priority{2}{D}

   \end{reqlist}

\item Data editing and flagging shall be possible based upon array,
environmental, astronomical, and calibration monitoring data, if available,
including:

   \begin{reqlist}

   \item $T_{sys}$ and/or $T_{ant}$ data; \priority{2}{D}

   \item WVR data; \priority{2}{D}

   \item pointing data (e.g. solution failure); \priority{2}{D}

   \item array tracking information; \priority{2}{D}

   \item RFI monitoring; \priority{3}{D}

   \item site-test interferometer (STI) or tipping radiometer; 
         \priority{3}{E}

   \item GPS or ionospheric monitor; 
         \priority{3}{E}

   \item weather data (wind speed, temperature, relative humidity, pressure);
         \priority{3}{E}

   \item array monitoring points (e.g.\ dewar temperatures);
         \priority{3}{E}

   \end{reqlist}

\item It shall be possible to expand the scope of the edits
to apply to other spectral channels, IFs, or polarizations.
\priority{2}{D}

\item Data display and editing shall be effected through generic tools
applicable to both single-dish and interferometer modes.  These shall,
as far as possible, present similar interfaces to the user and have
the same look-and-feel. 
\priority{3}{D}

\item Editing shall be incorporated into most visualization tools where data
or data-derived quantities are plotted, such as from calibration solutions,
amplitude vs. uv-distance plots, or any number of other plots.  A ``see-it,
flag-it'' capability shall be the standard within the tools.
\priority{3}{D}

\end{reqlist}

\subsection{Interferometer Calibration \& Self-Calibration}
\label{sec:ol:cal:int}

{\it Note: Antenna-based determination of calibration quantities such as gains,
polarization leakages, bandpasses, will be the primary form of calibration
where appropriate.  However, in  addition to antenna-based calibration,
baseline dependent corrections will be important in some cases.  
For example, coherence loss due to atmospheric phase
fluctuation depends on baseline length (this aspect will be more important at
higher frequencies) and must be taken into account if some of the WVR
corrections are discarded while others are applied.  Also, in general,
the bandpasses are baseline dependent and contain non-closing terms, though
these should be minimal for the EVLA if the observer does not over-integrate
the data.}

\begin{reqlist}

\item The Package must be able to handle reliably all {\bf designated EVLA
standard calibration modes}, possibly including but not exclusive to:

   \begin{reqlist}

   \item calibration transfer from standard sources (including planets);
         \priority{1}{C}
  
   \item fast-switching calibration transfer;
         \priority{1}{D}

    \item WVR data (offline); 
         \priority{2}{D}

   \item cal noise or pulse cal injection, if available; 
         \priority{3}{E}

   \end{reqlist}

\item Antenna-based determination of calibration quantities shall be
available, and are the default choice for calibration in tools where 
appropriate, for quantities including:

   \begin{reqlist}

   \item antenna gains;
         \priority{1}{C}

   \item antenna feed polarization leakages;
         \priority{1}{C}

   \item antenna-dependent bandpasses;
         \priority{1}{C}

   \end{reqlist}

\item Baseline dependent corrections shall be supported for quantities 
      including:

   \begin{reqlist}

   \item closure errors;
         \priority{2}{D}

   \item coherence loss;
         \priority{2}{D}

   \item baseline-dependent bandpasses;
         \priority{3}{D}

   \item WVR corrections to subsets of baselines;
         \priority{3}{D}

%   \item RFI mitigation;
%         \priority{3}{D}

   \end{reqlist}

\reqpri{1}

\item Calibration based on known calibration sources shall
      be implemented, including:

   \begin{reqlist}

   \item Recognition of standard calibration names (e.g.\ 3C286 and
         1331+305); \priority{1}{D}

   \item Standard parameterized flux density scales by observing
         epoch and frequency (e.g.\ Perley-Taylor, Baars) shall be 
         built-in to the Package; \priority{1}{D}

   \item Standard parameterized polarization parameters by observing
         epoch and frequency band shall be built-in to the
         Package; \priority{2}{D}

   \item Access to time history of calibration information (e.g.\ source
         catalogs containing flux density histories in an EVLA 
         Calibrator database) shall be built into
         calibration engines;  \priority{3}{D}

   \item Output of calibration procedures shall be exportable into similar
         structures for inclusion in a calibration archive. \priority{3}{D}

   \end{reqlist}

\item Calibration shall involve user-controllable selection of calibration
parameters, including:

   \begin{reqlist}

   \item pre-averaging and solution intervals; \priority{1}{C}

   \item interpolation of solutions, using:

      \begin{reqlist}

      \item two-point interpolation; \priority{1}{C}

      \item boxcar smoothing; \priority{1}{D}

      \item spline interpolation; \priority{2}{D}

      \item general polynomial interpolation. \priority{3}{D}

      \end{reqlist}

   \item weighting, based on:

      \begin{reqlist}

      \item visibility weights; \priority{1}{D}

      \item system or antenna temperature; \priority{2}{D}

      \end{reqlist}

   \end{reqlist}

\item Gain corrections will be made based on differences between observed and
modeled data quantities, possibly with iteration (e.g.\ self-calibration and
determination of gains using calibration sources).

\item There must be the facility to handle solution quality issues, including:

   \begin{reqlist}

   \item reporting of solution errors, SNR, and/or quality indicators;
         \priority{1}{C}

   \item ability to disregard or reject solutions failing to meet a quality
         threshold;
         \priority{1}{C}

   \item ability to disregard or reject solutions that are discrepant versus
         adjoining solutions;
         \priority{2}{D}

   \item ability to flag data affected by poor solutions.
         \priority{2}{D}

   \end{reqlist}

\item Calibration operations shall be carried out with sufficient precision
(as allowed by the circumstance) to acheive the required astrometric accuracy
(as specified by the EVLA project).
\priority{1}{D}

\item Data calibration operations shall take into account the scan
structure and switching scheme of the data.  The user shall be able
to request calibration solution intervals that correspond to and
reference from scan boundaries, for example.
\priority{2}{D}

\item Calibration quantities shall be transferable (e.g. between sources, 
frequency bands) when appropriate.
\priority{2}{D}

\item Determination of polarization calibration quantities such as leakage
(D-term or Jones matrix) and complex gain difference shall have 
the capability of performing full matrix calculations. 
\priority{2}{D}

\item The Package shall support the establishment and verification of the
relative calibration of the various component epochs, configurations or other
subsets for merged datasets.
\priority{3}{D}

\item Redundancy (e.g.\ same, similar, or crossing baselines) shall be used
wherever possible to increase accuracy of or to check calibration solutions.
Editing based on this comparison shall be possible.
\priority{3}{E}

\item Interferometric pointing, focus, baseline, and beam response fitting
shall be available in the Package as a supplement to the on-line calibration.
\priority{3}{E}

\item Solving for calibration solutions can be time consuming.  The
calibrator tool should provide run-time estimates to allow the user
advance warning if a process is likely to take more than 10 minutes.
The user should have the option to cancel the start of processing in
the time estimate is too long.   
\priority{3}{E}

\end{reqlist}

\subsection{Apriori Data Correction}

{\it Apriori correction of the data is based on data provided by, e.g., the
VLA online system or weather inputs.  To perform the calibration, AIPS++ must
be able to read and interpret ancillary data.}

\begin{reqlist}

\item Corrections to the data based on a priori known values shall be
possible, including:

   \begin{reqlist}

   \item antenna position errors; \priority{1}{C}

   \item antenna gain-elevation curves; \priority{1}{C}

   \item atmospheric optical depth with elevation. \priority{1}{C}

   \end{reqlist}

\item The Package shall be able to read VLA data obtained in special 
observing modes and be able to process this data, including:

   \begin{reqlist}
  
   \item baseline determination runs; \priority{2}{C}

   \item antenna gain-elevation determination runs; \priority{2}{D}

   \item beam mapping (including full polarization); \priority{2}{D}

   \item tipping scan data. \priority{3}{D}

   \item holography (including full polarization, tranform to surface errors,
         fitting of focus and subreflector terms); 
         \priority{3}{D}

   \end{reqlist}

\end{reqlist}

\subsection{Atmospheric and Ionospheric Calibration}\label{sec:ol:cal:atm}

\begin{reqlist}

\item Atmospheric and ionospheric modeling shall be available in the Package.  

   \begin{reqlist}

   \item {\bf The EVLA Project shall provide a standard model as used in the
         Pipeline processing of data which the package must support};
         \priority{1}{D}

   \item The package may have its own built-in models as an option; 
         \priority{3}{D}

   \item There shall be provision for the use of user-supplied models.
         \priority{3}{E}

   \end{reqlist}

\item The Package shall be able to predict the absorption,
emission and path length on the line of sight through the troposphere
at all EVLA bands using the model. The prediction will be based
on the following data:

   \begin{reqlist}

   \item measured atmospheric parameters at the site: temperature,
         pressure, humidity; \priority{1}{D}

   \item measured atmospheric emission in the observed EVLA bands
         (e.g. from radiometry using EVLA receivers); \priority{2}{D}

   \item data from EVLA taken in tipping mode; \priority{2}{D}

   \item data from site test interferometer or tipping radiometer
         (if available); \priority{3}{D}

   \item measured atmospheric profiles of temperature and water
         content if available from FTS, atmospheric sounders 
         or other devices; \priority{3}{E}

   \end{reqlist}

\item For EVLA bands affected by the troposphere, atmospheric modeling shall: 

   \begin{reqlist}

   \item derive the correction for absorption versus elevation; 
         \priority{1}{D}

   \item derive the system temperatures corrected for atmospheric absorption 
         as a function of elevations;
         \priority{2}{D}

   \item provide the conversion factors between WVR data and the water
         contribution to the astronomical phase.
         \priority{2}{D}

   \end{reqlist}

\item The Package shall be able to predict the electron content of the
ionosphere based on:

   \begin{reqlist}

   \item modeled electron content (e.g. from NASA);
         \priority{1}{D}

   \item data obtained on-site monitoring (e.g. GPS, if available).
         \priority{2}{D}

   \item measured electron content determined from multi-frequency 
         EVLA data (e.g.\ using rotation measures of calibrators);
         \priority{2}{D}

   \item ionospheric models from data (e.g.\ from phase curvature on
         long baselines);
         \priority{3}{D}

   \end{reqlist}

\item For EVLA bands affected by the ionosphere, the Package shall
      provide ionospheric modeling that will:

   \begin{reqlist}

   \item provide phase corrections in EVLA bands;
         \priority{1}{D}

   \item provide polarization corrections.
         \priority{3}{D}

   \end{reqlist}

\item The Package shall be able to estimate atmospheric optical depth at
various EVLA observing frequency bands based on:

   \begin{reqlist}

   \item measured system temperatures versus elevation; \priority{2}{D}

   \item measured atmospheric parameters at the VLA site (e.g. temperature,
         pressure, humidity); \priority{2}{D}

   \item tipping scan data; \priority{3}{D}

  \end{reqlist}

\end{reqlist}

\subsection{Mosaicing and Single Dish Considerations}\label{sec:ol:cal:mos}

{\it Although the EVLA itself is an interferometer and there are no
plans in the baseline to use the total power (e.g.\ to fill in the
short spacings), it is prudent to specify the integration of single-dish
observations in order to facilitate inclusion of GBT data.  This is
particularly true if E-configuration is built.  We are assuming that the
single dish calibration operations are dealt with in another set of
requirements (e.g. for GBT Post-processing).}

{\it For the EVLA, the mosaicing drivers are D-config plus GBT or
E-config.  There is some use in pure D-config VLA data, though the
small number of short spacings makes this a less critical area.}

\begin{reqlist}

\item Determination of and correction for pointing offsets and the 
polarized primary beam is critical to the ability to reliably mosaic using 
the EVLA, and thus must be available in the Package, preferably in several
algorithmic forms.
\priority{2}{D}

\item Careful cross calibration of the flux scales between the EVLA
interferometric data and single dish data is required for high fidelity
imaging.  There must be tools to cross-check and correct the relative
calibration between mosaics and different component observations. 
\priority{2}{D}

\item De-striping and adjustment of scan normalization factors must
be available for single-dish OTF observations with overlapping and crossing
scans.
\priority{2}{D}

\end{reqlist}

\subsection{Wide-Field Considerations}\label{sec:ol:cal:wf}

{\it A significant difference between ALMA and the EVLA is the driving
need to accomodate wide-field imaging.  We will need to come up with
a set of comprehensive requirements here.}

\begin{reqlist}

\item Provision shall be made for 3-D imaging taking into account the
$w$-term in calibration operations.
\priority{1}{C}

\end{reqlist}

\newpage

\section{Imaging}\label{sec:ol:im}

\subsection{EVLA Interferometric Imaging Requirements}\label{sec:ol:im:evla}

{\it Because the EVLA WIDAR correlator provides data in multiple channels, 
spectral cube mapping shall be built in as the primary mode from the
beginning. Also, due to the high volume of data that can be produced by the 
EVLA, it is imperative that the imaging and deconvolution tools in the Package
be user-friendly, efficient, and flexible.  This is the workhorse of
the Package as far as most users will be concerned, and suitability
and success of the Package will be judged with this in mind.}

\begin{reqlist}

\item Imaging of data taken from any combination of EVLA exported data, the
EVLA archive, or other instruments supporting common export formats must be
provided. {\bf A list of supported data and formats will be maintained
by the project.}
\priority{1}{C}

\item Provision must be made for the utilization and development of a variety
of imaging, deconvolution, and analysis algorithms, including:

   \begin{reqlist}

   \item raw (``dirty'') images with selectable weighting 
         (natural, uniform, Briggs robust); \priority{1}{C}

   \item residual images after model subtraction; \priority{1}{C}

   \item single-scale CLEAN (Hogbom, Clark, Cotton-Schwab); \priority{1}{C}

   \item maximum entropy method (MEM); \priority{1}{D}

   \item multi-scale CLEAN; \priority{2}{D}

   \item modelfitting (point, Gaussian, disk); \priority{2}{D}

   \item linear mosaics; \priority{2}{D}

   \item joint deconvolution of mosaics with single-scale CLEAN; 
         \priority{2}{D}

   \item joint deconvolution of mosaics with MEM; 
         \priority{2}{D}

   \item non-negative least-squares (NNLS); \priority{2}{D}

   \item multi-frequency synthesis with different spectral models; 
         \priority{2}{D}

   \item joint deconvolution of mosaics with multi-scale CLEAN; 
         \priority{3}{D}

   \item special function deconvolution (Pixon, wavelet); \priority{3}{E}

%   \item non-linear mosaics; \priority{3}{D}

   \end{reqlist}

\item Selection of paramaters for user control of imaging must be provided,
including:

   \begin{reqlist}

   \item field or source names or ids; \priority{1}{C}

   \item image pixel (cell) size; \priority{1}{C}

   \item image size; \priority{1}{C}

   \item frequency bands or IFs; \priority{1}{C}

   \item spectral channels (including ones to average as MFS); 
         \priority{1}{C}

   \item imaging weights, including:

      \begin{reqlist}

      \item natural weighting; \priority{1}{C}

      \item uniform weighing (with grid cell control); \priority{1}{C}

      \item robust (Briggs) weighting; \priority{1}{D}

      \item uv tapering (Gaussian); \priority{1}{D}

      \item user-supplied weighting functions; \priority{3}{E}

      \end{reqlist}

   \item deconvolution step control (e.g. CLEAN GAIN); \priority{1}{C}

   \item deconvolution stopping criteria (e.g. NITER, threshold); 
         \priority{1}{C}

   \item choice of FFT or DFT imaging (e.g. for small datasets);
         \priority{2}{D}

   \end{reqlist}

\item Image pixel and spectral channel blanking must be supported, including:
 
   \begin{reqlist}

   \item non-interactive specification of mask regions;
         \priority{1}{C}

   \item interactive graphical selection of blanking masks;
         \priority{1}{D}

   \item user control of the scope of mask (e.g. change channel ranges);
         \priority{2}{D}

   \item transfer of masks from different equivalent images;
         \priority{2}{D}

   \end{reqlist}

\item Deconvolution region boxing or region masking shall be available, 
      including:
 
   \begin{reqlist}

   \item non-interactive specification of mask regions;
         \priority{1}{C}

   \item interactive graphical selection of blanking masks;
         \priority{1}{D}

   \item user control of the scope of mask (e.g. change channel ranges);
         \priority{2}{D}

   \item transfer of masks from different equivalent images;
         \priority{2}{D}

   \end{reqlist}

\item Subtraction of continuum level (or equivalently spectral baselines)
from spectral data is required, including:

   \begin{reqlist}

   \item image plane subtraction using a (fitted or supplied) image; 
         \priority{1}{C}

   \item $uv$-plane subtraction using a model; \priority{1}{C}

   \item $uv$-plane subtraction using a fitted continuum baseline; 
         \priority{1}{C}

   \item flexible (interactive and specified at the CLI level) setting of the
         frequency channel ranges for the calculation of the continuum level; 
         \priority{2}{D}

   \item parameterized baseline fitting using standard functions
         (e.g.\ polynomial, spline); \priority{2}{D}
 
   \item flagging based on deviations found during baseline fitting; 
         \priority{3}{D}
 
   \end{reqlist}

\item There must be the ability to include ``zero-spacing'' values and
short-spacing data, including:

   \begin{reqlist}

   \item ``zero-spacing'' flux density (e.g. IQUV); \priority{1}{C}

   \item short spacing data transformed from an image, with selectable
         weighting; \priority{2}{D}
 
   \end{reqlist}

\item Imaging of direct polarization products (e.g.\ RR, RL, LR, LL) or
Stokes polarization states (e.g.\ I, Q, U, V) must be selectable and
interchangeable where possible given the data. 
\priority{1}{D}

\item There must be straightforward and seamless integration of data from
multiple epochs and configurations. 
\priority{2}{D}

\item Imaging and deconvolution parameters and interpolation shall be
selectable based on desired image criteria (e.g.\ field-of-view, accuracy)
\priority{2}{D}

\item Interactive control of the deconvolution process shall be possible,
including stopping cleaning at any time, prolonging the cleaning after
the maximum number of iterations is reached, and continuing to clean
down to a specified threshold with out changing the clean mask.  
\priority{2}{D}

\item Images made on different coordinate systems (e.g.\ \ref{req:coord}),
equinoxes (e.g.\ \ref{req:reframe}), or projections (e.g.\ \ref{req:project}) 
shall be transformed, merged and compared appropriately. 
\priority{2}{D}

\item Image cubes using different velocity definitions (e.g.\ \ref{req:veldef})
and velocity frames (e.g.\ \ref{req:velframe}) shall be transformed and merged 
correctly.
\priority{2}{D}

\item An integrated deconvolution, self-calibration, and editing/filtering
tool shall be available, especially for novice users with data taken in
commonly used modes.
\priority{2}{D}

\item Multiple input datasets shall be supported directly in the tools,  
rather than requiring previous concatenation of the data. 
\priority{3}{E}

\item There shall be the provision for the near-field imaging of solar-system
objects.  This can be done through the introduction of phase corrections based
upon the sphericity of the incoming wave front. {\it (Note: this capability is
in the online system and would presumably be mostly used there.)}
\priority{3}{D}

\item Imaging is often time consuming, the imaging tool should provide
run-time estimates to allow the user advance warning if a process is
likely to take more than 10 minutes.  The user should have the option to
cancel the start of processing if the time estimate is too long.
\priority{3}{D}

\end{reqlist}

\subsection{Wide-Field Imaging Considerations}
\label{sec:ol:im:wf}

{\it Significant parts of EVLA science, particularly at low frequencies,
will require wide-field, multi-faceted imaging that is straightforward to set
up and run.}

\begin{reqlist}

\item The imaging tools shall allow the option for the mitigation of 
the effects of non-coplanar baselines and sky curvature.
\reqpri{1}

\item Wide-field, multi-faceted imaging must be available in the Package,
including:

   \begin{reqlist}

   \item It shall be possible to set up a central region of
	 specified size which is imaged, e.g. the ``fly's eye'').
	 \priority{1}{D}

   \item Facet positions shall be chosen by the package based on
         user-specified imaging criteria.
	 \priority{1}{D}

   \item It shall be possible to stitch together all of the
         facets to form a single final image.
	 \priority{1}{D}

   \item It shall be possible to specify "outrigger" facets,
         either manually, or by reading in information from a catalog
         (e.g., NVSS, WENSS, etc...), or from multiple catalogs for 
         frequency interpolation, and specifying facets at the locations
         of sources above a given flux density cutoff (accounting for
         the primary beam response). 
         \priority{3}{D}

   \end{reqlist}

\item High-fidelity imaging of the entire primary beam in all Stokes
parameters is the primary goal --- therefore, incorporation of the polarized
primary beam response of the array is required, including: 

   \begin{reqlist}

   \item ability to image polarizations separately and correct for 
         beam squint; \priority{1}{D}

   \item inclusion of beam-squint between the R and L response in the
         primary beam for joint polarization imaging; 
         \priority{2}{D}

   \item inclusion of a full polarization response of the primary beam;
         \priority{3}{D}

   \end{reqlist}

\item It shall be possible to subtract the contribution of 
strong sources in the far sidelobes of the primary beam from the 
$uv$ data, accounting for a time variable primary beam response.
\priority{2}{D}

\item The package should know the location and sky brightness
structure of the strongest low frequency sources ($>$ 100 Jy).
\priority{3}{D}

\item It should be possible to derive variable source
differential refraction effects across the primary beam, and account
for them properly in imaging.  (this is a technique
for imaging when the isoplanatic patch is small, via fitting a
zernike polynomial across the primary beam for source location.)
\priority{3}{D}

\end{reqlist}

\subsection{Mosaicing and Single Dish Imaging Considerations}
\label{sec:ol:im:mos}

\begin{reqlist}

\item GBT data must be integrally supported by the Package and there
must be a straightforward way to combine GBT and VLA data, with selectable 
weighting, including:

   \begin{reqlist}

   \item image plane combination (e.g.\ feathering); \priority{2}{D}

   \item $uv$ plane combination and joint deconvolution; \priority{2}{D}

   \end{reqlist}

\item Careful (polarized) primary beam correction and pointing correction is
critical for high fidelity mosaic imaging and must be incorporated into the
mosaicing algorithms, including:

   \begin{reqlist}

   \item The primary beam calculation and correction must take into 
	 account the effect of on-the-fly scanning. \priority{2}{D}

   \item A set of {\bf EVLA standard beam parameters} will be made available
         by the project and distributed with the Package, with updates
	 available for download when appropriate. \priority{2}{D}

   \item A set of {\bf EVLA standard beam images} will be made available
         by the project and distributed with the Package, with updates
	 available for download when appropriate. \priority{3}{E}

   \item The user shall be able to specify the primary beam in a
	 number of forms, both analytic and tabular, in addition
	 to the EVLA provided primary beam. \priority{3}{E}

   \end{reqlist}

\item Careful cross calibration of the flux scales between VLA
interferometric data and single dish data is required for high
fidelity imaging.  There must be tools to cross-check and correct
the relative calibration between mosaics and different component
observations (e.g. de-striping of scans).
\priority{2}{D}

\item The Package must be able to produce an image by combining data observed
on different rasters, possibly taken with different (regular or irregular)
spacings and image centers.
\priority{3}{E}

\item Pointing corrections (e.g.\ as determined by optical cameras or through
monitoring data) shall be applicable to the data during imaging.
\priority{3}{E}

\end{reqlist}

\subsection{High Dynamic Range Imaging Considerations}
\label{sec:ol:im:hdr}

{\it High fidelity imaging will be a driver for much of new EVLA science.
This will be at $10^7$ dynamic range or better!  It is clear that significant
algorithm development will have to occur in this area, regardless of what
package is used.}

\begin{reqlist}

\item The Package must support imaging up to the levels specified in the
EVLA top-level requirements, including:

   \begin{reqlist}

   \item moderate dynamic range ($10^4$) imaging. \priority{1}{C}

   \item high dynamic range ($10^7$) imaging. \priority{1}{D}

   \end{reqlist}

\item High dynamic range imaging shall be supported in all the EVLA modes,
including:

   \begin{reqlist}

   \item single-field imaging within the half-power point of the primary
         beam, in Stokes IQU; \priority{1}{C}

   \item full primary beam, single-field imaging, in Stokes IQU;
         \priority{1}{D}

   \item multi-field mosaicing, in Stokes IQU;
         \priority{2}{D}

   \item in Stokes V (for moderate dynamic range only);
         \priority{3}{D}

   \end{reqlist}

\item The dynamic range in the image shall not be limited by the
presence of bright sources:

   \begin{reqlist}

   \item within the half-power point of the primary beam; \priority{1}{C}

   \item within the first null of the primary beam; \priority{1}{D}

   \item within the near sidelobes of the primary beam; \priority{2}{D}

   \item anywhere on the sky; \priority{3}{D}

   \end{reqlist}

\item The dynamic range levels shall be met at all EVLA bands, weather and
ionosphere permitting, for frequencies:

   \begin{reqlist}

   \item from 2 GHz to 18 GHz; \priority{1}{C}

   \item above 18 GHz; \priority{1}{D}

   \item below 2 GHz; \priority{2}{D}

   \end{reqlist}

\end{reqlist}

\subsection{Wide Bandwidth Imaging Considerations}
\label{sec:ol:im:mfs}

{\it The large bandwidths available in EVLA will necessitate improvements in 
Multi-Frequency Synthesis and wide-band imaging capability.  Again, this will
be a critical area for algorithm development.}

\begin{reqlist}

\item The Package must support wide bandwidth imaging.  The package shall
be able to process the widest ELVA bandwidths, where the appropriate
channelizations are provided by the correlator, including:

   \begin{reqlist}

   \item single-field imaging within the half-power point of the primary
         beam, at moderate dynamic range ($10^4$);
         \priority{1}{C}

   \item full primary beam, single-field imaging, in all polarizations, with
         moderate dynamic range ($10^4$);
         \priority{1}{D}

   \item high dynamic range ($10^7$); 
         \priority{2}{D}

   \item multi-field mosaicing; 
         \priority{2}{D}

   \end{reqlist}

\item Multi-frequency synthesis (MFS) imaging capability shall be available,
including the choice of:

   \begin{reqlist}

   \item independent uv gridding of data from multiple frequency channels
         within a spectral bands or windows (to avoid bandwidth smearing);
         \priority{1}{C}

   \item gridding weights derived from an assumed (overall) spectral index; 
         \priority{1}{C}

   \item uv gridding of data from multiple frequency channels from different
         spectral bands or windows; 
         \priority{1}{D}

   \item joint solution for the (polarized) intensity and spectral index in
         the image;
         \priority{2}{D}

   \end{reqlist}

\item Wide-bandwidth imaging shall be possible at all EVLA bands, for 
frequencies:

   \begin{reqlist}

   \item above 8 GHz; \priority{1}{C}

   \item from 2 GHz to 8 GHz; \priority{1}{D}

   \item below 2 GHz; \priority{2}{D}

   \end{reqlist}

\end{reqlist}

\newpage

\section{Data Analysis}\label{sec:ol:an}

\subsection{General Analysis Requirements}\label{sec:ol:an:gen}

\begin{reqlist}

\item Fitting based on goodness-of-fit shall include:

   \begin{reqlist}

   \item Variances of, and covariances between each pair of, fit parameters
	 shall be reported.  \priority{1}{C}

   \item Results should be reported to appropriate precision (e.g. 
         based on the covariances). \priority{2}{D}

   \end{reqlist}

\item Transparent translation between various astronomical quantities and
units in images, spectra, and data shall be available, including:

   \begin{reqlist}

   \item flux density --- Jy, mJy, $\mu$Jy, mag;
         \priority{3}{D}

   \item temperature --- K, mK (Rayleigh-Jeans, Planck);
         \priority{3}{D}

   \item surface brightness --- Jy/beam, Jy/sr, MJy/sr, mag/arcsec$^{2}$;
         \priority{3}{D}

   \item frequency --- Hz, MHz, GHz, cm$^{-1}$ (wave number);
         \priority{3}{D}

   \item velocity --- km/s, m/s, $z$ (redshift);
         \priority{3}{D}

   \item wavelength --- m, cm, mm;
         \priority{3}{D}

   \end{reqlist}

\end{reqlist}

\subsection{Spectral Line Analysis}\label{sec:ol:an:spec}

{\it Given the capabilities of the EVLA WIDAR correlator, the ease and
flexibility of spectral line analysis is likely to be a driver for the
Package.  Automatic and user-controlled fitting routines will need to be
included.  Note that there is necessarily some overlap with the image cube
analysis, but here we concentrate on issues relevant to traditional 1-D
spectra.} 

\begin{reqlist}

\item Spectral baseline removal facility is required, including:

   \begin{reqlist}

   \item Polynomial baseline fitting shall be supported. \priority{1}{C}

   \item Baseline fitting using other functions (e.g.\ sinusoids)
         shall be supported. \priority{3}{D}

   \end{reqlist}

\item Measurement of spectral line parameters shall be available, with
control of:

   \begin{reqlist}

   \item velocity or frequency windowing region; \priority{1}{C}

   \item starting guess at center and width; \priority{1}{C}

   \item number of lines to fit; \priority{1}{C}

   \item profile (function) to fit; \priority{1}{D}

   \item spacing for multiple lines; \priority{2}{D}

   \end{reqlist}

\item Available line fitting parameters and profiles shall include:

   \begin{reqlist}

   \item Gaussian line parameters (central and integrated intensity, 
         line width, line center) for single or multiple lines;
         \priority{1}{C}

   \item damping profiles (e.g.\ Voigt). \priority{2}{D}

   \end{reqlist}

\item Measurement of spectral line parameters shall be:

   \begin{reqlist}

   \item user-controlled by parameter list; \priority{1}{C}

   \item user-controlled by interactive GUI; \priority{1}{D}

   \item automatic. \priority{2}{D}

   \end{reqlist}

\item A set of standard line catalogs shall be distributed with the Package.
\priority{1}{D}

   \begin{reqlist}

   \item Updates shall be available and installable. \priority{2}{D}

   \item Updates shall be installable by a user from within the package
         (ie. without recompiling or root permission) via download. 
         \priority{3}{E}

   \item User importable line catalogs shall be supported by the Package
         as an ASCII table. \priority{3}{E}

   \end{reqlist}

\item The reporting of spectral line fitting results shall include:

   \begin{reqlist}

   \item Reporting of fit results in a logger or terminal window.
         \priority{1}{D}

   \item Export of publication quality postscript format of spectral line
         profiles.  The user should be able to choose data,
         fitting profiles, axis scaling, and annotations. 
         \priority{3}{E}

   \item Export of fit results in ASCII-format to a datafile. 
         \priority{3}{E}

   \end{reqlist}

\end{reqlist}

\subsection{Visibility or $uv$ Analysis}\label{sec:ol:an:uv}

\begin{reqlist}

\item Models shall be available to fit to the uv data, including: 

   \begin{reqlist}

   \item point source; \priority{1}{C}

   \item Gaussian (circular or elliptical); \priority{1}{D}

   \item limb-darkened disk (circular or elliptical); \priority{2}{D} 
 
   \item Optically thin sphere; \priority{2}{D}

   \item ring; \priority{3}{D}

   \item cone. \priority{3}{D}  

   \end{reqlist}

\item Fitting tools should have the ability to vary or hold constant any
of the model parameters.
\priority{2}{D}

\item Models components shall be able to be combined (mix and match) into a 
more complex model.
\priority{2}{D}

\item It shall be possible to Fourier transform images to the uv domains
for overlay/interpolation onto the visibilties. 
\priority{2}{D}

\item It shall be possible to derive visibility (amplitude \& phase,
real \& imaginary) statistics (mean, rms), with data selection as function of
baseline, channel, polarization, time.
\priority{2}{D}

\item It shall be possible to import an image of a structure (model) and
then fit for the intensity and position scale (offset). 
\priority{3}{D}

\end{reqlist}

\subsection{Image Cube Manipulation}\label{sec:ol:an:manip}

{\it Because the EVLA is inherently a multi-channel instrument, and due to
the design of the WIDAR correlator, spectral image cube can be considered
to be the fundamental image structure.  Single-channel or continuum images
can be considered as subsets or instances of cubes. Note that the ability to 
pull lower-dimensional structures from larger-dimensional cubes is 
especially important. }

\begin{reqlist}

\item The Package shall support the construction and analysis of image
cubes with a variety of axis choices, including:

   \begin{reqlist}

   \item position (e.g.\ \ref{req:coord} or general X,Y); 
         \priority{1}{D}

   \item channel (frequency, velocity, channel number, band, IF); 
         \priority{1}{D}

   \item polarization;
         \priority{1}{D}

   \item time (e.g.\ \ref{req:times}); 
         \priority{2}{D}

   \item Fourier (u,v); 
         \priority{3}{D}

   \end{reqlist}

\item The ability to extract same or lower-dimensional structures from	
higher-dimensional data cubes efficiently is required:

   \begin{reqlist}

   \item Extraction of ``cubical'' (rectangular) sub-structures aligned 
         with the original cube axes must be straightforward.
         \priority{1}{D}

   \item User-selectable sub-structures with arbitrary orientation
	 within the parent cube, with appropriate transformation 
	 or interpolation, shall be possible.
         \priority{2}{D}

   \item Extraction of data structures based on standard database
         (e.g.\ SQL) queries shall be available.
         \priority{3}{D}

   \end{reqlist}

\item The Package must have the capability of assembling lower-dimensional
data structures into higher-dimension cubes, including:

   \begin{reqlist}

   \item stacking of equally spaced planes (structures) into a cube along
         a third dimension;
         \priority{1}{D}

   \item assembly of non-equally spaced planes;
         \priority{3}{D}

   \end{reqlist}

\item There must be the facility for creating, manipulating, and maintaining
multi-dimensional  pixel masks and regions for blanking and selection
(e.g.\ for further processing) including:

   \begin{reqlist}

   \item It shall be possible to set masking regions by specification of
         boundaries or axes ranges (e.g. by corners of a rectangle
         BLC, TRC); \priority{1}{D}

   \item Interactive (graphical) facilities for setting of regions
	 shall be provided;
         \priority{2}{D}

   \item It shall be possible to mask based on values in another (homologous)
         cube; \priority{2}{D}

   \item Operations on two regions must sensibly obey masking (e.g.\ 
         blank if either is masked for a spectral index, use the unmasked
         value for a scalar sum); \priority{2}{D}

   \item Interpolation across blanked or masked regions (e.g.\ filling
         in blanked regions) shall be possible; \priority{2}{D}

   \item Automatic facilities for setting of masking parameters based
         on image properties (e.g.\ clipping pixels above a threshold,
         contour following) shall be provided;
         \priority{3}{D}

   \item Blanking shall not be destructive, and the original pixel
         value is retained by default(if defined); \priority{3}{D}

   \item It must be possible to turn on and off different blanking
         (mask) levels, when blanking is set within the Package.
         \priority{3}{D}

   \end{reqlist}

\item The transposition of cube axes shall be possible and straightforward,
including:

   \begin{reqlist}

   \item Basic cube rotation operations shall be available, for rotation axes
         aligned with the cube axes. \priority{2}{D}

   \item Rotation about axes not orthogonal to cube faces shall be
         possible. \priority{3}{E}

   \end{reqlist}

\subsection{Image Cube Analysis}\label{sec:ol:an:im}

\item Multidimensional baseline removal facility, along spectral and/or scan
directions, is required including:

   \begin{reqlist}

   \item Single-dimensional polynomial baseline fitting shall be supported
         (e.g. along a scan direction). \priority{1}{D}

   \item Two-dimensional polynomial baseline fitting shall be supported
         (e.g. flat-fielding). \priority{2}{D}

   \item Polynomial baseline (3D+) fitting shall be supported. \priority{3}{D}

   \item Baseline fitting based on image statistics (e.g.\
         median filtering) shall be supported. \priority{3}{D}

   \item Baseline fitting using other functions (e.g.\ sinusoids)
         shall be supported. \priority{3}{D}

   \end{reqlist}

\item The ability to collapse or integrate over sub-dimensions
of data cubes in order to form a ``moment'' image is required.  

   \begin{reqlist}

   \item This shall be possible along any direction(s) in the cube aligned
         with the axes. \priority{1}{D}

   \item This shall include the sum (zero-moment). \priority{1}{D}

   \item This shall include the first and second moments. \priority{2}{D}

   \item This shall include arbitrary (third and higher) moments. 
         \priority{3}{D}

   \item Moments along arbitrary user-specified directions in the
         cube shall be possible. \priority{3}{E}

   \end{reqlist}

\item Identification and reporting of image features (e.g.\ as determined in
processing operations) shall be available, and interactive (where
appropriate). Features shall include: 

   \begin{reqlist}

   \item output in pixel coordinates (e.g.\ row, column);
         \priority{1}{D}

   \item output in world coordinates (e.g.\ RA, Dec, Vel);
         \priority{1}{D}

   \item convertible to other supported coordinate systems
         (e.g.\ precessed to B1950);
         \priority{2}{D}

   \item exportable (e.g.\ as an ASCII file);
         \priority{3}{D}

   \end{reqlist}

\item Unary arithmetical operations on image cube values shall be possible,
including: 

   \begin{reqlist}

   \item the addition of a uniform level; \priority{1}{D}

   \item multiplicative scaling; \priority{1}{D}

   \item logarithm (natural and base ten); \priority{3}{D}

   \item exponential; \priority{3}{D}

   \end{reqlist}

\item Scalar arithmetic between cubes or different regions (e.g. planes)
of the same or different cube shall be possible, including:

   \begin{reqlist}

   \item sum and/or difference); \priority{1}{D}

   \item product and/or division); \priority{1}{D}

   \item spectral index; \priority{2}{D}

   \end{reqlist}

\item Construction and comparison of polarization quantities in the cube
shall be available, including:

   \begin{reqlist}

   \item polarization (E) vector at each cube pixel; \priority{1}{D}

   \item rotation measure between different frequencies; \priority{2}{D}

   \end{reqlist}

\item It shall be possible to fit models, shapes, profiles and functions over
regions of a cube, including:

   \begin{reqlist}

   \item polynomials; \priority{1}{D}

   \item elliptical Gaussian components; \priority{1}{D}

   \item uniform (multi-dimensional) spheroids; \priority{2}{D}

   \item Fourier modes (sinusoids); \priority{2}{D}

   \item Lorentzian profiles; \priority{3}{D}

   \item ``optically thin'' (multi-dimensional) spheroids; \priority{3}{D}

   \item exponential profiles; \priority{3}{D}

   \item trigonometric functions; \priority{3}{E}

   \end{reqlist}

\item It shall be possible to calculate statistical quantities over a defined
region, including: 

   \begin{reqlist}

   \item maximum and/or minimum); \priority{1}{D}

   \item mean; \priority{1}{D}

   \item rms; \priority{1}{D}

   \item standard deviation from mean; \priority{1}{D}

   \item median; \priority{2}{D}

   \item higher order statistics (skew, kurtosis, etc.); \priority{3}{E}

   \end{reqlist}

\item Smoothing and convolution (filtering) shall be available, with kernels
including: 

   \begin{reqlist}

   \item Uniform (box-car or top-hat) kernel; \priority{1}{D}

   \item Elliptical Gaussian kernel; \priority{1}{D}

   \item Symmetric polynomial; \priority{2}{D}

   \item User-supplied kernel; \reqpri{3}

   \end{reqlist}

\item Fourier and correlation operations on cube or cubical sub-regions shall
be available, including:

   \begin{reqlist}

   \item Fourier transform; \priority{2}{D}

   \item autocorrelation; \priority{3}{E}

   \item structure function; \priority{3}{E}

   \item power spectrum; \priority{3}{E}

   \end{reqlist}

\item Arithmetic between cubes of vectors (e.g.\ polarization vector
images) shall be possible, including: 

   \begin{reqlist}

   \item vector sum and difference; \priority{2}{D}

   \item dot product; \priority{3}{D}

   \end{reqlist}

\item Cube deconvolution (over frequency and spatial axes) 
shall be available, including:

   \begin{reqlist}

   \item Clean-based deconvolution; \priority{2}{D}

   \item Pixon-based deconvolution; \priority{3}{D}

   \item Wavelet-based deconvolution; \priority{3}{D}

   \end{reqlist}

\item Resampling of the cube (e.g.\ at lower temporal or spectral resolution)
shall be possible after processing. 
\priority{3}{D}

\item The use of user-defined functions in cube operations
shall be supported.  Ideally, these would be used
transparently in the tools the same as built-in functions.
\priority{3}{E}

\item There shall be the capability to manipulate data
cubes as general data structures, so that arithmetical and logical
operations can be applied as object methods.
\priority{3}{E}

\end{reqlist}

\newpage

\section{Visualization}\label{sec:ol:vis}

{\it This is intended as the purely graphical part of data analysis.
There is by necessity some overlap with the functionality discussed
under Data Analysis, particularly that for image cube manipulation,
and it would in fact be ideal if visualization and analysis were so
closely integrated that there were no effective difference.
The intention here is that the user is not only able to display
pre-calculated images (processed using tools from the Data Analysis
suite), but also has the capability of doing some processing and
display on-the-fly as an integral part of the visualization.}

\subsection{General Visualization and Plotting Requirements}
\label{sec:ol:vis:gen}

\begin{reqlist}

\item Standard type of plots must be supported, such as:

   \begin{reqlist}

   \item X-Y plots; \priority{1}{C}

   \item 2D raster images, including:

      \begin{reqlist}

      \item greyscale; \priority{1}{C}

      \item color-mapped RGB; \priority{1}{C}

      \item color-mapped HSV; \priority{3}{D}

      \item CMYK color (for hardcopy); \priority{3}{E}

      \end{reqlist}

   \item contour plots; \priority{1}{D}

   \item vector plots; \priority{1}{D}

   \item histograms; \priority{2}{D}

   \item rendered 3D surfaces; \priority{3}{D}

   \item wireframe 3D surfaces; \priority{3}{E}

   \end{reqlist}

\item ``Blinking'' between two different must be possible, including:  

   \begin{reqlist}

   \item blinking between two homologous images; \priority{1}{D}

   \item setting of the relative transfer functions of the two images
         (e.g.\ with a split screen); \priority{1}{D}

   \item blinking between homologous regions of the same image (e.g.
         two planes of a cube); 
         \priority{2}{D}

   \item blinking between homologous regions of two images; 
         \priority{2}{D}

   \end{reqlist}

\item Stepping (e.g.\ animation) through a set of channels (for an image
cube) or plots (e.g.\ by antenna or baseline for XY plots), must be possible,
including:

   \begin{reqlist}

   \item selection of animation axis; \priority{1}{C}

   \item manual stepping; \priority{1}{C}

   \item animation control of starting and stopping (e.g.\ tape-deck
         functions); \priority{1}{D}

   \item animation at a user-selected rate; \priority{1}{D}

   \item user-selection of the step ranges and increment; \priority{2}{D}

   \item setting of the relative transfer functions of the planes; 
         \priority{3}{D}

   \item user-selection of the animation order (e.g.\ through lists); 
         \priority{3}{D}

   \end{reqlist}

\item Standard plotting formats shall be supported, including:

   \begin{reqlist}

   \item Standard display (e.g.\ X window);

   \item There must be at least one designated standard ``hardcopy''
         output format (e.g.\ postscript) that can be converted by 
         the user to a variety of formats using easily obtainable tools. 
         \priority{1}{D}

   \item The Package shall also support the output of a 
	 variety of commonly used formats such as FITS, PDF,
	 GIF and/or JPEG.
         \priority{3}{D}

   \end{reqlist}

\item Identification of cursor position (if you ``see-it'' you should be able
to figure out where it came from) shall be available for interactive
plots, including:

   \begin{reqlist}

   \item reporting in plotter window; \priority{1}{D}

   \item reporting in logger or shell window; \priority{2}{D}

   \item Where appropriate, this information shall be recordable and
         exportable (e.g.\ to a formatted ASCII file). 
         \priority{3}{D}

   \end{reqlist}

\item An extra ``axis'' of information shall be encodable on the
standard plot types using color and/or intensity.
\priority{3}{D}

\end{reqlist}

\subsection{Display Appearance and Interactivity}\label{sec:ol:vis:dis}

\begin{reqlist}

\item Plot selection parameters (axes, limits, colormap) shall be conveniently
controllable (e.g.\ via buttons or easily accessible menus).
\priority{1}{C}

\item User should have full control over the transfer function and plot
line styles, including:

   \begin{reqlist}

   \item choice of linear or logarithmic amplitude and intensity scales; 
         \priority{1}{C}

   \item selection, from menu, of transfer function and colormap (for images);
         \priority{1}{C}

   \item control of line width and style (for XY plots);
         \priority{1}{C}

   \item import and export of color maps or functions; 
         \priority{3}{D}

   \item user editable or definable color maps or functions. 
         \priority{3}{E}

   \end{reqlist}

\item There shall be interactive display zooming and unzooming capability
within plot windows.
\priority{1}{C}

\item The plot update speed shall not be a bottleneck.  Speed shall
be benchmarked, and should be commensurate with comparable plotting
packages. 
\priority{1}{D}

\item Multi-panel plots (e.g.\ multiple channel maps, or spectra vs.\
baseline) of publication quality shall be possible, with:

   \begin{reqlist}

   \item user-selectable number (each direction x,y) per page;
         \priority{1}{D}

   \item user-selectable panel spacing or padding;
         \priority{1}{D}

   \item axes only along outer most panels;
         \priority{2}{D}

   \end{reqlist}

\item User shall be able to augment plots and produce overlays of different
data sets of standard formats:

   \begin{reqlist}

   \item Images with same axes, size and orientation shall be superposable
	 directly, with basic control of colors and symbols;
         \priority{1}{D}

   \item Overlay layer style shall be selectable, including:

         \begin{reqlist}

         \item contours; \priority{1}{D}

         \item vectors; \priority{1}{D}

         \item pseudo-multicolor (i.e.\ one layer gets assigned intensity 
               scales of red, another green, another blue).
               \priority{3}{D}

         \end{reqlist}

   \item Overlay of selectable coordinate grids (e.g.\ , galactic,
         ecliptic, pixel number) shall be available, including:  

         \begin{reqlist}

         \item equatorial (J2000, B1950); \priority{1}{C}

         \item galactic; \priority{1}{D}

         \item ecliptic; \priority{2}{D}

         \item local (AZ,EL), e.g.\ for beam maps; \priority{2}{D}

         \item It shall be possible to overlay multiple grids. 
               \priority{3}{D}

         \end{reqlist}

   \item The user must be able to overlay (e.g. as markers) points read in
         from standard tabular files, which include:

         \begin{reqlist}

         \item control parameters for symbol, size, position, and text;
               \priority{2}{D}

         \item position format in pixels, relative pixels, or 
               world coordinates.
               \priority{2}{D}

         \end{reqlist}

   \item It shall be possible to place data sets in ``layers'' of the
         display, which can be interactively colormapped, switched on and off,
         registered (or not), and overlaid with controllable transparency;
         \priority{3}{D}

   \item The user shall be able to overlay functional fits (e.g.\ polynomials);
	 \priority{3}{D}

   \item It shall be possible to display and overlay data with different
	 coordinate systems, i.e.\ the coordinate system of the display can be
	 chosen independent of the system the data were observed in and
	 the data transformed appropriately with pre-computation.
	 \priority{3}{D}

   \item It shall be possible to shift, rotate and scale the images 
	 interactively while viewing.
	 \priority{3}{D}

   \end{reqlist}

\item The user shall be able to change between different time and coordinate
units and formats (e.g.\ hours, hhmmss, radians, ddmmss.s) for axes.
\priority{1}{D}
	 
\item Users shall be able to save all plots and images in a publication
quality image.  They shall be able to add annotation, both interactively and
through scripts, including text with various fonts (including Greek letters),
symbols (e.g.\ all the symbols provided by the LaTeX package with AMSTeX
extension), arrows, geometrical figures like boxes and circles, etc.
\priority{2}{D}

\item Display and plotting parameters shall be saveable and reloadable.
\priority{3}{D}

\item Users shall be able to synchronize multiple display windows, for
example such that zooming to a given pixel in one image window will select
the equivalent pixel in the slaved windows. 
\priority{3}{E}

\end{reqlist}

\subsection{Visibility Domain Data}\label{sec:ol:vis:vis}

\begin{reqlist}

\item Plotting of commonly used basic data and calibration quantities must be
straightforward and easily accessible from all relevant tools.  Any quantity
should be displayable versus any other (or any two plus another encoded
as a z-axis or intensity) as long as these quantities are defined for the
same visibility or calibration solution interval.

These displayable quantities include:

   \begin{reqlist}

   \item real and/or imaginary; \priority{1}{C}

   \item amplitude and/or phase; \priority{1}{C}

   \item time; \priority{1}{C}

   \item channel or frequency or velocity; \priority{1}{C}

   \item weight and/or rms error; \priority{1}{D}

   \item uv distance; \priority{1}{D}

   \item antenna or baseline id; \priority{2}{D}

   \item u and/or v; \priority{2}{D}

   \item $T_{ant}$ and/or $T_{sys}$; \priority{2}{D}

   \item azimuth and/or elevation; \priority{2}{D}

   \item hour angle; \priority{2}{D}

   \item parallactic angle; \priority{2}{D}

   \item flag; \priority{3}{D}

   \item delay and/or rate; \priority{3}{D}

   \end{reqlist}

\item Data selection parameters shall be understandable and
user-friendly:

   \begin{reqlist}

   \item Selection shall be by name where appropriate, not just by
         an ID number (e.g.\ by antenna name or number instead of antenna
         table entry number, polarization name RR instead of 1);
         \priority{2}{D}

   \item Selection shall use graphical browsers (in GUI mode) and/or
         standard selection language (e.g.\ SQL queries) in script mode. 
	 \priority{3}{D}

   \end{reqlist}

\item It shall be possible to select the displayed data times to be the
integration beginning, middle, or end points.
\priority{2}{D}

\item It shall be possible to interpolate or extrapolate any tabulated
quantity onto a visibility or calibration solution point, and then manipulate
these like extra visibility information.
\priority{3}{D}

\end{reqlist}

\subsection{Image-cube Manipulation}\label{sec:ol:vis:cube}

\begin{reqlist}

\item Histograms of pixel values must be easily produced for selected 
regions of the cube.
\priority{2}{D}

\item Interactive display of spectra corresponding to a pixel or region
in a displayed image shall be supported.
\priority{2}{D}

\item Display of a 1D slice taken from a multi-dimensional image shall
be possible, including:

   \begin{reqlist}

   \item user specification of end-points;
         \priority{2}{D}

   \item interactive display (e.g.\ dragging the line on the map to bring up a
         position-velocity diagram);
         \priority{2}{D}

   \end{reqlist}

\item It must be possible to plot values of pixels against each other
(e.g.\ as an XY plot), for:

   \begin{reqlist}

   \item the same pixel (in pixel coords) in different images;
         \priority{2}{D}

   \item the same pixel in different layers or registered images;
         \priority{2}{D}

   \item pixels with the same world coordinates in different images;
         \priority{3}{E}

   \item one image interpolated onto the same pixels (world coords) as
         another.
         \priority{3}{E}

   \end{reqlist}

\item Plotting of spectra on a pseudo-grid corresponding to position on a
raster (e.g.\ a ``stamp map'' or ``profile map'', basically thumbnail spectra
in panels corresponding to position) shall be possible.
\priority{3}{D}

\end{reqlist}

\subsection{Other EVLA Data}\label{sec:ol:vis:anc}

{\it Although the Package will not likely be the primary vehicle for the
EVLA staff to assess the state of the array, it is intended that users 
(as well as staff) have the full capability of using ancillary data provided
by EVLA to aid in the processing and understanding of their data.  Therefore,
the Package should be able to deal with this data in as user-friendly a 
manner as possible.}

\begin{reqlist}

\item The Package shall be able to plot standard EVLA-format ancillary data
(where available), including:

   \begin{reqlist}

   \item focus data and curves; \priority{3}{D}

   \item pointing data (e.g.\ reference pointing solutions) 
         and offset vectors; \priority{3}{D}

   \item WVR output data; \priority{3}{D}

   \item ionospheric monitor (e.g.]\ GPS) output data; \priority{3}{E}

   \item TIP data and solutions; \priority{3}{E}

   \item holography and beam map data; \priority{3}{E}

   \item monitor point values (e.g.\ temperatures); \priority{3}{E}

   \item weather station data; \priority{3}{E}

   \end{reqlist}

\end{reqlist}

\newpage

\section{Simulation}\label{sec:ol:spec:sim}

{\it Note: Inclusion of at least moderate simulation capability in the Package
will benefit the user who may not have access to the more comprehensive
simulator built into the Pipeline and Online systems.  In the spirit of 
providing the user with offline options equivalent to those available in the
project, it is desirable that some simulation capability also makes it into
the Package albeit at low priority.  The main goals would be to allow the
user to simulate basic EVLA modes based on input models or images and to
replace existing data in EVLA format with simulated data.}

{\it Capability of simulating all EVLA modes of observation is needed
for planning observations (with the Observing Tool), and
comparison of data with models (in data reduction, e.g. in
order to test data reduction procedures and their reliability).
Various levels of complexity and speed of execution will be
necessary.

Relevant parts of the simulator (e.g. simple single field
and mosaic dataset generation with thermal noise and
pointing errors) should be available early in the software
production cycle in order to use it to test other EVLA
software components.}

\begin{reqlist}

\item All standard EVLA observing and correlator modes shall be
simulatable (with priority given to the most likely-used modes).
\priority{2}{D}

\item Simulated data shall be produced in the standard EVLA data format,
thus available to be used as input by the pipeline and
offline data processing.
\priority{2}{D}

\item Specification of observing scheme to be simulated shall
consist of:

   \begin{enumerate}

   \item parameters (e.g.\ \ref{req:simparam}) describing the dataset;
         \priority{2}{D}
   
   \item a template uv dataset;
         \priority{2}{D}

   \item a simple observing procedure, or a full observing program
         (set of scheduling blocks produced by the Observing Tool);
         \priority{3}{D}

   \end{enumerate}
   
\item Specification of sky data to be simulated shall consist of:

   \begin{enumerate}
   
   \item input models consisting of point-sources or Gaussians;
         \priority{2}{D}

   \item an input image;
         \priority{2}{D}

   \end{enumerate}
   
\item It shall be possible to generate fake data given observing
parameters and simple models of the instrument, atmosphere,
and spatial/spectral distribution of the source emission.  These should
include (time-variable) errors due to: 
\label{req:simparam}
         
   \begin{reqlist}
   
   \item antenna, optics, receiver, and correlator efficiencies; 
         \priority{2}{D}
   
   \item receiver thermal noise or $T_{sys}$; \priority{2}{D}

   \item receiver passband; \priority{2}{D}

   \item receiver gain fluctuations; \priority{2}{D}

   \item atmospheric emission and absorption; \priority{2}{D}

   \item atmospheric phase fluctuations (corrected or uncorrected 
         by using  water vapor radiometers); \priority{2}{D}

   \item antenna position errors; \priority{2}{D}

   \item antenna pointing errors (wind and thermal effects); \priority{2}{D}

   \item antenna primary beam response, including: 

      \begin{reqlist}
   
      \item Gaussian model; \priority{2}{D}

      \item scalar function; \priority{3}{D}

      \item polarization effects; \priority{3}{D}

      \item image; \priority{3}{E}

      \end{reqlist}
   
   \item antenna chromatism (standing wave effects); \priority{3}{D}

   \item antenna focus errors; \priority{3}{D}

   \end{reqlist}
         
\item Atmospheric emission data needed to calculate and
calibrate the radiometric phase correction shall also be
generated, using the same atmospheric model as used to
generate atmospheric phase fluctuations. Fake correlation
data shall be averaged according to the integration time
specified in the observing procedure; the phase correction
will applied according to the rules required for real data
taking.  
\priority{3}{D}

\end{reqlist}

\section{Special Features}\label{sec:ol:spec}

\subsection{Solar System Object Observing}\label{sec:ol:spec:solar}

{\it The Sun and planets are likely to be important and interesting targets
for EVLA observing.  The requirements are likely to be strongest on the
actual hardware (e.g.\ high frequency and time resolution) but software
compatibility must also be considered. In particular, solar and planetary
observations require a special effort in tracking and handling of 
ephemerides.}

\begin{reqlist}

\item The Package must be able to handle data taken in standard EVLA modes
for the Sun and Solar System object, including moving targets.
\priority{1}{C}

\item The Package must be able to calculate and compensate for the position
of moving objects in the solar system:

   \begin{reqlist}

   \item Ephemerides must be provided for major solar system objects, 
        including:

   	\begin{reqlist}

	\item Sun; \priority{1}{D}

        \item Moon; \priority{1}{D}

        \item planets; \priority{1}{D}

        \item major asteroids (all known with 50km dia. greater);
              \priority{2}{D}

%        \item known short period comets; \priority{3}{D}
% orbits too uncertain?

	\end{reqlist}

        \reqpri{1}

   \item Ephemerides must be identical to those used in the EVLA online
         system for the same objects. \priority{1}{D}

   \item Ephemerides must be calculated in all available reference frames
	(e.g.\ \ref{req:reframe}). \priority{1}{D}

   \item The Package shall be able to import a user-supplied ephemeris in
        tabular form. \priority{2}{D}

   \item The Package shall calculate positions from user-provided orbital
        elements. \priority{3}{E}

   \end{reqlist}

\item The Package must carry out astrometry for moving sources.
\priority{1}{D}

\item In addition to the standard models available in the data analysis tools,
there shall be provision for:

   \begin{reqlist}

   \item prolate and oblate ellipsoids; \priority{1}{D}

   \item limb-darkened disks (polynomial, $\cos^n$, Legendre polynomial)
         \priority{2}{D}

   \end{reqlist}

\item The visibility amplitude correction for distance (from 
ephemeris for major objects, or user-supplied) shall be computed.
\priority{2}{D}

\item The Package must calculate quantities for the ``physical ephemeris''
for the enumerated major solar system objects, including:

   \begin{reqlist}

   \item subearth latitude and longitude; \priority{3}{D}

   \item subsolar latitude and longitude; \priority{3}{D}

   \item position angle of North Pole; \priority{3}{D}

   \item season; \priority{3}{D}

   \item phase angle; \priority{3}{D}

   \end{reqlist}

\item The Package shall do coordinate transformations from plane-of-sky
to planetocentric for a selection of projections, including those
of \ref{req:project}, and in addition:

   \begin{reqlist}

   \item 3-D backprojection (onto the planetary sphere);
         \priority{3}{D}

   \end{reqlist}


\item There shall be the provision for the near-field imaging of
solar-system objects.  This can be done through the introduction of
phase corrections based upon the sphericity of the incoming wave
front. 
\priority{3}{D}

\item The Package shall support the 3-D reconstruction of the emission
using observations of the target object at different aspect angles and/or
rotational phases. 
\priority{3}{D}

\end{reqlist}

\subsection{Solar Observing}

{\it To observe the Sun one must point at the Sun. This is done the same
way that planetary observations are made. Tracking requirements for
Solar System objects are covered in the previous section.

The Sun differs from the planets and comets in several important
respects. First, it is large --- larger than the primary beam in most
bands --- and it rotates. Hence, an observer might want to correct for
both the Sun's apparent motion against the background sky *and* its
rotation. Second, the Sun is bright, so bright that the signal must be
attenuated. Finally, the Sun can be highly variable: the total flux
can change by orders of magnitude.  Specific requirements to reduce
solar observations to within currently possible errors are:}

\begin{reqlist}

\item When filling EVLA data offline, one must take care *not* to
compute weights on the basis of the nominal sensitivity since
they're often meaningless for many antennas. When solar data are
filled, the Tsys correction applied by the EVLA online system must
be undone.  Values of Tsys and the nominal sensitivity (real or
dummy) must be made available to the observer to determine which
antennas have solar cals and if any antennas or IFs are bad.
\priority{2}{D}

\item Once the "good" solar cal antennas have been identified, the
a task analogous to the AIPS task SOLCL must be available to average
the nominal sensitivities of the antennas (for each IF) for each
integration time. The dummy nominal sensitivity of any antenna that
had no solar cal must be replaced with this value.  After this step,
calibration proceeds just as it does for any other source.
\priority{2}{D}

\end{reqlist}

\subsection{Astrometry Considerations}

{\it At this time, with Phase I underway, the astrometric accuracy should
be commensurate with the highest frequencies (Q) and longest baselines (Pie
Town Link?).  An upgrade to these capabilities should be included and
budgeted with Phase II.}

\begin{reqlist}

\item The facility to correct the baseline vectors (u, v, w) shall be present,
either incorporated into the filler, or as a separate tool:

   \begin{reqlist}

   \item Timestamps should be corrected to reflect the midpoint of the
         sample integration. \priority{2}{D}
	 
   \item Special relativistic diurnal and annual aberration correction
         should be applied. \priority{2}{D}

   \end{reqlist}

\item Image plane and uv-plane component fitting shall be possible and
accurate for sources detected anywhere in a field-of-view.
\priority{2}{D}

\item Results of should be reported to sufficient precision for the EVLA
(highest frequencies and longest baselines).
\priority{2}{D}

\end{reqlist}

\subsection{VLBI}\label{sec:ol:spec:vlbi}

{\it Note: Because it is the intention that the EVLA work seamlessly
with the VLBA, it is important that the Package also supports VLBI processing.}

\begin{reqlist}

\item The Package shall support general VLBI processing suitable for 
dealing with EVLA plus VLBA data, in order to allow general EVLA users
access to VLBI science without having to learn a completely new software
package.
\priority{2}{D}

\item Results of should be reported to sufficient precision for the VLBA
(highest frequencies and longest baselines).
\priority{2}{D}

\end{reqlist}

%%%From Walter Brisken, v30Jun03

\subsection{Pulsar Observing}\label{sec:ol:spec:pulsar}

{\it Pulsar science with the EVLA will likely be done in one (or both) of
two modes: 1. phased array observing for timing/polarimetry and 2. 
interferometry.  The first mode will likely involve use of a non-NRAO
backend, and thus its post processing requirements are beyond the scope of
this document.  The later mode uses the WIDAR correlator as its backend and 
the data products are the cross correlations, similar to those for standard
EVLA observing.  The only difference is the possibility of integrating into
pulse phase bins synchronously with the pulsar rotation.  It is features
to support phase bins that are discussed here.  Bistatic radar applications
may take advantage of phase bins as well.}

\begin{reqlist}

\item Phase bins shall be supported as an additional axis in both 
UV data and images.  This axis should be on equal footing with
the spectral channel axis.  
\priority{1}{B}

\item The UV and image data must be able to support any number of phase bins
up to 1024. 
\priority{1}{B}

\item Filling of data from the EVLA should properly populate the phase
bin axis.  
\priority{1}{B}

\item Associated with UV or image data shall be some pulsar specific
keywords:

   \begin{reqlist}

   \item pulse period; \priority{2}{D}

   \item dispersion measure; \priority{2}{D}

   \item dispersion measure reference frequency; \priority{2}{D}

   \item correctional pulse phase delay. \priority{2}{D}

   \item These values shall be set when the data is filled if possible.
         \priority{2}{D}

   \item These values should be user from changable within the package.
         \priority{3}{D}

   \end{reqlist}

\item UV data selection by phase bin shall be possible:

   \begin{reqlist}

   \item in any situation where a database query is possible; \priority{1}{B}

   \item specifically for data editing; \priority{2}{D}

   \item specifically for imaging. \priority{2}{D}

   \end{reqlist}

\item Weigted averaging of the phase bins (i.e., integrating over the phase
axis, resulting in one fewer axis) shall be possible for both UV and image
data:

   \begin{reqlist}

   \item User supplied weight vectors (weight tabulated as a function of pulse
         phase, often the average pulse profile) shall be supported.  The
         format for these files shall be simple ascii text files with one
         column for pulse phase and the second for weight; \priority{1}{B}

   \item One-axis (weight tabulated as a function of pulse phase) and Two-axis
         (pulse phase and frequency channel) weight vectors should be
         supported; \priority{2}{D}

   \item A user supplied dispersion measure should be used to apply the
         correct pulse phase delay to each channel.  A reference frequency,
         where no delay is done, should also be supplied by the user;
         \priority{1}{B}

   \item A user supplied constant pulse phase delay should be allowed to 
         compensate for uncertainty in the true pulse phase; \priority{1}{B}

   \item Associated keywords should be used if no user supplied values for
         dispersion measure, reference frequency, or pulse phase delay are
         given.  \priority{2}{D}

   \end{reqlist}

\item Pulse phase axis rebinning must be possible:

   \begin{reqlist}

   \item Simple rebinning of phase bins to reduce the number of bins must be
         supported.  For example, three integer parameters to describe the
         rebinning could be: start bin, nunber of bins to combine, and number
         of output bins; \priority{2}{D}

   \item An optional one- or two-axis weight vector shall be applicable.  If
         such a weight vector is supplied, it should be used only to determine
         the relative weights of the input channels that are combined into the
         output channels, not to change the scale of the output vector;
         \priority{2}{D}

   \item A user supplied dispersion measure and reference frequency
         shall be honored if provided; \priority{2}{D}

   \item A user supplied pulse phase delay shall be honored if provided.
         \priority{2}{D}

   \end{reqlist}

\item Time averaging of UV data should properly handle phase bins.
\priority{2}{D}

\item Pulse profiles shall be extractable from image cubes:

   \begin{reqlist}

   \item A pulse profile should be extractable from any region of an image
         cube with a pulse phase axis.  This is analogous to generating a
         spectral line profile; \priority{3}{D}

   \item The user shall have the option of extracting a pulse profile averged
         over any subset of spectral channels, with dispersion measure
         correctly applied; \priority{3}{D}

   \item The user shall have the option of extracting a two-axis pulse
         profile, with spectral channel as the second axis;  \priority{3}{D}

   \item Full polarization information shall be extractable; \priority{3}{D}

   \item The output pulse profile shall be usable as a user-supplied 
         weight vector. \priority{3}{D}

   \end{reqlist}

\end{reqlist}

\newpage
\section{Pipeline Considerations} \label{sec:ol:pl}

{\it It is anticipated that the EVLA Pipeline will be the primary engine for
Online Data Processing and system monitoring, and the functional scientific
requirements for the EVLA Science Pipeline are therefore included in this
document.Also note that not all offline analysis tools will necessarily be in
the Pipeline Package.  For example, one of the important differences between
Pipeline and Offline reduction path is that Offline one should have extensive
interactive capabilities to merge and compare data with different resolution,
coordinate system, data grid, and so on.  However, given that the baseline
plan for the EVLA is that both Pipeline and Offline packages are based upon
AIPS++, the amount of common software and component reuse is likely to be
large.  We also note that ALMA will be developing similar capabilities and
that it would be advantageous if common practices and code were used in EVLA
and ALMA software.}

{\it The Package should be able to flag, calibrate, and image EVLA
data in an off-line pipeline.  All components necessary to support
off-line processing with a pipeline script should be available.}

The Package should meet all requirements outlined in section
\ref{sec:ol:ui:cli} to ensure the command line interface (CLI) is
adequate to handle off-line processing.  In addition, the following
requirements should also be met:

\begin{reqlist}

\item The user shall have control of tasking, including:

   \begin{reqlist}

   \item default directory settings;  \priority{1}{D}

   \item direction of output;  \priority{1}{D}

   \item starting and stopping of the pipeline; \priority{1}{D}

   \item task-level parallelization;  \priority{2}{D}

   \item control of memory and CPU use;  \priority{2}{D}

   \end{reqlist}

\item Automatic flagging capabilities should be available to flag bad
data.  If the heuristics for identifying and flagging bad data are
not available, then the pipeline script should allow an individual to manually
edit the data at specific points in the process, e.g.\ at the beginning
of the pipeline, after calibration solutions have been derived, and
after calibration has been applied. \priority{1}{D}

\item Automatic calibration should be available for:

   \begin{reqlist}

   \item the flux density scale; \priority{1}{D}

   \item polarization calibration;  \priority{1}{D}

   \item bandpass calibration;  \priority{1}{D}

   \item phase and amplitude calibration;  \priority{1}{D}

   \end{reqlist}

\item Automatic imaging should be available for all sources in the
project.  There should be the capability to allow an individual 
to break into the process to create a mask interactively.  
\priority{1}{D}

\item The end products of the pipeline should include: 

   \begin{reqlist}

   \item the script used to flag, calibrate, and image the dataset;
	 \priority{1}{D}

   \item deconvolved, restored images for each source; \priority{1}{D}

   \item plots of the calibration solutions; \priority{2}{D}

   \item visibility plots for each source; \priority{2}{D}

   \end{reqlist}

\item All standard processing functionality available in any official
EVLA Pipeline shall be available in the Package also as an offline analysis
option.
\priority{2}{D}

\end{reqlist}

\newpage
\appendix
\section{EVLA Observing Modes}
\label{app:modes}

We attempt to define the set of EVLA observing modes that cover the
range of observations that will be carried out with the Phase I instrument.  A
set of {\bf keywords} are defined which describe the modes.  Note that these
mix together stuff that is set online (polarization products present) and
stuff that can be changed at reduction time.

The keywords which define the EVLA Standard Observing Modes are:

\begin{description}

\item[SCAN\_MODE] How are the pointing centers arranged?

   \begin{description}

   \item[single\_field] --- a single pointing;

   \item[mosaic] --- multiple linked pointing centers (e.g.\ a raster);

   \end{description}

\item[FIELD\_MODE] Are wide-field corrections necessary?

   \begin{description}

   \item[narrow] --- no correction necessary;

   \item[wide] --- sky curvature and/or w-term correction necessary;

   \end{description}

\item[POLARIZATION] How many parallel-hand and cross-hand products are there?

   \begin{description}

   \item[single\_pol] --- one parallel hand (e.g.\ RR or LL) available, 
         which will proxy for Stokes I;

   \item[dual\_pol] --- both parallel hands present (e.g.\ RR and LL), 
         allowing Stokes I and one other (e.g.\ V);

   \item[full\_pol] --- both parallel hands and both cross hands present 
         (e.g.\ RR, LL, RL, LR), allowing all Stokes parameters (IQUV);

   \end{description}

\item[SPECTRAL\_MODE] How many spectral channels are to be analyzed together?

   \begin{description}

   \item[continuum] --- independent (usually relatively wide) bands (e.g.
                        IF sidebands);

   \item[spectroscopic] --- more than one spectral channel which must be
                        analyzed together (possibly to be combined 
                        post-calibration into a pseudo-continuum channel,
                        or kept separate);

   \end{description}

\end{description}

Observation definitions are constructed using these keywords.  For example
the most common EVLA continuum mode is given by: {\bf single\_field, narrow, 
dual\_pol, continuum}.  There are 24 EVLA standard modes built from these keys.

There are also three EVLA Special Observing Modes:

\begin{description}

\item[SPECIAL\_MODE] Are there special hardware or software modes used in the
observation?

   \begin{description}

   \item[solar] --- for bright solar signals;

   \item[planetary] --- for moving sources with ephemerides;

   \item[pulsar] --- using pulsar gating backends etc.;

   \end{description}

\end{description}

The default is for no special mode (if unspecified).

\section{Wide-Field Considerations (Frazer Owen)}
\label{app:wide}

This is an attempt to describe the steps necessary to
make a wide-field, high resolution (A or B array), deep VLA
survey at 20cm. The motivation is to encourage making this
process possible in AIPS++. The process is complex and also
requires steps outside of what one would think of as radio
synthesis imaging. However, to arrive a a useful scientific 
result one needs to consider the entire process.

\subsection{Filling the data: database efficiency}

One major problem what making a deep survey is that it
requires a lot of data. Presently, the AIPS++ database is very
nice for small problems, carrying along all the information needed
in a nice accessible way. However, the size of the databases for
deep surveys (20--100 hours, 5s integrations (probably should be shorter),
351 baselines, 2pol x 2IFs x 7channels) makes a database too large 
practically to be swallowed by the AIPS++. Also while disk sizes will
eventually absorb this database size, the new correlator will increase
these numbers by about 100x, so AIPS++ needs a mode where it deals with
the databases in as efficient a way as possible. It seems to me this
means a 16bit compressed format and possibly fewer bits of information
being carried along. AIPS++ at least needs to match AIPS efficiency
here.

\subsection{Flexible uv Editing}

Throughout the process, starting just after filling at
any time one needs to be able to investigate the uv data and apply
one of many flagging processes. In AIPS I use TVFLG, UVFLG, CLIP,
and FLGIT at various stages depending on what I encounter. Flexible
flagging and display is a must. One must also have some way to reverse
the process, either by keeping multiple copies of the database or by
easy reversibility of the flagging. The latter is harder than the former
but is more space efficient.

\subsection{External Calibration}

\begin{enumerate}

\item Bandpass Calibration:

   \begin{enumerate}

   \item phase self-calibrate bandpass calibrator before
	 any calibration is applied;

   \item calculate and display (check) bandpass corrections;

   \item apply corrections to original database, including
	 unselfcalibrated bandpass calibrator since it may be used to
	 external phase calibration.

   \end{enumerate}

\item Bootstrap amplitude calibration from flux calibrator to phase calibrator

\item Calculate and apply amplitude and phase calibration

\item Calibrate weights using external system temperatures. Currently
      I fit a polynomial to the variation of Tsys with elevation and
      apply a global Tsys vs elevation correction to all antennas. This
      is because I don't believe the noise tube calibrations. There are
      several other ways this might be done. The relative weights are often 
      in error by factors of 5 or more and thus this is important and 
      should be viewed as part of the necessary calibration.

\end{enumerate}

\subsection{Setting Up the Grid of Imaging Positions}

For wide-field, 3D imaging, one needs an inner dense grid of
of facets which cover the primary beam out to almost the first null
calculated so that 3D effects are small enough to be ignored. In addition
one needs a number of outlying fields to cover the bright confusing
sources which lie in the first sidelobe or beyond. The first part of
the problem is straightforward and I believe AIPS++ can do that. The
outlying sources are another problem. One can find them by making a
tapered image of a very large field and/or using external catalogs
like NVSS. To do the latter one would need a program which has fairly
detailed model of the primary beam beyond the first null. The first
way is easier and that is what I do most of the time. AIPS does have
a version of the second method which some people use.

Once one has an image one needs an easy way to pick out
to pick out and record the confusing sources. I usually display
a box on the TV which covers the area sampled by the dense inner
grid, so I can see what parts of the image to ignore. Then I use
TVMAX in AIPS to point at the outer confusing sources and measure
their positions. AIPS uses a simple ASCII file as the input source
for IMAGR to tell it where to put the outlying fields as well as the
dense grid. Thus one can simply use the mouse and an editor to move
the TVMAX fitted positions into the list of coordinates for AIPS.

\subsection{Picking the Weighting for IMAGR}

Besides the external weights one also needs to pick the
weighting schemes to use on the gridded uv data to get the best
compromise between beam size and noise characteristics. This requires
trying several different sets of parameters before one starts. The
best solution depends on the detailed uv sampling, so it is not
possible in general to decide this in advance. 

Right now for me this is usually a combination of ROBUST,
SUPERUNIFORM and a TAPER. There could be a bigger parameter space than 
this. One needs to do this to be sure one is getting the best
combination before going through the very long reduction process
to come.

To do this in AIPS++ right now as I understand it one
must undo the imaging weights in the database each time and go re-apply
all the different forms of weighting one wants each time. One must
also remember what one has done. AIPS, on the other always recalculates
all the imaging weights, so one must just change a single parameter
in IMAGR and rerun the program to try another combination. This is
computationally inefficient but that is a rather minor matter in total
processing time for a deep survey. 

There needs to be an user efficient way to do this, probably
with a GLISH script and perhaps with a grid of trial beams and statistics
produced. I also would prefer always to apply the weights on the
fly to minimize bookkeeping but that is a close call.

\subsection{Optimal Averaging of the Input uv Dataset}

Before imaging to minimize imaging time, one should average
the data in time and frequency to produce the smallest input dataset.
Perhaps one should do this before step IV. In AIPS one can do this
with the program UBAVG which runs through the data on each baseline
and averages versus time in such a way as to produce less than an
N percent error inside some radius from the phase/pointing center.
This can make a significant difference in imaging time since the
uv-based clean process is dominated by the number of uv points it
must subtract a model from. 

In principle there should be a step in the imaging process
which does this optimization of the uv dataset for both time and
frequency. With the current correlator at 20cm frequency sampling is not
usually adequate, so only time averaging is important but at longer
wavelengths now and in the future at 20cm and shorter wavelengths 
frequency averaging will be a issue.

However, one does need to be able to go back to the full
time resolution in the selfcal step. Also when one is combining
uv data from multiple days one needs the full time resolution.


\subsection{Initial Imaging}

Once one has the full grid set up, one can make the initial
set of images. One needs to clean this image to a moderate level
so one can see all the sources. AIPS++ should be able to do this now.
For deep imaging one normally will have multiple days with the same
or similar uv coverage. For this initial image, one uses just one
day's data to minimize the processing time.

\subsection{Initial Boxing}

Without BOXES to limit the areas CLEAN can consider, CLEAN
will scatter power outside the regions with real sources to optimize
its fit to the data. This will bias the noise low, bias the source
flux densities low, and take longer to run than if one restricts the
algorithm. It will also produce a non-optimum model for the selfcal
process. There are other ways to solve this problem besides BOXES
such as rejecting isolated clean components by some method before
restoring the image but BOXES seems to me the most straight-forward,
even if it is expensive in real time for the user.

In theory, one could write program to find the boxes. However,
in practice such a task has trouble distinguishing between residual
sidelobes from strong sources and real sources which the human can do
fairly easily. For big surveys, some such automatic program is needed
but I suspect we may always need a user check and adjustment of the
program's solution. Thus some sort of interactive environment is needed.

In AIPS right now the process is entirely interactive. One
displays the image, or part of it, on the TV and uses the graphics
overlays to mark where the BOXES should go. The interactive program,
FILEBOX, writes the marked positions in the same ASCII file as it
stores the field centers and sizes. This makes editing this file
very flexible. This process is very time consuming, however.

In the ideal world there would be a program which sets up
the first guess at the BOXES (or more general REGIONS). Kumar already
has produced a first attempt at this. Then the user would display and correct
interactively the automatically created REGIONS.

The most obvious thing missing from AIPS++ is the graphical
overlay for the TV. This will come up again and again in the image
analysis steps.

\subsection{Second Imaging}

After the BOXES, one reruns IMAGR, staring from scratch with
the clean components and clean down to the current noise level.

\subsection{Selfcal loop}

One then selfcals the first days uv data using all
the clean components and re-images the field. Usually, one does
this the first time with a phase-only selfcal, re-images, and then does
it again with a phase and amplitude selfcal and re-images again. After
each re-imaging one checks the clean boxes, usually adding quite a few
after the first selfcal. The amplitude and phase selfcal is usually
done with a longer solution interval to increase the S/N since one is
solving for more variables the second time. Besides fixing poor calibration
the amplitude and phase step also forces the two IF's to be on approximately
the same flux scale, which minimizes error for bright sources. This is
a practical matter right now. In an era with the new VLA correlator this
probably would be done differently to keep track of the differences in 
the primary beam with frequency and probably to solve for the spectral
index as well as the average total intensity across the band. Usually two 
selfcal passes are adequate, so this is not really in the DIFMAP limit.

\subsection{Further uv Clipping}

Once one has a good model one can subtract out the sources
and do a uv editing step on the uv residuals. Normally, I subtract out
the model with UVSUB, use UVPLT to plot the data, and CLIP to remove
remaining high points. Sometimes a pass through TVFLG is used here.
Then one adds the MODEL make into the remaining data with UVSUB again.
Exactly how this step fits with VIII can vary. 

\subsection{Calibration of the Rest of the Data}

Once one has a good image for the first night, one can use this 
model to calibrate the rest of the nights. Often just one amplitude
and phase "selfcal" will be good enough. Also one needs to go through
step IX on the rest of the data at this point.

\subsection{Compressing the Full uv Dataset}

Once again one wants to average the data in time and frequency
before imaging. However, in addition, one wants to average the multiple
days together to minimize the size of this full dataset. 

In AIPS right now this involves going through a series of steps
not intended for this purpose. One converts the times into HA's, edits
the headers to make the individual datasets look like they all were
observed on the same day, DBCONs all the datasets together, sorts them
in baseline-time order, averages them optimally versus time, and
sorts then back in time-baseline order for IMAGR. I probably am leaving
a few steps out. Clearly a TASK to do all this would be a better approach.
However, this effort and bookkeeping is well worth it because one can
reduce a big database by a factor of 10 or more and thus speed up the
imaging by almost the same factor.

\subsection{Imaging the Full Dataset}

At this point one normally makes an image with the full dataset,
adds and resets the boxes again, does a selfcal using the optimally averaged 
dataset, and then makes an "almost" final image.

\subsection{RR/LL Pointing Errors}

At this point the residual pointing errors usually limit
the result. The beam squint produces pointing differences between the
R and L feeds which are understood to first order. For sources near the
field center this is not too big a problem; however, for bright sources
further for the pointing center the effect can be large and can be the
big problem, scattering sidelobes over large regions of the map and
increasing significantly the average noise level. This can be helped
by a good choice of weighting at step IV. The pointing error also varies
with paralactic angle as the position of a bright source relative to
the pointing error vector changes.

The only way in current AIPS to deal with this problem is to divide the data
into small ranges of paralactic angle, by polarization and by IF. Then one
images and selfcals each subset separately, forcing the same clean beam for
each one. Then one measures the noise on each resulting image and stacks them
together weighting them optimally.  Usually if I have 6 hours for each
uv-track (only six hours to minimize the system temperature increases at low
elevation), I divide the data into two time intervals, two IFs and two
polarizations, producing 8 images in the end I must stack up.

Eventually, in AIPS++ one hopes this problem will be reduced
by smarter selfcal/imaging programs which can 1) take into account
the RR/LL pointing offset from the start, 2) solve for pointing errors
with time and include them in the processing, 3) solve for local pointing
errors for bright confusing sources and treat them separately in the
processing. However, this processing may complicate the data compression
issues and require a rethinking of the sequence of events in the processing.

\subsection{Making the Source Catalogs}

After the images are made there is still a lot to do to produce
usable scientific results. The first, most important, step is to make
a source catalog. To do this one first runs an automatic source 
finding/fitting task. In AIPS this is SAD. After adjusting a number of
parameters and running the program on the first facet of the image, one
produces an ASCII catalog. However, the same problems exist with this
task as with the automatic boxing procedure. When one is in a region
affected by the residual sidelobes of a bright source, the program has
trouble tell the difference between sidelobe ripple and real sources.
Thus one is required to investigate each source to be sure it is real.

I do this by using the ASCII list, the mouse and an almost
trivial AIPS script called COVTLOD. COTVLOD allows me to specify
a center position and an image size and then load a region of that
size on the TV centered on the position specified. While it would be
fairly easy for each user to write such a script, it is very efficient
for one to be available in the package. I similar script, COSTAR, will
also plot a symbol on the TV using the graphics overlay. I often plot
a circle centered on the position to make recognizing the source easy.
At this point I usually re-fit the flux and position of the source
with JMFIT and copy the answer with the mouse to my summary table. This
last step is probably unnecessary and is partly driven by a less than
ideal format for the SAD output.

For large sources, I usually measure a total flux density
with TVSTAT, make a contour/greyscale image with KNTR, and measure a
total size from two extreme positions on the image. If there is
a central component or other bright feature, I measure its position
using JMFIT, TVSTAT, or in extreme cases with the IMPOS, which just
reads the positions which the cursor is pointed to.

AIPS++ clearly needs the source finding/fitting/cataloging task.
It also needs the graphics overlay and should have a script to load a
small region around a given position as well as being able to mark
particular positions on the TV.

\subsection{Comparing with other catalogs}

At this point one normally wants to compare the radio image
with other images: radio, optical, IR, X-ray etc. In general other images
will not have coordinates will not be well registered with the radio
system. One needs a way to improve this. This is done in AIPS with
a program called, XTRAN, which can take a set of known positions on
the optical (or other type) image and calculate a transformation to
a new coordinate system. One can then use the SAD process to make a
catalog for this image. One can also use HGEOM to transform the image
again to register with the radio image.

However, normally it is easier to mark all the radio source
positions on the optical (or other) image and look for matches. This
is done in AIPS by making an ST file. The ST file is, in turn, made
by running a task, STARS, which converts an ASCII file into an internal
AIPS extension file. One can then use TVSTAR to mark the positions of
a large number of objects on another image. For optical identifications,
one usually uses the marks the smaller number of radio sources on the
optical image. One can also plot the ST files on greyscale or contour
output images. Another use is checking the final catalog one makes
in step XIV. 

COTVLOD and COSTAR are extremely useful at this point. One
often has an interesting object in a given field that someone has
found something interesting about at another wavelength. Using these
two scripts one can investigate the radio image at this position
quickly and precisely. 

It also is very useful to be able to plot a contour map from one band on top
of a greyscale from another. For catalogs of multiple types of objects, it is
useful to make several ST files and display each one in a different color.

While most of the latter capabilities are not imaging, they are necessary for
a complete processing package which can produce actual scientific results
without going into another package. AIPS++ must be able to deal with data from
other bands to be successful.

\end{document}
