\documentclass[10pt]{article}
\usepackage{EVLADocumentationStandard}
\usepackage{color}
\newcommand{\red}{\color[rgb]{1,0,0}}
\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}}
% uncomment the following, and re-make the dvi file, if you
% subsequently want to make a pdf file via dvi2pdf
%\usepackage{times}
%
% --- modifications to the standard LaTeX styles
%
% Page size parameters.
%
\parindent 0pt
\brokenpenalty=10000
\parskip 2mm
\renewenvironment{itemize}
 {\list{---}{\itemsep 0pt \parsep 0pt \topsep 0pt} }
 {\endlist}
% 
% reqlist environment gives ordered requirement numbers 
% 
\newcounter{req}[section]
\newcounter{subreq}[req]
\newcounter{subsubreq}[subreq]
\newcommand {\rrr}{ \arabic{subsection}.\arabic{subsubsection}.\arabic{paragraph}--R\arabic{req}}
\newcommand {\rr}{ \arabic{subsection}.\arabic{subsubsection}--R\arabic{req}}
\newcommand {\rrs}{ \arabic{subsection}.\arabic{subsubsection}--R\arabic{req}.\arabic{subreq}}
\newcommand {\rrrs}{ \arabic{subsection}.\arabic{subsubsection}.\arabic{paragraph}--R\arabic{req}.\arabic{subreq}}
\newcommand {\rrss}{ \arabic{subsection}.\arabic{subsubsection}--R\arabic{req}.\arabic{subreq}.\arabic{subsubreq}}
\newenvironment{reqlist} 
  {\list{\bf \rr}
  {\usecounter{req}} }
{\endlist}
\newenvironment{reqlistthree} 
  {\list{\bf \rrr}
  {\usecounter{req}} }
{\endlist}
\makeatletter
\def\reqlabel#1{\@bsphack \protected@write\@auxout{}%
  {\string\newlabel{#1}{{\arabic{subsection}.\arabic{subsubsection}--R\arabic{req}}{\thepage}{{\arabic{subsection}.\arabic{subsubsection}--R\arabic{req}\relax}}{req.\arabic{req}}{}}}
  \@esphack}

\newenvironment{subreqlist}
 {\list{\bf \rrs}
 {\usecounter{subreq}} }
 {\endlist}
\newenvironment{subsubreqlist}
 {\list{\bf \rrss}
 {\usecounter{subsubreq}} }
 {\endlist}
\newenvironment{subreqlistthree}
 {\list{\bf \rrrs}
 {\usecounter{subreq}} }
 {\endlist}

\setcounter{secnumdepth}{4}
\setcounter{tocdepth}{4}

%
% ---COMMAND FOR EVLA PRIORITIZATION
%
\newcommand{\priority}[2]{\par\noindent{\em Priority:~#1}\ {\em Timescale:}~#2}
%
% ---COMMANDS FOR AUDITING
%
\newcommand{\grade}[1]{\par\noindent{\em Grade:~#1}}
\newcommand{\severe}[2]{\par\noindent{\em Grade:~#1}\ {\em Severity:}~#2}
\newcommand{\comment}[1]{\par\noindent{\em Comments:} #1}
%
% ---end of modifications to the standard LaTeX styles
%

%
% to hard-code date, fill in next line, e.g.:
%\date{2002-Oct-11}
\date{\isotoday}
\DocumentType{Requirements}
\DocumentNumber{SW-001}
%
\Revision{1.3}
\ContactAuthor{B.\ Butler, S.\ Myers}
\title{EVLA e2e Software\\[3truemm] Science Requirements}
\author{
{\em EVLA Software Science Requirements Committee:}\\
        C. Brogan, B. Butler, C. Chandler, B. Clark, S. Myers, 
        P. Napier, F. Owen, R. Perley, M. Rupen}
\sloppy
\owner{B. Butler, S. Myers}
\keywords{EVLA, e2e, Software, Science, Requirements}
\rhead{EVLA e2e Software Science Requirements}
%

\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-Sep-09 & S. Myers  & All & Initial Version \\
1.1 & 2002-Oct-11 & B. Butler & All & First Revision  \\
1.2 & 2002-Oct-25 & S. Myers  & All & Second Revision \\
1.3 & 2002-Oct-29 & B. Butler & All & Third Revision, mostly pipeline \\
\hline
\end{tabular}
\vfill
\verb|$Id: evla_requirements.tex,2002-Oct-29 bbutler Exp bbutler $|

\end{center}
\newpage
\tableofcontents
%---------------------------------------------------------------
\newpage
\section{Introduction}

Because of the increased capability of the EVLA, including the greatly 
expanded capacity of the correlator, we foresee a number of new 
software developments that will need to be in place when the EVLA comes 
online.  One necessary input to proceed in these developments is a set 
of scientific requirements on the software.  This document defines these
requirements for the part of the EVLA software which has been contracted
to the Data Management division of NRAO (under the e2e project).  

\subsection{Overview of this document}

The requirements herein are structured according to the EVLA contract 
with the Data Management Division of NRAO, which has 6 specific areas:
\begin{enumerate}
  \item Proposal generation and submission (\ref{sec:propose})
  \item Observation preparation (\ref{sec:preparation})
  \item Observation scheduling (\ref{sec:scheduling})
  \item Data archive (\ref{sec:archive})
  \item Image pipeline (\ref{sec:pipeline})
  \item Data post processing (separate document)
\end{enumerate}
We have generated EVLA specific requirements in the first five of these 
areas.  The final area of Data post-processing is dealt with in a 
separate document - {\it EVLA Offline Data Processing Science 
Requirements}.  Requirements for EVLA software which is being completed 
by the EVLA project itself (not contracted to the DMD) are also 
considered in a separate document - {\it EVLA Project Software Science 
Requirements}.

We stress here that this is a living document, and subject to revision 
at any time by the EVLA SSR committee.  The intent is to write down as 
much as we can at a given time regarding the requirements, but we must 
retain the ability to remedy mistakes, oversights, or changes in 
philosophy with respect to the software.

The prioritizing scheme is described at the top of 
Section~\ref{sec:req}.  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 those charged with evaluating and accepting 
the software to take these properly into account. 

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.

In Section~\ref{sec:req} we enumerate requirements in a formal way; 
these are grouped in subsections corresponding to the main software 
components outlined in the present Introduction.  In 
Appendix~\ref{sec:Glossary} we define the main entities, used 
to manage the whole observing process, that are referred to in the 
Requirements. An example list of scheduling block operations is given 
in Appendix~\ref{sec:SBExamples}.

This document is heavily based upon the {\it ALMA Science Software 
Requirements and Use Cases} document.

The e2e project is described in much more detail in the 
{\it e2e project book}.

\subsection{General description}

Proposals will be submitted by prospective users of the EVLA for 
evaluation by a scheduling committee (with input from external 
referees).  Proposals contain all information that is necessary for the 
scheduling committee to make a decision on awarding observing time, 
including sources to be observed (with characteristics), frequencies, 
configurations, etc..., and a scientific justification.  It is 
envisioned that the preparation, submission, and handling of proposals 
is contained in a single software ``Tool'' - the Proposal Tool.

A Tool could be a stand-alone program or set of scripts, or might be an 
integrated part of a larger software package.  This is a question of 
implementation and as such is beyond the scope of this document.  We 
do require in many instances, however, that different Tools be able 
to ``speak'' to each other, i.e., can pass information back and forth. 
We also strongly recommend that if they are separate implementations 
that they at least have a common look-and-feel.

If awarded time by the scheduling committee, the observer must then 
provide more detailed information on how to go about observing the 
desired sources.  The intent should be to make this process as simple 
as possible for inexperienced users (e.g., as simple as saying ``I would
like a map of Cygnus A at 8.5 GHz with 1$^{\prime\prime}$ resolution 
and 1 $\mu$Jy rms noise''), and yet should allow the experienced 
observer enough power and flexibility to command the telescope in any 
desired (but still sensible) way.  It is envisioned that this task is 
handled by another Tool - the Observing Tool.  

Both the Proposal Tool and the Observing Tool will include at least 
minimal models of the EVLA and the site in order to give guidance, 
e.g., on whether a proposed observation is possible, or whether a 
different method of observing will produce superior results.  This will 
aid in the preparation of proposals and also in the creation of the 
program blocks (observation description).  This can build on common 
software, as discussed above.  Note that it might be possible to do 
more complex, and more realistic, simulations of EVLA observing using 
the Offline Data Processing Package, but this will not be discussed in 
this document further.

The Observing Tool creates a description of an observing program which 
is then sent to the Scheduling Tool.  The Scheduling Tool is what 
actually tells the telescope what to go off and observe next.  Dynamic 
scheduling is an essential feature of the instrument and should be 
installed from the very beginning of its operational life.  To improve 
the total efficiency we must be able to make the best use of all weather
conditions, by selecting in quasi-real time the project most suited to 
the current weather and to the state of the array. This means we should 
always be able to observe a given project in appropriate weather 
conditions. This philosophy can be extended to the point where a given 
project can change its own observing parameters according to variations 
in observing conditions (such as atmospheric phase rms). 

At this point in the information flow, we leave the regime which is 
under the e2e project, and control is passed over to the EVLA real-time 
software, described in a separate document.  The instrument collects 
the requested data, and provides it at the backend, where control is 
handed back over to the e2e software.  The dividing lines between the 
control in these two areas need much firmer definition, but that too is 
outside the scope of this document.

After data is collected, it must be archived - this is handled by the 
Archive Tool.  All related observational and technical auxiliary data 
must be accessible to the observer through the archive.  The Archive 
Tool is conceptually divided into two sections: the Archive Search Tool 
(which finds the data), and the Archive Retrieval Tool (which actually 
goes and gets it).  The archive stores not only raw data, but also 
processed images and spectra, calibration data, and even pointers to 
outside references relevant to projects contained therein.  In addition
to having its own search tool, the archive allows access via queries 
from the National Virtual Observatory (or its moral equivalent).

At the same time as data is fed to the archive, it may also be fed to a 
data reduction pipeline (conceptually, at any rate - whether the data 
is first fed into the archive and then immediately retrieved from the 
archive for input into the pipeline is a question of implementation).  
We envision the following types of operations which might be considered
as 'pipeline' related: real- (or near-real) time calibrator analysis; 
production of quick-look images and/or spectra; production of default 
images and/or spectra for the archive; user-controlled production of 
images and/or spectra from data contained in the archive.  The 
3$^{\rm rd}$ and 4$^{\rm th}$ of these are really off-line processing 
operations, and so we defer most discussion of them to the document 
discussing that topic.  The pipeline that produces the quick-look images
and/or spectra must be able to take data as it is produced by the EVLA 
and flag, calibrate, map, deconvolve, etc... it to produce the final 
images and spectra.  Because of this, it must have access to current 
calibration data including bandpass, polarization, flux density, phase 
and amplitude, antenna efficiency, etc..., and to other parameters like 
current atmospheric opacity.  The pipeline then produces images and 
spectra which are made available to the Operator(s) and to the 
observer(s).  The calibration data necessary for not only the quick-look
pipeline, but also for things like phasing the array, is obtained by 
the real- (or near-real) time calibrator analysis tool.  This is a set 
of high level functions built around what in the current system is 
called ANTSOL.

The Proposal Tool, Observing Tool, Pipeline Tool, and Archive Tool all 
interact with each other.  For instance, we imagine a prospective 
observer invoking the Proposal Tool, and while creating the proposal, 
requesting a simulation of the observation (from within the Proposal 
Tool).  To simulate the observation, the Observing Tool is invoked from 
the Proposal Tool to determine how to actually perform the observations.
The data created by the simulation is fed to the Pipeline Tool, which 
reduces the data (e.g., makes a map and deconvolves it).  The results 
are then available in the Proposal Tool.  The observer then makes a 
query into the Archive Tool to see if this observation has already been 
done, and if so, may request the data, and feed it into the Pipeline 
Tool (although this last exercise may be considered part of the off-line
data processing).  Again, these can all be separate 'programs' (or the 
moral equivalent), but they need to be callable from each other, and it 
is extremely desirable that they have a common look-and-feel for any 
interactive access.  They should also be developed in a highly 
consistent way, from the very beginning of design.  They may, however, 
be installed progressively provided the critical elements are 
implemented first.

\subsection{Some details}

The expert user/developer will need to be able to send direct commands 
to the instrument through a simple, easily editable command language.  
Atomic commands in a script language will directly send orders to the 
basic software elements controlling the hardware: antenna motion, 
instrument setup, or transmitting parameters to the data processing 
(pipeline). The script language will support loops, structured 
conditional tests, parameterized procedures, global variables and 
arrays. These scripts, once fully developed and tested, will evolve 
into the basic observing procedures of the instrument.

The general user will need more user-friendly graphic interfaces to many
components of the system. They will propose several templates, 
corresponding to the available observing modes, and provide a simple way
to pass astronomy parameters to the basic observing process, and to the 
corresponding data reduction procedures of the pipeline. Input 
parameters will preferably be expressed in terms of astronomical 
quantities, which will be translated into technical parameters by 
sophisticated configuration tools.

In writing this set of requirements, we have made a number of specific
assumptions about how the EVLA is to appear to users and staff.  These 
are: 

\begin{enumerate}
\item The EVLA software shall offer an easy to use interface to any user
   and should not assume detailed knowledge of radio astronomy and
   of the EVLA hardware.
\item The EVLA software shall provide simple ways for the staff or 
   expert astronomers to refine observing modes and develop new ones.
\item The general user shall be offered fully supported, standard
   observing modes to achieve the project goals, expressed in terms of
   science parameters rather than technical quantities. Observing modes
   shall allow automatic fine tuning of observing parameters to adapt
   to small changes in observing conditions. 
\item All user interaction with the EVLA system shall be through {\bf
   Graphical User Interfaces} (GUIs) except for the low level Command
   Control Language.
\item The instrument shall be dynamically scheduled in near real time 
   (a few minutes in advance of real time) to take full advantage of the
   atmospheric conditions and of instrument availability.  The scheduler
   will work from a queue of scheduling blocks with priorities.  For
   interactive mode, the observer will have control of the queue.
\item The EVLA final product shall be images for the large majority of
   projects.  The data shall be calibrated and processed in pipelines.
\item Observing scripts, raw data, monitor data, calibration data, and 
   images will be archived; archived data shall be easily accessible to 
   the users.
\item The EVLA processing system shall be able to handle the peak data 
   rate of 20 MB/s.  This corresponds roughly to one million 
   (double-precision complex) visibilities per second (1.0 MVPS), and 
   one-half million (double-precision) image pixels per second (0.5 
   MPPS).  See Tim Cornwell's {\it EVLA Memo 24} for an analysis of the 
   EVLA processing needs.
\comment{STM: put real numbers here}
\item Data processing pipelines will make available and display for the
   use of operations any system element performance measures they 
   develop in the course of calibration.
\end{enumerate}

%---------------------------------------------------------------------
%---------------------------------------------------------------------
\newpage
\section{Requirements} \label{sec:req}

The {\em Requirement priorities} reflect the importance and the time 
frame in which the requirement must be met in the project.

The priorities 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 in the Package and 
work with high efficiency.  Priority 2 items should be in the Package, 
though there may have to be sacrifices in performance or availability 
may be delayed.  Fulfilling Priority 2 items well should give a boost 
to a given Package's rating.  We expect that the Package 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 same as the priorities and timescales used in the 
{\it EVLA Offline Data Processing Science Requirements}.

%---------------------------------------------------------------------
\newpage
\subsection{Proposal generation and submission} \label{sec:propose}

{\it These requirements cover the preparation and submission of 
 proposals for EVLA observing time, which are to be evaluated by the 
 scheduling committee. }

\begin{reqlist}
   \item There shall be a Proposal Tool for the preparation and 
      submission of proposals for the EVLA.
      \priority{1}{A}
      \begin{subreqlist}
         \item The Proposal Tool, Observing Tool, 
            Scheduling Tool, Pipeline Tool, and Archive Tool shall be 
            integrated into a common software package, or at least be 
            able to be invoked from each other and pass data back and 
            forth, and have a common look-and-feel for any interactive 
            access.
            \priority{1}{C}
      \end{subreqlist}
   \item The proposals shall be submitted electronically and all 
      observer input shall be in digital form.
      \priority{1}{A}
      \begin{subreqlist}
         \item The scientific justification shall be provided in an 
            easily printable format (e.g., Postscript, PDF), 
            with figures incorporated (i.e., it is all in one file).
            \priority{1}{A}
      \end{subreqlist}
   \item Upon the first submission of a Proposal, the Proposal Tool 
      (or the proposal handling system of EVLA operations) 
      shall provide a unique Project Code
      for use by the observer for all correspondence, as well as further
      updates and tracking of the Proposal through the system.
      \priority{1}{A}
   \item The Proposal Tool shall allow storing of intermediate stages 
      to local disks (e.g., to enable trying out different parameter 
      settings, for backup).  
      \priority{1}{A}
      \begin{subreqlist}
         \item This stored version shall be easily transferred (across 
            platforms) with co-authors and collaborators.
            \priority{2}{C}
         \item This stored version shall be easily editable with normal 
            text editors (i.e., should be normal printable ASCII text), 
            and easily shared with co-authors and collaborators.
            \priority{3}{D}
      \end{subreqlist}
   \item Proposals output from the tool shall be readable by the tool. 
      \priority{1}{A}
   \item The proposal submission tool should support source lists.
      \reqlabel{req:scigoals}
      \begin{subreqlist}
         \item The tool must encourage entry, for all sources, of all 
            fields useful to decide scientific priority.  These include:
            \begin{subsubreqlist}
               \item Source coordinates;
               \item Source common name;
               \item Source continuum flux density;
               \item Required continuum rms (or, equivalently, required 
                  dynamic range);
               \item Requested VLA configurations;
               \item Requested observation bands;
               \item Angular size of largest structure.~\\
            \hspace*{-8truemm} Spectroscopic observations also include:
               \item Line identifications or frequencies;
               \item Requested frequency or velocity resolution;
               \item Requested velocity or redshift range;
               \item Requested rms in a spectral channel;
               \item Source flux density at line peak.
            \end{subsubreqlist}
            \priority{1}{A}
         \item The submission tool shall supply a flexible interface for
            importing the above from another medium.
            \priority{1}{A}
         \item There shall be a mechanism for specification of source 
            selection parameters in lieu of an enumerated source list,
            in order to facilitate the target definition for large
            surveys.
            \priority{2}{C}
         \item The submission tool shall provide access to catalogs 
            such that sources can be imported by common name, including 
            at least 3C, 4C, NGC, Markarian, and UGC.  Consistency 
            between positions and names of type Bnnnn+nnn, Jnnnn+nnn, 
            and Gnnn.n+n.n shall be enforced.  Consistency between 
            entered names, positions, and the above catalogs shall be 
            enforced.
            \priority{2}{C}
         \item A connection to commonly available astronomical databases
            (e.g., the CDS and NED databases) shall be available.
            \priority{3}{D}
      \end{subreqlist}
   \item The Proposal Tool shall perform certain calculations, 
         including:
      \begin{subreqlist} 
         \item the integration time required:
            \begin{subsubreqlist}
               \item for a given bandwidth and channel (e.g., velocity) 
                  width;
                  \priority{1}{C}
               \item under average environmental conditions;
                  \priority{1}{C}
               \item using real observing statistics;
                  \priority{2}{D}
               \item for the measured RFI enviroment;
                  \priority{2}{D}
            \end{subsubreqlist}
         \item the appropriate configuration needed given desired 
            sensitivity, resolution, and source angular size.
            \priority{1}{C}
         \item the scheduled time required given stringency of required 
            conditions (e.g., required phase stability at the specified 
            frequency).
            \priority{2}{D}
      \end{subreqlist}
   \item The tool shall calculate the data rate and the total data
      volume for the project.
      \priority{1}{C}
   \item The tool shall react to user input by providing warnings 
      based on the situation and selected observing mode, including:
      \begin{subreqlist}
         \item hardware limitations;
            \priority{1}{C}
         \item data rate/volume;
            \priority{1}{C}
         \item expected data quality;
            \priority{2}{D}
         \item expected stringency limitations (e.g., weather, RFI,
            ionospheric conditions).
            \priority{2}{D}
      \end{subreqlist}
   \item The basic input parameters shall be translated by the tool into
      control parameters (e.g., observing mode, configurations, 
      observing time, correlator setup) which the expert shall be able 
      to check.  These can be overridden manually (e.g., by EVLA staff).
      \priority{2}{C}
   \item There shall be the facility to search a database of previous
      observations of objects for a proposal, with the results returned 
      to the proposer, as well as being made accessible to the 
      scheduling committee.
      \priority{2}{D}
      \begin{subreqlist}
         \item The search results should be ordered by relevance.
         \priority{3}{D}
      \end{subreqlist}
\end{reqlist}

%---------------------------------------------------------------------
\newpage
\subsection{Observation preparation} \label{sec:preparation}

{\it 
These requirements cover the preparation of Program Blocks (collections
of Schedule Blocks) for submission to the Scheduling Tool by the 
observer using the Observing Tool.  It is envisioned that the 
Scheduling Tool is a software program (or equivalent), accessed only by 
the Operator, NRAO staff, and possibly expert external users. 

It is envisioned that a Project consists of one or more sets of Program
Blocks, which are in turn sets of Scheduling Blocks that are submitted
as a group to the Scheduling Tool for scheduling purposes.  For example,
a Project might include Program Blocks in each of A and B configuration
for a given target.
}

\subsubsection{The Observing Tool} \label{sec:ObservingTool}

\begin{reqlist}
   \item There shall be an Observing Tool for the generation of Program 
      Blocks as input to the Scheduling Tool.
      \priority{1}{A}
      \begin{subreqlist}
         \item The Proposal Tool, Observing Tool, 
            Scheduling Tool, Pipeline Tool, and Archive Tool shall be 
            integrated into a common software package, or at least be 
            able to be invoked from each other and pass data back and 
            forth, and have a common look-and-feel for any interactive 
            access.
            \priority{1}{C}
      \end{subreqlist}
   \item The Observing Tool shall support and enforce (at least via
      the checking for validity of format) the use of the
      unique Project Code used to identify a given Project.
      \priority{1}{A}
   \item The output of the Observing Tool shall consist of a Program 
      Block, which is a set of Scheduling Blocks that are to be 
      considered as an ensemble by the Scheduling Tool.
      \priority{1}{A}
      \begin{subreqlist}
         \item The Program Blocks and Scheduling Blocks produced by the 
            Observing Tool shall be human-readable (i.e., not binary). 
            \priority{2}{C}
      \end{subreqlist}
   \item Since the Observing Tool is the primary interface of the 
      observer to the EVLA, it should be easy-to-use and robust.
      \priority{1}{A}
      \begin{subreqlist}
         \item This tool shall operate using a GUI;
            \priority{1}{A}
         \item There shall be a batch or script mode for automated 
            generation of Program Blocks;
            \priority{1}{C}
         \item There shall be built-in help capability;
            \priority{1}{C}
         \item The use of the Observing Tool shall not entail an 
            excessive learning curve.  Average users, with some 
            knowledge of radio astronomy (as obtained by attending the 
            NRAO Summer School) shall be able to become proficient in 
            using the tool on a timescale of approximately 8 hours 
            dedicated use, and truly neophyte users (e.g., graduate 
            students in other areas of astronomy) should reach 
            proficiency with an investment not exceeding 24 hours of 
            dedicated use.
            \priority{2}{D}
      \end{subreqlist}
   \item Program Blocks output from the tool shall be readable by 
      the tool. 
      \priority{1}{A}
      \begin{subreqlist}
         \item Program Blocks output from the tool shall contain the 
            entirety of information needed by the Scheduling Tool (i.e.,
            you can use a Program Block as a template for creation 
            of a new Program Block, with minimal modification).
            \priority{3}{D}
      \end{subreqlist}
   \item The Observing Tool shall allow its state and intermediate 
      output to be saved and restored at any time. 
      \priority{1}{A}
      \begin{subreqlist}
         \item Saved outputs shall (by default) be distinguished by name.
            \priority{2}{A}
         \item Saved outputs shall be local.  
            \priority{2}{C}
         \item Saved outputs shall be easily editable with normal  
             text editors (i.e., should be normal printable ASCII text).
            \priority{3}{D}
      \end{subreqlist}
   \item The Observing Tool shall include as components tools for: 
      \begin{subreqlist}
         \item Observation setup;
            \priority{1}{A}
         \item Calibrator selection;
            \priority{1}{A}
         \item Correlator setup;
            \priority{1}{B}
         \item Pipeline data reduction setup;
            \priority{2}{D}
         \item Observation prediction;
            \priority{2}{D}
      \end{subreqlist}
   \item The Observation setup component shall:
      \begin{subreqlist}
         \item Allow the user to select from and manipulate source 
            catalogs derived from:
            \begin{subsubreqlist}
               \item a built-in calibrator catalog;
                  \priority{1}{A}
               \item user-supplied source lists in ASCII format;
                  \priority{1}{A}
               \item access to standard astronomical catalogs (CDS, NED).
                  \priority{2}{C}
             \end{subsubreqlist}
         \item Allow the user to easily construct a {\em Source List} 
            of coordinates and velocities.  This shall be possible 
            based on:
            \begin{subsubreqlist}
               \item interactive selection from a catalog list;
                  \priority{1}{A}
               \item sequential extraction of targets from a list of 
                  sources (e.g., to conveniently schedule survey 
                  programs);
                  \priority{1}{A}
               \item user input of selection parameters (e.g., area of 
                  sky, flux density, source size, depending on what is 
                  available in the catalog);
                  \priority{2}{C}
               \item on the basis of an image (e.g., from survey 
                  databases, or from the EVLA image archive) one shall 
                  be able to define the area to be mapped interactively 
                  (e.g., with a mouse). 
                  \priority{3}{D}
            \end{subsubreqlist}
         \item Produce target source lists which are exportable, 
            editable (easily with text editors, i.e., it is normal 
            printable ASCII), and re-usable for further sessions;
            \priority{1}{C}
         \item Provide to the user a list of standard observing modes 
            that may be used to achieve the science goals, from which 
            they could choose defaults.
            \priority{2}{C}
         \item Offer, for the selected standard observing mode, sensible
            defaults for all parameters deduced from the science goals, 
            making these parameters unnecessary to manipulate for the 
            general user.
            \priority{1}{C}
            \begin{subsubreqlist}
               \item Should this be supported by the Scheduling Tool,
                  the Observing Tool shall support the facility for
                  some parameters (e.g., calibrators, loop cycle times, 
                  integration times) to be selected automatically 
                  at run-time by the Scheduling Tool depending on actual
                  weather, phase fluctuations, and pipeline results.
                  \priority{2}{E}
            \end{subsubreqlist}
         \item Allow integration times and cycle repeats to be set 
            based upon a desired level of sensitivity under the 
            requested stringency (e.g., atmospheric, ionospheric,
            RFI) conditions.
            \priority{2}{C}
            \begin{subsubreqlist}
               \item Limits imposed by the scheduling committee, such 
                  as hard limit on the total project integration time, 
                  shall also be factored in (through a settable 
                  parameter).
                  \priority{2}{D}
            \end{subsubreqlist}
         \end{subreqlist}
   \item The Correlator setup component shall provide:
      \begin{subreqlist}
         \item A {\em Hardware Menu}, based on actual hardware setup 
            (e.g., number of channels, width in Hz);
            \priority{1}{B}
         \item A {\em Spectral Menu}, based on observational parameters
            (e.g., selection of spectral windows based on molecular
            transitions, velocity widths and line brighnesses); 
            \priority{2}{C}
         \item Pre-configured setups shall be available for frequently 
            observed transitions;
            \priority{2}{D}
         \item Links to a standard provided line catalog (e.g., based on
            the JPL or Lovas line catalogs);
            \priority{2}{D}
         \item Links to simulated spectra based on physical models.
            \priority{3}{E}
      \end{subreqlist}
      {\it Note: the correlator setup component acts as a translator
      between these two views; both can be visible at the same time with
      a split screen if desired (see e.g., the BIMA and SMA setup
      programs). The correlator setup component shall be linked to 
      existing line surveys for a variety of sources, to be able to
      place correlator units visually at interesting regions.}
   \item The Calibrator selection component shall provide:
      \begin{subreqlist}
         \item A built-in calibrator catalog;
            \priority{1}{A}
         \item The ability to import calibrators from a user-supplied 
            source list in ASCII format;
            \priority{1}{A}
         \item The ability to directly input calibrators;
            \priority{1}{A}
         \item The ability to select the following types of calibrators,
            based on source location, frequency, and array 
            configuration:
            \begin{subsubreqlist}
               \item primary and secondary flux density scale 
                  calibrator(s);
                  \priority{1}{A}
               \item bandpass calibrator(s);
                  \priority{1}{A}
               \item polarization calibrator(s).
                  \priority{1}{A}
            \end{subsubreqlist}
         \item The ability to display, and then select nearby sources 
            to be used for tracking time variable complex gain, based 
            on source location, frequency, and array configuration, 
            either:
            \begin{subsubreqlist}
               \item interactively (by the user), or,
                  \priority{1}{A}
               \item automatically (by the software).
                  \priority{2}{C}
            \end{subsubreqlist}
      \end{subreqlist}
   \item The Pipeline data reduction setup component shall provide:
      \begin{subreqlist}
         \item A mechanism for the observer to convey intent to
            the pipeline, including the following information:
            \begin{subsubreqlist}
               \item How calibrators are to be used;
               \item Level of flagging (e.g., light, medium, heavy);
               \item Preferred deconvolution algorithm and associated 
                     parameters;
               \item Preferred mosaicing algorithm and associated 
                     parameters;
               \item Any other necessary pipeline control parameters.
            \end{subsubreqlist}
            \priority{2}{D}
         \item Estimates for the Pipeline to evaluate the data 
            processing resources needed for science data processing.
            If the resources needed for image deconvolution are 
            significant, the proposer shall be asked when image 
            deconvolution needs to be executed, for instance:
            \begin{subsubreqlist}
               \item after observing session;
                  \priority{2}{D}
               \item at the end of program execution;
                  \priority{2}{D}
               \item when certain sensitivity levels are reached.
                  \priority{3}{E}
            \end{subsubreqlist}
      \end{subreqlist}
   \item The Observation prediction component shall be able to:
      \begin{subreqlist}
         \item estimate S/N;
            \priority{2}{D}
         \item estimate synthesized beam size;
            \priority{2}{D}
         \item estimate surface brighness sensitivity;
            \priority{2}{D}
         \item produce dirty beams;
            \priority{3}{D}
         \item effect its calculations on execution timescales on the
            order of 10 seconds or less, and should not require 
            significant computational resources
            \priority{3}{D}
         \item for suitable source models, simulate maps with the 
            desired array configurations.
            \priority{3}{E}
      \end{subreqlist}
      {\it Note: The observation prediction component of the Observing 
      Tool would preferably use common software to the prediction 
      components of the Proposal Tool (see above) to ensure 
      consistency.}
   \item The Observing Tool shall only require specification of science
      goals (see Requirement~\ref{req:scigoals}) as input.
      \priority{2}{D}
   \item The Observing Tool shall have a ``check'' function, in which 
      it presents expected sensitivities on all target sources, as well 
      as verifying correlator modes, LO setups, etc.
      \priority{2}{D}
   \item The Observing Tool shall be cognizant of the Project and 
      Program parameters as allocated by the scheduling committee, and 
      will, unless requested otherwise, apply those limits to the time 
      being scheduled.
      \priority{3}{D}
\end{reqlist}

\subsubsection{Generation of Program Blocks} \label{sec:sbgen}

\begin{reqlist}
   \item The Observing Tool shall divide a Program Block into
      Scheduling Blocks based upon parameters chosen:
      \begin{subreqlist} 
         \item by observer input, e.g., by specification of 
            cycle times and counts;
            \priority{1}{A}
         \item automatically, for standard observing modes with 
            ``science oriented'' input (e.g., sensitivity).
            \priority{2}{D}
      \end{subreqlist}
   \item The observer shall be able to assign Scheduling Blocks 
      a relative priority, to ensure the proper order of execution.
      \priority{1}{C}
      \begin{subreqlist} 
         \item There shall be the facility to support contingent 
            priority (see below), such that the priorities of
            subsequently queued blocks are adjusted based upon the
            results of execution of previous blocks, e.g., the 
            time since execution of a previous block to ensure the
            desired time spacing of monitoring observations.
            \priority{2}{D}
      \end{subreqlist}
   \item The proposer shall be able to specify what is needed for 
      real-time checking of data quality (should this be available in 
      the EVLA system), including:
      \begin{subreqlist}
         \item choosing a standard calibrator as a {\em test source} to 
            be observed to assess the conditions for stringency; 
            \priority{3}{D}
         \item option for the system to automatically choose the test 
            source at execution time.
            \priority{3}{E}
      \end{subreqlist}
\end{reqlist}

%---------------------------------------------------------------------
\newpage
\subsection{Observation scheduling} \label{sec:scheduling}

{\it These requirements refer to the scheduling of programs for actual
 observation (i.e., using the Scheduling Tool), with the actual 
 Scheduling Blocks that form a given Program Block being provided by the
 Observing Tool (see Section~\ref{sec:sbgen}).}

\subsubsection{The Scheduling Tool} \label{sec:SchedTool}

\begin{reqlist}
   \item There shall be a Scheduling Tool which generates a list of 
      commands which are input to the EVLA real-time system to control
      the telescope.
      \priority{1}{B}
      \begin{subreqlist}
         \item The Proposal Tool, Observing Tool,  
            Scheduling Tool, Pipeline Tool, and Archive Tool shall be 
            integrated into a common software package, or at least be 
            able to be invoked from each other and pass data back and 
            forth, and have a common look-and-feel for any interactive 
            access.
            \priority{1}{C}
      \end{subreqlist}
   \item The input to the Scheduling Tool shall consist of Program 
      Blocks (PB), each of which is a set of Scheduling Blocks (SB) 
      from the same Program.
      \begin{subreqlist}
         \item The SBs that comprise a given PB shall be submitted to
            the Scheduling Tool at the same time.
            \priority{1}{B}
         \item The execution of an SB shall not be interrupted by the 
            scheduling process (except possibly through an error 
            condition or manual intervention). 
            \priority{1}{B}
         \item An SB can be executed again (in order to reach the 
            required sensitivity level, or if it had failed for hardware
            reasons), but cannot be restarted in the middle of its 
            execution.
            \priority{1}{B}
      \end{subreqlist}
   \item The Scheduling Tool shall handle the observing for the EVLA in
      the main modes:
      \begin{subreqlist}
         \item A {\bf manual mode} shall be available to the staff 
            (as a special case), for testing new observing procedures, 
            by sending commands directly to the observing system, 
            using the whole array or a sub-array.
            \priority{1}{B}
         \item Normal EVLA observing shall be {\bf dynamically 
            scheduled} in quasi-real time based upon the queue of SBs.
            \priority{1}{C}   
         \item There shall be an {\bf interactive mode} where normal 
            operation from the dynamic queue is suspended and an 
            observer has control of a queue (e.g., overriding priorities
            in the main queue, or through use of an auxiliary queue) 
            into which they can submit a PB.
            \priority{1}{C}   
      \end{subreqlist}
   \item The Scheduling Tool shall be able to run off-line using 
      recorded historical inputs or simulated inputs, to facilitate 
      debugging and tuning of parameters.
      \priority{1}{B}
   \item The objective of dynamic scheduling shall be to produce the 
      highest scientific output per unit time.  Because of 
      uncertainties in future weather and the possibility of transient 
      phenomena that might occur, an absolute solution for this is not 
      possible.  A heuristic approach is required.
      \begin{subreqlist}
         \item Algorithms and heuristics shall be clearly documented.
            \priority{1}{C}
         \item Parameters and weights involved in the heuristics shall 
            be documented, and easily adjustable.
            \priority{1}{C}
      \end{subreqlist}
   \item The Scheduling Tool shall check submitted Scheduling Blocks for
      correctness, to prevent malformed SBs from being executed.
      \priority{1}{C}
   \item As SBs are scheduled, feedback to the observers (PIs) shall be 
      the following:
      \begin{subreqlist}
         \item A Scheduler web page is maintained which lists priority 
            ranked programs;
            \priority{1}{C}
         \item An e-mail is sent to the PI when the first of his/her SBs
            is executed for the first time;
            \priority{1}{C}
         \item A final email is sent at the end of the program (when 
            all the data are archived and available).
            \priority{1}{C}
         \item A Project Web page is created (with password-protection)
            which gives the current status of the Project.
            \priority{2}{D}
         \item An e-mail is sent to the PI when the first of his/her SBs
            gets for the first time into the top $\sim 10$ ranked ones, 
            as an announcement of approaching execution (but not a 
            guarantee, the weather being not easily predicted);
            \priority{2}{D}
         \item An email is sent at the end of each session;
            \priority{2}{D}
         \item The Project web page is updated at regular intervals 
            (e.g., each SB, or $\sim 10$min whichever is longest). This 
            includes the quick look image, quality check information 
            from the quick look pipeline, and general execution status 
            of the program;
            \priority{3}{D}
      \end{subreqlist}
\end{reqlist}

\subsubsection{Scheduling Operations} \label{sec:SchedOps}

\begin{reqlist}
   \item The order of execution of Scheduling Blocks from the queue
      shall be on the basis of an assigned dynamic priority.
      \priority{1}{B}
      \begin{subreqlist}
         \item The decision for the next SB to execute shall be made
            shortly before the end of the scheduling block currently 
            in execution.
            \priority{1}{C}
      \end{subreqlist}
   \item The dynamic priority of a given SBs shall be calculated at the
      decision time based upon the criteria:
      \begin{subreqlist}
         \item Availablity of the SB for scheduling.  An SB will not be 
            scheduled (dynamic priority set to zero) if its principal 
            direction is below the horizon (or if some other 
            staff-entered LST constraint is not met), if the phase 
            stability (atmospheric and possibly ionospheric) is too 
            bad for the band being observed, or if solar or radio 
            interference would compromise observations with the 
            observing parameters being used;
            \priority{1}{B}
         \item Scientific Value (see below);
            \priority{1}{B}
         \item Relative Priorities assigned by the observer using the
            Observing Tool;
            \priority{1}{C}
         \item Environmental Priority Modifiers based upon current 
            conditions;
            \priority{1}{C}
         \item Contingent Priorities (see below);
            \priority{2}{D}
         \item Operational Priorities (see below);
            \priority{2}{D}
      \end{subreqlist}
   \item The following criteria will be used in evaluating the 
      Scientific Value of an SB:
      \begin{subreqlist}
         \item Science rating as determined by the scheduling committee 
            and the referees;
            \priority{1}{B}
         \item Proximity to a preferred date or LST (e.g., for emulation
            of fixed-time scheduling for placing observations near 
            observations made with another instrument, or hitting a 
            particular phase of a variable object);
            \priority{1}{C}
         \item Suitability of the phase of a periodic phenomenon (for 
            instance the phase of a close binary star, or the orbital 
            phase of a planetary satellite);
            \priority{2}{C}
         \item The contribution of the execution of the scheduling 
            block to the program.  (That is, the contribution to the 
            sensitivity, taking into account the system temperature at 
            the current HA, atmospheric opacity and/or ionospheric 
            conditions, current RFI environment, and the number of 
            available antennas, is to be considered, not just the time.);
            \priority{3}{D}
      \end{subreqlist}
   \item There can also be Contingent Priorites, which are modifiers 
      arising at decision time based upon the results of the execution
      of other SBs from the same Program Block.  These might include:
      \begin{subreqlist}
         \item Elapsed time since previous execution (for monitoring 
            variable objects at a regular rate);
            \priority{2}{D}
         \item Hour Angle or Parallactic Angle spacing since previous
            execution (for improving uv coverage or );
            \priority{2}{D}
      \end{subreqlist}
   \item Environmental Priority Modifiers include:
      \begin{subreqlist}
         \item Local weather conditions (temperature, dew point, wind
            speed);
            \priority{1}{C}
         \item Current atmospheric conditions (opacity and phase rms
            at the observing frequencies used in the SB);
            \priority{1}{C}
         \item Current ionospheric conditions (phase rms
            at the observing frequencies used in the SB);
            \priority{1}{C}
         \item Stringency factor: SBs requiring rare conditions may be
            preferred when those conditions occur.
            \priority{2}{D}
         \item Weather predictions.
            \priority{3}{D}
      \end{subreqlist}
   \item Depending upon the algorithm chosen for implementation of the 
      system, the following heuristics may also be appropriate to 
      consider for Operational Priorities:
      \begin{subreqlist}
         \item The status of the Program as a whole (preference should 
            be given to finishing a Program Block once it is started);
            \priority{2}{D}
         \item The status of the Project as a whole (preference should 
            be given, for example, to getting a small amount of D 
            configuration time to provide short spacings for a project 
            that already has a large amount of B configuration time).
            \priority{2}{D}
         \item Auxiliary operation execution times (e.g., observation of
            calibrators or other operations required by 
            preamble/postamble blocks should these be implemented);
            \priority{3}{D}
      \end{subreqlist}
   \item The time-contiguous execution of one or more SBs of a given
      program may be started by a special setup SB (or a preamble 
      block), and ended by a final SB (or postamble block). These might
      needed to ensure proper execution (flux density measurements of 
      phase and amplitude calibrators) and calibration (bandpass, 
      polarization, phase, etc...).  {\it Note: this is implementation
      specific, and can be considered as an implementation suggestion.}
      \priority{3}{D}
   \item Pipeline results from the astronomical targets themselves (for
      instance, test point sources) can be used in computing scheduling
      block priorities.
      \priority{3}{D}
\end{reqlist}

%-------------------------------------------------------------------
\newpage
\subsection{Archiving} \label{sec:archive}

\subsubsection{Archive Definition} \label{sec:ArchDef}

\begin{reqlist}
   \item There shall be an EVLA archive which stores all data obtained 
      with the EVLA.  This archive shall include:
      \begin{subreqlist}
         \item interferometer data taken for any reason (science, 
            testing, calibration);
            \priority{1}{A}
         \item environmental data (e.g., weather data, WVR, APM, GPS);
            \priority{1}{A}
         \item monitor and control data;
            \priority{1}{C}
         \item data products (e.g., calibrated data and images from the
            pipeline);
            \priority{1}{D}
         \item project data (e.g., proposal, schedules, papers, links).
            \priority{2}{D}
      \end{subreqlist}
   \item There shall be an Archive Tool capable of accessing (including 
      searching and retrieving) the information in the archive.
      \priority{1}{C}
      \begin{subreqlist}
         \item The Proposal Tool, Observing Tool, 
            Scheduling Tool, Pipeline Tool, and Archive Tool shall be 
            integrated into a common software package, or at least be 
            able to be invoked from each other and pass data back and 
            forth, and have a common look-and-feel for any interactive 
            access.
            \priority{1}{C}
      \end{subreqlist}
   \item There shall be a backup for the archive to protect the data 
      from catastrophic failure and loss.
      \priority{1}{C}
   \item The archive shall enable astronomers and engineers to access 
      and use data which has been obtained with EVLA, regardless of 
      where the information physically resides.  When requested, the 
      archive shall let a user know the list of available data. 
      \priority{1}{D}
   \item The data shall be archived and made accessible (with access
      control) as soon as practical after they are taken or produced.
      \priority{2}{C}
   \item The principal archive(s) should be easily accessed by users 
      from all EVLA partners and major collaborators.
      \priority{2}{D}
   \item There may be several ``shadow'' archives which hold all or 
      subsets of data, which shall enable users over the world to 
      access the observational data efficiently.
      \priority{3}{C}
\end{reqlist}

\subsubsection{Raw Data} \label{sec:ArchRaw}

\begin{reqlist}
   \item The raw data in the archive shall include:
      \begin{subreqlist}
         \item raw interferometer data;
            \priority{1}{A}
         \item header information;
            \priority{1}{A}
         \item calibration data.
            \priority{1}{C}
      \end{subreqlist}
   \item In the presence of irreversible on-line data corrections such 
      as RFI excision on time scales shorter than the integration time, 
      the archive must be able to store and recognize both the corrected
      and uncorrected data.
      \priority{1}{C}
   \item All information describing the observation shall be 
      accessible through the header (or an equivalent object).
      \priority{1}{C}
   \item The data within each scan shall be identifiable by its goal 
      (phase calibrator, target observation, pointing scan ...).
      \priority{1}{D}
   \item There shall be a mechanism to identify whether the 
      observational data is scientifically meaningful or not (this is 
      to allow a user to eliminate test observations for technical 
      purpose, e.g., out-of-focus astronomical observation, etc.);
      \priority{2}{D}
\end{reqlist}

\subsubsection{Environmental Data} \label{sec:ArchEnv}

\begin{reqlist}
   \item The environmental data in the archive shall include:
      \begin{subreqlist}
         \item all measured weather data (e.g., temperature, relative
            humidity, wind speed and direction, barometric pressure);
            \priority{1}{A}
         \item the water vapor radiometric raw data (at $\sim 1s$ 
            timescale);
            \priority{1}{C}
         \item any available atmospheric electron content data (from 
            GPS, e.g.);
            \priority{2}{C}
         \item any available RFI monitoring data;
            \priority{2}{C}
         \item other atmospheric sounding data, if available (e.g.,
            Atmospheric Phase Monitor, tipping radiometer, FTS);
            \priority{3}{D}
      \end{subreqlist}
   \item Each item shall contain a time-stamp that is referenced to the
      data time stamps (i.e., not off by some large arbitrary offset due
      to internal clock slews within modules).
      \priority{1}{C}
   \item All archived environmental data shall be indexed by time, to 
      facilitate the linking of this data with appropriate observation
      periods.
      \priority{2}{D}
\end{reqlist}

\subsubsection{Monitor and Control Data} \label{sec:ArchNC}

\begin{reqlist}
   \item Monitor and control data stored in the archive shall include:
      \begin{subreqlist}
         \item status of real-time system parameters (e.g., tracking, 
            referenced pointing, delays, focus);
            \priority{1}{C}
         \item status of instrumentation (e.g., error flags);
            \priority{2}{D}
         \item monitor point information (e.g., module temperatures, 
            voltages).
            \priority{3}{D}
      \end{subreqlist}
   \item The archive shall include all technical/environmental data 
      measured by the EVLA system including times when the array was 
      not observing.  
      \priority{1}{C}
   \item Each item shall contain a time-stamp that is referenced to the
      data time stamps (i.e., not off by some large arbitrary offset due
      to internal clock slews within modules).
      \priority{1}{C}
   \item All archived technical data shall be indexed by time, to 
      facilitate the linking of this data with appropriate observation
      periods.
      \priority{2}{D}
\end{reqlist}

\subsubsection{Data Products} \label{sec:ArchProd}

\begin{reqlist}
   \item Data products stored in the archive shall include:
      \begin{subreqlist}
         \item calibrated data (or the ability to generate on-the-fly);
            \priority{1}{D}
         \item images/image cubes (or the ability to generate on-the-fly);
            \priority{1}{D}
         \item the pipeline or offline software versions and data 
            reduction scripts;
            \priority{2}{D}
         \item data quality information (e.g., noise level and dynamic 
            range, based on pipeline results);
            \priority{2}{D}
         \item histories of flux densities of calibration sources, 
            which are to be accessible for use in other observations;
            \priority{2}{D}
         \item catalog information (e.g., flux density, spectral index, 
            source size) extracted from images or data;
            \priority{3}{D}
      \end{subreqlist}
   \item Submission of products to the archive shall be controlled.
      \begin{subreqlist}
         \item the pipeline shall have access to the archive to deposit
            resulting calibrated data and images;
            \priority{1}{D}
         \item an EVLA staff member may submit the results of off-line 
            reduction and imaging for inclusion in the archive (e.g., 
            in cases where there was fault in the pipeline reduction);
            \priority{2}{D}
         \item an observer or archive user, who has been granted 
            authorization, may submit the results of off-line 
            reduction and imaging  for inclusion in the archive;
            \priority{3}{D}
         \item the pipeline, staff, or authorized users shall be able to
            deposit catalog information extracted from data into the
            Archive.
            \priority{3}{D}
      \end{subreqlist}
   \item The submission process shall provide a link between the
      submitted data and the original raw data.
      \priority{1}{D}
   \item Calibrated data produced by the pipeline are stored in the 
      archive when appropriate:
      \begin{subreqlist}
         \item For long integrations or large numbers of channels, the 
            calibrated data are stored in the archive;
            \priority{1}{D}
         \item For short integrations or small datasets, calibrated data
            may be generated on-the-fly from the visibilities upon 
            extraction from the archive;
            \priority{2}{D}
         \item The break point between image storage and on-the-fly 
            extraction shall be determined by the computing capability 
            of the archive extraction pipeline, and may evolve with time;
            \priority{3}{D}
         \item Calibrated data may be averaged or decimated with respect
            to the original raw data when appropriate.
            \priority{3}{E}
      \end{subreqlist}
   \item Images produced by the pipeline are stored in the archive when
      appropriate:
      \begin{subreqlist}
         \item For long integrations or large numbers of channels, the 
            images are stored in the archive.
            \priority{1}{D}
         \item For short integrations or small datasets, images shall be
            generated on-the-fly from the visibilities upon extraction 
            from the archive.
            \priority{2}{D}
         \item The break point between image storage and on-the-fly 
            extraction shall be determined by the computing capability 
            of the archive extraction pipeline, and may evolve with time.
            \priority{3}{D}
      \end{subreqlist}
      \priority{1}{C}
   \item Updates to the calibration must be transparently incorporated
      in the archive.
      \begin{subreqlist}
         \item The archive should provide the most up-to-date
            calibration by default.
            \priority{1}{D}
         \item The archive should contain all calibrations which are 
            applicable. 
            \priority{1}{D}
         \item If recalibration by using better calibration algorithm 
            and/or better calibration data is recommended by the EVLA, 
            then the stored image will be recalibrated.
            \priority{2}{D}
         \item If recalibration is made by the EVLA, then the old 
            calibrated image will also be stored in the archive system. 
            \priority{3}{D}
      \end{subreqlist}
   \item Quick-look data products are not stored in the final archive by
      default (see requirements for quick-look and scientific
      imaging pipelines).
      \priority{3}{D}
\end{reqlist}

\subsubsection{Project Data} \label{sec:ArchProj}

\begin{reqlist}
   \item Project data stored in the archive shall include:
      \begin{subreqlist}
         \item all user (observer) input including the scientific 
            justification of the project (i.e., the proposal);
            \priority{2}{D}
         \item high-level observing scripts as they have been used to 
            obtain the data;
            \priority{2}{D}
         \item the low-level actual observation descriptors which are 
            made by expanding the high-level observing scripts and
            (time-variable) instrumental/environmental parameters;
            \priority{3}{D}
      \end{subreqlist}
   \item Submission of Project data to the archive shall be controlled.
      \begin{subreqlist}
         \item an EVLA staff member may submit data to the archive as
            needed;
            \priority{2}{D}
         \item an observer or archive user, who has been granted 
            authorization, may submit data for inclusion in the archive;
            \priority{3}{D}
      \end{subreqlist}
   \item The submission process shall provide a link between the
      submitted data and the original raw data.
      \priority{2}{D}
   \item The archive shall store all high- and low-level scripts, not 
      only of the Scheduling Tool but also of interactive observing 
      or other manual operation, whether they are made during 
      observation or not.
      \priority{3}{D}
   \item The archive shall include an electronic logbook to record
      the notes of the observer and/or telescope operator.
      \priority{3}{D}
   \item The archive shall have the ability to attach a persistent 
      link to external archives and catalogs (e.g., DSS image) of 
      the corresponding sky area, and to published papers, e.g., ADS if 
      available, that used the relevant data, upon request.
      \priority{3}{E}
\end{reqlist}

\subsubsection{Archive Search Tool}

\begin{reqlist}
   \item There shall be an Archive Search Tool to access the Archive.
      \priority{1}{A}
      \begin{subreqlist}
         \item The Archive Search Tool shall be operated through 
            a web-based GUI.
            \priority{1}{A}
         \item The Archive Search Tool shall have a CLI to interrogate 
            the Archive from scripts or other Tools.
            \priority{1}{A}
         \item The Archive Search Tool shall serve as a front end to the
            Archive Retrieval Tool, which manages the data extraction 
            and delivery.
            \priority{2}{C}
      \end{subreqlist}
   \item The Archive Search Tool shall operate on supported platforms as
      designated by the project.
      \priority{1}{A}
      \begin{subreqlist}
         \item The appearance and operation of the Archive Search Tool
            shall be platform independent.
            \priority{3}{D}
      \end{subreqlist}
   \item There shall be a variety of help and documentation facilities 
      available from the UI and on the Internet for the Archive 
      Search Tool.  These shall include:
      \begin{subreqlist}
         \item An up-to-date and complete Reference Manual for the
            Archive Search Tool functions, operation, and installation.
            \priority{1}{A}
         \item An introductory cookbook, including examples, designed to
            let a novice user, possibly without extensive knowledge of
            radio astronomy, know how to utilize the database 
            efficiently and how to do data mining by using the archive. 
            \priority{1}{C}
         \item Interactive context-based help provided in the GUI.
            \priority{2}{D}
      \end{subreqlist}
   \item The Archive Search Tool interfaces shall present a 
      look-and-feel suitable for the differing needs of types of 
      Archive Users.  These should include:
      \begin{subreqlist}
         \item a technical interface aimed at EVLA staff users of the 
            Archive, and for Archive Tool development and debugging;
            \priority{1}{C}
         \item a user-friendly but comprehensive interface aimed at EVLA
            observers and Archive users with knowedge of radio astronomy;
            \priority{2}{D}
         \item a user-friendly interface aimed at novice users or 
            astronomers outside the expert radio astronomy community 
            (e.g., casual browsers, NVO users);
            \priority{2}{D}
      \end{subreqlist}
   \item The search criteria shall include all the information in the
      observation headers, including any information pointed to in
      sub-headers. They shall include (but not be limited to):
      \begin{subreqlist}\itemsep 0pt
         \item Object name
         \item Position on the Sky (Equatorial, Galactic, Ecliptic 
            coordinates)
         \item Hour angle
         \item Elevation
         \item Observation Date
         \item Integration Time
         \item Molecular transition
         \item Frequency
         \item Array Configuration
         \item Observation mode
         \item Whether observation is for target or calibration
         \item Angular resolution
         \item Spectral resolution
         \item Weather condition
         \item Name of Principal Investigator
         \item Project name
         \item Project number
         \item Title of the proposal
         \item Observing Programs (OPs)
         \item Scheduling Blocks (SBs)
         \item Telescope operator or Astronomer on Duty
         \item Reduction date
         \item Data quality (noise level or dynamic range).
         \item Other header info
      \end{subreqlist}
      \priority{1}{C}
   \item The Archive Search Tool shall allow searching the observation
      database to see if observations for particular targets have been 
      previously done. 
      \priority{1}{C}
   \item Regular expressions including wild card and ranges 
      shall be available in search.
      \priority{2}{D}
   \item The search criteria used for database search shall be shown 
      with search results and shall be able to be modified.
      \priority{2}{E}
   \item The Archive Search Tool shall allow search criteria based on
      combination of search fields should be possible 
      (e.g., the product of time and bandwidth).  
      \priority{3}{D}
   \item An archive user shall be able to browse all of the header 
      information for requested data. 
      \priority{1}{C}
\end{reqlist}

\subsubsection{Archive Retrieval Tool}

\begin{reqlist}
   \item There shall be an Archive Retrieval Tool to access the Archive.
      \priority{1}{A}
      \begin{subreqlist}
         \item The Archive Retrieval Tool shall have a CLI to access the 
            Archive from scripts or other Tools.
            \priority{1}{A}
         \item The Archive Retrieval Tool shall be operated through 
            a web-based GUI (possibly the same one as the Archive Search
            Tool).
            \priority{1}{A}
         \item The Archive Retrieval Tool shall be accessible from the
            Archive Search Tool.
            \priority{2}{C}
         \item The Archive Retrieval Tool shall be able to accept 
            (properly verified) web-based search and extraction requests.
            \priority{2}{D}
         \item The Archive Retrieval Tool shall be accessible from the
            Offline Data Processing Package.
            \priority{3}{D}
      \end{subreqlist}
   \item The Archive Retrieval Tool shall receive the parameters for the
      retrieval from the calling interface or Tool, and in response,
      assuming the user has authorization,  shall return the requested 
      information such as:
      \begin{subreqlist}
         \item a raw uv data file;
            \priority{1}{A}
         \item header information;
            \priority{1}{A}
         \item environmental data;
            \priority{1}{A}
         \item calibration data.
            \priority{1}{C}
         \item monitor and control data;
            \priority{1}{C}
         \item a calibrated uv data file;
            \priority{1}{D}
         \item an image;
            \priority{1}{D}
         \item other data products;
            \priority{2}{D}
         \item project data;
            \priority{2}{D}
         \item a raw data file, with averaging in time or frequency;
            \priority{3}{D}
         \item Run the pipeline on raw data with optional input 
            parameters;
            \priority{3}{E}
      \end{subreqlist}
   \item The archive user can select network transfer or physical data 
      delivery (disk/tape) for data retrieval.  The Archive Retrieval 
      Tool shall have upper limits in total data size for each of them, 
      which shall be determined by the EVLA project by taking into 
      account the network bandwidth and the I/O speed.
      \priority{2}{D}
   \item If an archive user requests a disk file transfer operation, 
      then the Archive Retrieval Tool shall put data in a 
      user-accessible directory.  The user will be informed about the 
      estimated transfer time. An email message can be requested at the 
      end of the transfer.
      \priority{2}{D}
   \item In any EVLA supported data transfer method, the data shall be 
      delivered to a user within the EVLA project defined maximum time.
      \priority{2}{D}
   \item  At user request, a preview image (e.g., a small image cube) of
      the data found in the search shall be made available before actual
      data transfer. 
      \priority{3}{D}
      \begin{subreqlist}
         \item The preview image cube of the images and dirty beams 
            shall be made either on-the-fly upon request or produced by 
            the pipeline in advance (using the same criteria as for 
            full images).
            \priority{3}{D}
         \item If a user requests a preview image without specifying
            the frequency/velocity information in the line data search,
            the Archive Retrieval Tool shall provide a sensible default
            velocity integrated intensity map (e.g., 10 km/s for 
            Galactic, 300 km/s for extragalactic, centered on the 
            observer-specified rest frequency and tracking velocity, or 
            the intensity-weighted velocity of the detected line 
            emission from the pipeline).
            \priority{3}{D}
         \item A simple image viewer for preview image shall be also 
            provided.
            \priority{3}{D}
      \end{subreqlist}
\end{reqlist}

\subsubsection{Relationship with the Virtual Observatory projects}

\begin{reqlist}
   \item The archive shall be designed to meet the requirements, if 
      practical, for on-going virtual observatory projects so that the 
      EVLA data can be used more efficiently. 
      \priority{2}{D}
   \item Whatever the final shapes of virtual observatories become,
      the EVLA archive system shall be able to provide the following
      basic elements:
      \begin{subreqlist}
         \item the archived image
            \priority{2}{D}
         \item image quality information for archived images
            \priority{2}{D}
         \item data quality information for selected observations
            \priority{2}{D}
         \item catalogues derived from the archive, if available 
            \priority{3}{E}
      \end{subreqlist}
   \item The interface shall be designed to meet the requirements for 
      virtual observatories. This assumes that the EVLA project 
      receives the requirement information early enough to meet the 
      project's development plan.
      \priority{2}{D}
\end{reqlist}

\subsubsection{Proprietary requirements}

{\it Whether data is public or proprietary will usually be decided 
on the basis of the associated proposal, with rare exceptions based 
on the project or on the proposal group.}

\begin{reqlist}
   \item Astronomical data may be public or proprietary.  
      \begin{subreqlist}
         \item Technical data and header information shall be freely 
            available;
            \priority{1}{A}
         \item Calibration observations and staff test observations 
            shall be public;
            \priority{1}{C}
         \item Access to proprietary data shall be restricted to 
            authorized users;
            \priority{1}{C}
         \item Image data, and other data products, will be proprietary 
            if the data from which the image is made is proprietary.
            \priority{1}{D}
         \item Astronomical calibration observations, as well 
            as the calibration pipeline output, can be extracted from 
            the midst of otherwise proprietary data.
            \priority{2}{D}
      \end{subreqlist}
   \item The enforcement of access control to proprietary data will be
      consistent with EVLA policy.  
      \priority{1}{C}
      \begin{subreqlist}
         \item Proprietary data will considered to be owned by the 
            associated proposal.  A mechanism shall be provided to 
            designate the authors of that proposal as authorized users 
            of that data.
            \priority{1}{C}
         \item The EVLA staff shall have the capability of marking data 
            associated with any given proposal or project as public.
            \priority{1}{C}
         \item The EVLA staff shall have the capability of making 
            proprietary data accessible to a designated user other than 
            the owner.
            \priority{2}{C}
         \item The data associated with a given proposal will (usually) 
            be made public on the basis of the expiration of a 
            proprietary interval after the latest observation done on 
            the basis of the proposal.  The Archive software must 
            recognize and enforce this interval.
            \priority{2}{D}
      \end{subreqlist}
   \item The Archive Retrieval Tool will maintain a record of data 
      extracted.
      \priority{3}{D}
   \item For data younger than a ``data notification age'', the Archive
      Retrieval Tool will send an email to the last known address of 
      the contact person of the associated proposal, informing them of 
      the data being extracted and including the comment solicited 
      above.
      \priority{3}{D}
\end{reqlist}

%--------------------------------------------------------------------
\newpage
\subsection{Pipeline data processing} \label{sec:pipeline}

{\it
Most of the Pipeline data processing is done by the off-line processing
package - what is contained herein describes only those things that 
could be considered 'pipeline-ish' which are in the on-line system:
real- (or near-real) time calibrator analysis; and production of 
quick-look images and/or spectra.  We present a single requirement for 
the Default Archive Image Pipeline which impacts the on-line system.

The real-time calibrator analysis is a set of higher level functions 
built around an algorithm capable of returning antenna-based complex 
gains given observed visibilities and a source model (what is in the 
current on-line system called ANTSOL, or in AIPS called CALIB), with 
some additional capabilities not tied to that specific algorithm.

We envision the quick-look pipeline as a subset of the full-blown 
off-line processing package pipeline which can execute quickly and 
return first-cut images and/or spectra to the operator(s) and 
observer(s).
}

\subsubsection{Real-time Calibrator Analysis}

{\it
The real-time calibrator analysis is a set of higher level functions 
built around an algorithm capable of returning antenna-based complex 
gains given observed visibilities and a source model (what is in the 
current on-line system called ANTSOL, or in AIPS called CALIB), with 
some additional capabilities not tied to that specific algorithm.
}

\begin{reqlist}
   \item The Real-time Calibrator Analysis Tool shall be activated 
      after each calibration scan, except during autophasing, where it 
      must be able to run during scans.
      \priority{1}{C}
      \begin{subreqlist}
         \item It should be possible to also specify shorter or longer 
            intervals between activations, e.g., execute at the end of
            every integration, rather than just at the scan end, or, do 
            not execute at the end of every scan, but rather only at 
            the end of some number or grouping of scans.
            \priority{2}{D}
      \end{subreqlist}
% bjb - is the following an operations req?
%  \item Whenever the results of the Real-time Calibrator allow one to 
%     identify poorly behaving hardware, a status report will be logged 
%     at system level for maintenance purposes, and made available both 
%     to the operator and to the Scheduling Tool.  Affected data will 
%     be flagged.
%     \priority{2}{C}
   \item The Real-time Calibrator Analysis Tool shall determine the 
      autophasing phase for each antenna, IF, and sub-band, and make 
      it available to the real-time observing system.
      \priority{1}{C}
      \begin{subreqlist}
         \item It shall be possible to select either on-the-fly 
            autophasing (with appropriate simple source model input),
            which is done on each integration, or to specify that
            phases determined during calibrator scans are to be used
            to phase the array during scans on the astronomical source.
            \priority{1}{C}
            \begin{subsubreqlist}
               \item For phases determined on the calibrator and applied
                  to the astronomical source, simple extrapolation 
                  schemes should be available (e.g., last sampled value,
                  linear extrapolation given last 2 samples, spline
                  extrapolation given last N samples, etc...).
                  \priority{3}{E}
            \end{subsubreqlist}
      \end{subreqlist}
   \item The Real-time Calibrator Analysis Tool shall have the 
      capability of taking visibility data along with a source model 
      for a calibrator and deriving antenna-based complex gains
      therefrom.
      \priority{1}{C}
      \begin{subreqlist}
         \item There should be a capability of specifying simple u-v 
            restrictions on the input visibilities (e.g., boxes or 
            circles in the u-v plane).
            \priority{1}{C}
         \item There should be a capability of specifying the following 
            simple parametric source models:
            \begin{subsubreqlist}
               \item point source (flux density, position, spectral 
                  index);
                  \priority{1}{C}
               \item elliptical gaussian (flux density, position, 
                  major and minor axis width and position angle, 
                  spectral index);
                  \priority{1}{C}
               \item elliptical limb-darkened disk (flux density, 
                  position, major and minor axis width and position 
                  angle, limb-darkening parameter, spectral index);
                  \priority{3}{D}
               \item combinations of the above simple single sources.
                  \priority{2}{D}
            \end{subsubreqlist}
         \item There should be a capability of specifying more complex
            source models, via input as a FITS image cube or set of 
            CLEAN components as a function of frequency (or other, 
            relatively simple and easily manipulated, image-plane 
            description).
            \priority{2}{D}
      \end{subreqlist}
   \item The Real-time Calibrator Analysis Tool should have the 
      capability of determining the current phase stability of the 
      instrument + atmosphere, given the visibilities and complex gain
      solutions.  This quantity should be accessible by the Scheduling
      Tool.
      \priority{2}{D}
   \item The Real-time Calibrator Analysis Tool should have the 
      capability to recognize misbehaving antennas based on its 
      results, and should be able to report this information to the 
      real-time system and to operations.
      \priority{2}{D}
   \item The Real-time Calibrator Analysis Tool should support the 
      following higher level functions:
      \begin{subreqlist}
         \item antenna location determination;
            \priority{1}{D}
         \item global pointing model determination, per antenna;
            \priority{1}{D}
         \item pointing offset determination, per antenna and frequency 
            band;
            \priority{1}{D}
            \begin{subsubreqlist}
               \item arbitrary 'pointing patterns' (e.g., 5-point,
                  triangles, the 'Craig cross', etc...) shall be 
                  specifiable as an ordered table of offsets and dwell 
                  times.
                  \priority{2}{D}
               \item single-dish pointing determination should also be 
                  supported.
                  \priority{2}{D}
            \end{subsubreqlist}
         \item complex bandpass, per antenna, given frequency band, 
            correlator and backend setup;
% note - this is hard to specify, since there are so many possible
% 'backend' configurations.  should we skip it, or make it so that
% just the most common modes are supported here?
            \priority{1}{D}
         \item focus, per antenna and frequency band;
            \priority{1}{D}
            \begin{subsubreqlist}
               \item arbitrary 'focus patterns' shall be specifiable 
                  either parametrically (i.e., arbitrary center point, 
                  number of points, delta focus between points, dwell
                  time per point), or as an ordered table of focus 
                  positions and dwell times.
                  \priority{2}{D}
               \item single-dish focus determination should also be 
                  supported.
                  \priority{2}{D}
            \end{subsubreqlist}
         \item delays (including the crossed-hands), per antenna, 
            frequency band, IF, and sub-band;
            \priority{1}{D}
         \item polarization calibration terms, per antenna and frequency
            band;
            \priority{1}{D}
         \item flux density scale determination (i.e., the conversion 
            factor from correlation coefficient to Janskys);
            \priority{1}{D}
         \item TIP analysis to derive antenna parameters (Tcal) and 
            atmospheric opacity at the observed frequency;
            \priority{2}{D}
         \item antenna aperture efficiency determination, per frequency,
            given knowledge of source flux density, atmospheric opacity,
            and other system quantities.
            \priority{3}{E}
      \end{subreqlist}
   \item There should be simple commands to invoke the higher level 
      functions, e.g., ``determine focus at W frequency using X 
      calibrator'', as well as a capability for more detailed commands,
      e.g., ``determine focus at W frequency using X calibrator using Y 
      points centered at Z focus, and here is the calibrator model 
      image cube.''
      \priority{2}{D}
   \item The outputs from the Real-time Calibrator Analysis Tool should 
      be archived (probably by passing them to the Archive Tool).
      \priority{1}{D}
   \item The outputs from the Real-time Calibrator Analysis Tool should 
      be available to the Quick-look Pipeline Tool.
      \priority{1}{D}
\end{reqlist}

\subsubsection{Quick-look Pipeline}

{\it 
The quick-look pipeline produces images and/or spectra on short
timescales for feedback during observing - both to the operator and to 
the observer.  It is most likely that this is a streamlined version of
the full off-line science pipeline.
}

\begin{reqlist}
   \item The Quick-look Pipeline Tool shall be activated automatically 
      under given conditions (e.g., after a certain time interval, 
      after each scheduling block, etc...).  These intervals should 
      be specified in the Observing Tool.
      \priority{1}{D}
   \item It should also be possible to run the Quick-look Pipeline Tool 
      whenever requested by the staff astronomer, operator, or observer
      (assuming a reasonable request).
      \priority{1}{D}
   \item The Quick-look Pipeline Tool should, when selecting data, 
      apply all desired flagging.  The operater or astronomer should
      be able to select the level of flagging, e.g., light, nominal,
      heavy, etc...
      \priority{1}{D}
   \item The Quick-look Pipeline Tool should create calibrated image 
      cubes and/or spectra, with the best calibration information 
      currently available, including:
      \begin{subreqlistthree}
         \item conversion of correlation coefficients into flux density,
            including an opacity correction;
         \item bandpass calibration;
         \item polarization calibration;
         \item transfer of amplitude and phase correction from 
            calibrator(s) (using the scaling factor between the 
            calibration and observing frequencies if necessary);
         \item WVR phase correction, if desired and available.
      \end{subreqlistthree}
      \priority{1}{D}
   \item The following calibration modes shall be supported:
      \begin{subreqlistthree}
         \item calibration transfer (including fast switching);
            \priority{1}{D}
         \item self-calibration.
            \priority{1}{D}
      \end{subreqlistthree}
   \item The Quick-look Pipeline shall always compute the dirty image of
      astronomical sources when directed to do so (the operator or 
      astronomer should be able to select spectra only), using the 
      fastest algorithm possible.  The supported observing modes should 
      include:
      \begin{subreqlistthree}
         \item normal single-field synthesis;
            \priority{1}{D}
         \item multiple source observations (``snapshots'');
            \priority{1}{D}
% bjb - do we really even want this in there?
         \item mosaicing;
            \priority{2}{E}
      \end{subreqlistthree}
   \item The Quick-look Pipeline should deconvolve the dirty images,
      if possible in the short time allowed, using a fast deconvolution
      algorithm, with minimal controlling inputs (e.g., only 
      Cotton-Schwab CLEAN allowed, only to very shallow levels 
      [a few hundred to a thousand components?], with pre-set [not
      selectable] weighting, tapering, etc... parameters).
      \priority{2}{D}
   \item The processing described in the previous requirement shall be 
      done for:
      \begin{subreqlistthree}
         \item the continuum data;
         \item the line-averaged spectra, over a pre-defined velocity 
            or frequency range (defined either by the astronomer or by
            the staff astronomer or operator).
      \end{subreqlistthree}
      \priority{1}{C}
   \item The Quick-look Pipeline Tool should create complete its 
      execution on a time scale which is reasonable for astronomy 
      decision making (current thinking is a few minutes at most).  If 
      the astronomer is asking for too much from the Quick-look Pipeline
      Tool (e.g., ``I want an image cube which covers the full primary 
      beam over 32000 channels every 100 milliseconds''), the Tool 
      should indicate that what is being asked for is unreasonable.
      \priority{2}{D}
\end{reqlist}

\subsubsection{Default Archive Image Pipeline}

{\it 
It is envisioned that when all of the data has been collected for a 
given Program, a pipeline will be invoked which creates the default
image for the archive for that program.  There is a single requirement 
on the on-line software that connects with this pipeline, which we
specify here.  The rest of the requirements for that pipeline are 
contained in the off-line processing document.
}

\comment{BJB: it's not clear that this req should be in this document.
one could envision that there is a mechanism for going through the
archive off-line and seeing which Programs have been completed,
and triggering the Default Archive Image Pipeline that way.  it could,
in that case, go into the Archive section above.  we can discuss which 
is preferable.}

\begin{reqlist}
   \item The default image pipeline needs to be triggerable from the 
      on-line system (i.e., the on-line system recognizes that a 
      Program has been completed, and sends a signal to the default 
      image pipeline that it should go off and do its thing.  The 
      default image pipeline may have to delay execution until all 
      necessary calibration quantities are obtained, but it should have 
      the capability of receiving the indication from the on-line 
      system that all of the visibility data has been collected for 
      that program).
      \priority{2}{D}
\end{reqlist}

\subsubsection{Atmospheric Model}

\comment{BJB: it's not clear to me if we want this in here, but 
it could be used by both the Real-time Calibrator Analysis Tool and the
Quick-look Pipeline Tool}

\begin{reqlist}
   \item Atmospheric modelling shall be available in the Pipeline.  The
      model shall be able to predict the absorption, emission and 
      pathlength on the line of sight through the atmosphere at all 
      EVLA bands. The prediction will be based on measured data, 
      including, but not limited to:
      \begin{subreqlistthree}
         \item measured atmospheric parameters at the site: temperature,
            pressure, humidity;
         \item measured atmospheric emission in the observed EVLA bands;
         \item measured WVR data;
         \item measured atmospheric profiles of temperature and water
            content if available from atmospheric sounders;
         \item measured optical depths from tipper meters and/or FTS, if
            available;
         \item measured electron content from GPS or other techniques.
      \end{subreqlistthree}
      \priority{1}{C}
   \item Atmospheric modelling shall be used to derive the opacities in
      all astronomical bands in use, in order to correct the observed 
      amplitudes at various elevations.
      \priority{1}{C}
   \item Atmospheric modelling shall be able to provide the conversion 
      factors between WVR data and the water contribution to the 
      astronomical phase in all EVLA bands.
      \priority{2}{D}
\end{reqlist}

\subsubsection{The Astronomer's ``what's up'' Screen} \label{sec:whatup}

\comment{BJB: it's not clear to me that this subsection belongs here.
i think it's appropriate for this document, but i don't know where
it should go.}

{\it
The astronomer shall be able to access via the internet a GUI which
displays information about observations currently being undertaken by 
the EVLA.  BGC has coined the term: ``what's up screen'' for this, and
we adopt that terminology here.  It is a screen that makes available,
e.g., information on current meteorological parameters, phase stability,
observing Program, source, real-time calibrator analysis output, 
quick-look pipeline output, raw visibility information, etc...
}

\begin{reqlist}
   \item There shall be made available over the internet an astronomer's
      ``what's up'' screen, giving current observational and 
      instrumental information for the EVLA.
      \priority{1}{C}
   \item The following quantities and their time histories shall be 
      able to be displayed via the ``what's up'' screen:
      \begin{subreqlist}
         \item current surface meteorological parameters;
            \priority{1}{C}
         \item current auxiliary monitoring device output:
            \begin{subsubreqlist}
               \item Atmospheric Phase Monitor - raw data and related
                  derived quantities (structure function, rms phase, 
                  corner time, exponent);
                  \priority{1}{C}
               \item current opacity estimate for all observing bands, 
                  from either surface data, seasonal estimate, TIPs of 
                  the array itself, separate tipping radiometers, 
                  separate FTS devices, etc...
                  \priority{2}{D}
               \item Water Vapor Monitor byproduct data (e.g., derived
                  precipitable water vapor from WVM data);
                  \priority{2}{E}
               \item RFI monitor (if available);
                  \priority{3}{E}
               \item Atmospheric electron content information (if 
                  available, via GPS, e.g.);
                  \priority{2}{D}
            \end{subsubreqlist}
         \item current array properties, such as:
            \begin{subsubreqlist}
               \item the $uv$ coverage and dirty beam, integrated over 
                  the current session, for a chosen target source;
                  \priority{2}{D}
               \item the thermal noise rms reached since the beginning 
                  of the observing session (from theory, using actual 
                  system temperatures);
                  \priority{2}{D}
               \item for mosaic observations: the above quantities for 
                  each pointing center.
                  \priority{3}{E}
            \end{subsubreqlist}
         \item results of real-time calibrator analysis output for the 
            current session, including any focus, delay, reference 
            pointing, complex gain, etc..., data.  There should be a 
            variety of options, to control the display parameters, to 
            plot the variation of these results with time, to allow the 
            staff astronomer and operator to monitor one antenna or 
            baseline in particular, etc.  Since it is required that the 
            EVLA staff can efficiently check out the status of ongoing 
            observations, all the plots should be reasonably simple, 
            and the plot option should be able to quickly be changed by 
            the staff astronomer/operator.
            \priority{1}{C}
         \item the (uncalibrated) spectrum observed on an astronomical 
            source (amplitude/phase or real/imaginary) with various 
            options such as:
            \begin{subsubreqlist}
               \item time integration;
                  \priority{1}{C}
               \item choice of a single baseline (antennas selectable)
                  or all baselines;
                  \priority{1}{C}
               \item vector or scalar averaging.
                  \priority{1}{C}
            \end{subsubreqlist}
         \item the resultant image cube and/or spectrum from a 
            quick-look pipeline execution.
            \priority{1}{D}
      \end{subreqlist}
   \item It should also be possible for the staff astronomer, operator,
      or observer to initiate execution of the quick-look pipeline from
      the ``what's up'' screen (assuming a reasonable request).
      \priority{2}{D}
% XXX bjb note - these are hard-wired links to the requirements above,
%  but we have no mechanism for a soft-cross-reference into this
%  silly \reqlist environment, so if the requirement numbers change
%  above, they need to be fixed here!  XXX
   \item There should be a link to the Scheduler web page from the 
      ``what's up'' screen (see requirement~{3.1-R7.1}).
      \priority{2}{D}
   \item There should be a link to the Project web page from the 
      ``what's up'' screen (see requirement~{3.1-R7.7}).
      \priority{2}{D}
\end{reqlist}


%-------------------------------------------------------------------
\appendix

\newpage
\section{Definitions and Descriptions} \label{sec:Glossary}

In this Section we introduce the main entities, used to manage the
whole observing process, that are constantly referred to in the
Requirements. These entities have some kind of hierarchical structure 
that will be further refined at the analysis stage of software 
development.

\begin{description}\itemsep 2ex
   \item[Proposal:]~\\

      An observer submits a proposal to perform a set of observations. 
      A proposal has uniquely associated with it:
      \begin{itemize}\itemsep 0pt
         \item A proposal identification code;
         \item A status (e.g., New, Being Observed, Partially Scheduled,
            Rejected, etc...);
         \item A title;
         \item A list of requested frequency bands;
         \item A list of sources, explicit or generic (for large 
            surveys);
         \item A crude technical categorization (Detection/Mapping,
            Spectroscopic Line Survey, etc...);
         \item A crude scientific categorization (solar system, stars, 
            galaxies, cosmology, etc...) in order to help reviewers;
         \item An author list;
         \item A contact person and contact information;
         \item A staff contact person;
         \item A scientific justification;
         \item A synoptic referee rating.
      \end{itemize}			
      It has associated with it an author list, a time request list, 
      and an optional source list.

      Note that ``staff contact person'' and ``synoptic referee rating''
      are assigned well after submission.  Additional information it 
      might be useful to include later on are:

      \begin{itemize}\itemsep 0pt
         \item Total array time scheduled under the aegis of this 
            proposal;
         \item Sensitivity weighted time scheduled under the aegis of 
            this proposal (for observations at unfavorable elevations 
            or high system temperature.);
         \item Number of observing sessions scheduled under this 
            proposal;
      \end{itemize}			

      Although there certainly are groups of proposals (and the 
      submission tool should have a box to list associated or previous 
      proposals), it is proposed to take no formal cognizance of them,
      with the exception that the proprietary period of a group of
      proposals may be considered to extend through the last member of 
      the group.

   \item[Project:]~\\

      When approving a proposal, the observing program committee 
      creates one or more Projects.  A Project is a scientifically 
      independent subset of the observations proposed in the Proposal 
      which have been approved by the observing program committee.  
      Each project may have a different scientific rating.

      The project refers back to the proposal through the proposal
      identification code.  It has associated with it additional
      information:
      \begin{itemize}\itemsep 0pt
         \item A project identification code;
         \item A list of requested bands (possibly subset of those in
            proposal);
         \item A list of requested configurations (possibly subset of 
            those in proposal);
         \item A scientific rating assigned by the observing program
            committee;
         \item An optional source list (subset of that in proposal if 
            that exists);
         \item A limitation of observing resources (reassessment of
            sensitivity level, maximum observing time);
         \item Number and status (e.g., Observed, Partially Observed, 
            Not Observed) of the underlying programs. 
      \end{itemize}

   \item[Program:]~\\

      Within each project, observations in different configurations are 
      each assigned to a separate program.

      Each program has associated with it an observing description (a
      Program Block), which describes (in greater detail than is 
      available in the proposal) how the observations are to be 
      completed for the program.

      The Program Block is a set of Scheduling Blocks (SB) and Break 
      Points (BP).

      The program refers back to the proposal and project through the
      proposal and project identification codes.

      A Program has associated with it the additional information:
      \begin{itemize}\itemsep 0pt
         \item Configuration(s) in which its Scheduling Blocks may be 
            run (including whether move time is acceptable).  Note that
            if multiple configurations are required, then it must be 
            split into separate Programs - if any one of several 
            configurations are acceptable, they can be specified here;
         \item List of requested bands (a subset of those in the 
            project);
         \item A limitation of observing resources;
         \item Total array time scheduled under the aegis of this 
            program;
         \item Sensitivity weighted time scheduled under the aegis of 
            this program;
         \item An optional scientific rating assigned by the observing 
            program committee;
         \item A Program Block (observing description).
      \end{itemize}

   \item[Program Block (PB):]~\\

      The set of Scheduling Blocks derived from a single Program that 
      are to be submitted to the Scheduling Tool for queuing at the 
      same time.  An observer would normally create these in a single 
      run of the Observing Tool.

   \item[Scheduling Block (SB):]~\\

      When the observer is notified that their project is approved for
      phase II, they make a set of scheduling blocks.  The division 
      into scheduling blocks is under the observer's control, but for 
      standard observing modes, a template is provided, and observers 
      are warned that deviating from the spirit of the templates may 
      result in a reduced likelihood of being scheduled.  The SB refers 
      back to the proposal through the proposal, project, program, 
      identification code.  It has associated with it additional 
      information:
      \begin{itemize}\itemsep 0pt
         \item A control script to be executed, including scripts or 
            objects for preamble and postamble observations
            (should these be implemented);
         \item A maximum single execution duration of the SB;
         \item A maximum total observing time to be spent using this SB;
         \item A main target direction, to be used by the scheduler to
            evaluate observing priority for the SB. All actual targets 
            must lie within a limited area around this direction 
            ($\sim$ 5 degrees, TBD);
         \item The sensitivity goal to be reached by repeated 
            executions to be checked using the nominal radiometry 
            formula, expressed in $T_{\rm A}^*$ units;
         \item The maximum water content required for scheduling
            (normally defaulted from frequency);
         \item The maximum phase fluctuation (after phase correction) 
            required for scheduling (normally defaulted from technical 
            characterization, frequency and requested angular 
            resolution);
         \item An optional, observer assigned relative priority to be
            used when scheduling. This is used for dependencies 
            between SBs in a given project;
         \item A maximum pointing error (systematic and random 
            components) including wind speed;
         \item An optional preferred LST range, and preference for 
            rising sources, which may be used to increase the 
            likelihood of contiguous UV tracks, over a system 
            preference for high elevations;
         \item Status information, including at least:
            \begin{itemize}\itemsep 0pt
               \item The number of successful executions;
               \item The integration time, and theoretical rms for each
                  execution;
               \item The total integration time, and current resulting 
                  theoretical rms;
               \item The total array time used so far;
               \item Whether the block goals are reached.
            \end{itemize}
      \end{itemize}

      Each source in the SB should be checked to be either a member of 
      the proposal source list or a calibrator.

      Preamble and postamble operations have several possible functions.
      The purpose of these operations is to collect data for use in the 
      data reduction phase:
         \begin{itemize}\itemsep 0pt
            \item Bandpass calibration;
            \item Polarization leakage term calibration;
            \item Receiver phase difference calibration.
         \end{itemize}

   \item [Observing Session:]~\\

      The time contiguous execution of one or more scheduling blocks 
      in a program constitutes an observing session.  An observing
      session has a common preamble and postamble for each SB which
      requires one.

   \item [Scan:]~\\

      The scan is the lowest level object normally used by an observer.
      It is a sequence of one or more observations that share a single
      goal.  A scan is usually a single observation of a target 
      source or a calibrator, but, for instance, pointing and focus 
      scans involve a pattern of observations.

   \item [Observation:]~\\

      An Observation is the minimal amount of data taking that can be
      commanded at the script language level. It is highly desirable 
      that it should be a simple enough element so that the script 
      language may be used to define the content of scans (at the staff 
      member/expert level), as a means to develop and debug new 
      observing modes. Ideally a single generic command could execute 
      any observation as described by the Observation Descriptor. The 
      Observation Descriptor features:
      \begin{itemize}\itemsep 0pt
         \item A simple driving pattern for each antenna;
         \item A simple driving pattern for the array phase center;
         \item A single receiver and frequency setup;
         \item A single correlator configuration.
      \end{itemize}

   \item [Integration:]~\\

      An Integration is the basic written unit of data. It is the 
      average of a set of Correlator Dumps.

   \item [Correlator Dump:]~\\

      A Correlator Dump corresponds to the minimum available integration
      time output from the correlator hardware.

   \item [Control Script:]~\\

      A script in the language of the on-line computer system directing 
      the VLA or a subarray thereof to collect data with a specified 
      receiver setup, phase tracking center, and antenna pointing.  
      Note that Control Scripts can function as the main control script 
      of a Scheduling Block or as Preamble/Postable scripts.  The VLA 
      is operated by having the Scheduling Tool, or a human operator, 
      pass a Control Script to the real-time computer system.

\end{description}

%-------------------------------------------------------------------
\newpage
\section{Scheduling Block Templates} \label{sec:SBExamples}

\comment{STM: these are from ALMA.  Is this useful here?  If so, they 
 need to be changed.}

We give here a few examples of Scheduling Blocks, in order to provide a 
guide as to our thinking about how observing might be organized.  These 
are not specifications.

\begin{itemize}\itemsep 0pt
   \item Strong source, low frequency, interferometry:
      \begin{itemize}\itemsep 0pt
         \item One minute phase calibrator scan
         \item Nine minutes target scan
      \end{itemize}
   \item Strong source, high frequency, interferometry:
      \begin{itemize}\itemsep 0pt
         \item Pointing scan
         \item (optional) Focus scan
         \item One minute phase calibrator scan
         \item Nine minutes target scan
         \item One minute phase calibrator scan
         \item Nine minutes target scan
         \item One minute phase calibrator scan
         \item Nine minutes target scan
      \end{itemize}
   \item Weak source, low frequency, interferometry:
      \begin{itemize}\itemsep 0pt
         \item Twenty seconds phase calibrator scan
         \item Forty seconds target scan
      \end{itemize}
   \item Weak source, high frequency, interferometry:
      \begin{itemize}\itemsep 0pt
         \item Pointing scan
         \item (optional) Focus scan
         \item Twenty cycles of
            \begin{itemize}\itemsep 0pt
               \item Twenty seconds phase calibrator scan
               \item Forty seconds target scan
            \end{itemize}
      \end{itemize}
   \item Dual band, low frequency, interferometry:
      \begin{itemize}\itemsep 0pt
         \item Target, band 1, two minutes
         \item Calibrator, band 1, 30 seconds
         \item Calibrator, band 2, 20 seconds
         \item Target, band 2, two minutes
      \end{itemize}
   \item Accurate polarization:
      \begin{itemize}\itemsep 0pt
         \item Pointing scan
         \item (optional) Focus scan
         \item Leakage calibrator scan, 1 minute
         \item Thirty cycles of
         \begin{itemize}\itemsep 0pt
            \item Phase calibrator 20 seconds
            \item Target 40 seconds
         \end{itemize}
      \end{itemize}
   \item Mosaicing:
      \begin{itemize}\itemsep 0pt
         \item Pointing scan
         \item (optional) Focus scan
         \item Phase calibrator 20 seconds
         \item Up to 30 mosaic points at 30 seconds each
      \end{itemize}
\end{itemize}

\end{document}
