\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}}
%
% --- 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.2}
\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{S. Myers, B. Butler}
\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  \\
\hline
\end{tabular}
\vfill
\verb|$Id: evla_requirements.tex,2002-Oct-25 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}.

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
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 observing scripts.  This can build
on common software, as discussed above.  Note that it might be possible to
do more complex, and more realistic, simulations of ALMA observing using the
Offline Data Processing Package, but this will not be discussed in this
document further.

The Observing Tool creates an {\it observing script} 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 is also 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).  

Most of the functions of the pipeline are under the domain of the 
off-line data processing, and will therefore not be treated in this 
document.  What is needed in our present context is a subset of the 
pipeline which is capable of taking data as it is produced by the EVLA 
and producing real-time images or spectra.  We envision that this is 
effected by a Quick Look Pipeline Tool, which would be a subset of the 
full off-line Pipeline Tool.  The Quick Look Pipeline Tool 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 Quick Look Pipeline Tool then produces images and spectra 
which are made available to the Operator(s) and to the observer(s) as 
well.

The Proposal Tool, Observing Tool, Simulation 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.  The Simulation 
Tool requires an observing script, so the Observing Tool is invoked to 
generate a simple script which is fed into the Simulation Tool.  The 
Simulation Tool then feeds its output into 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 
            transfered (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 Scheduling 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 Program consists of one or more sets of Program
Blocks, which are in turn a set of Scheduling Blocks that are submitted
as a group to the Scheduling Tool for scheduling purposes.  For example,
a Program 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 
      Scheduling 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 Scheduling Blocks produced by the Observing Tool shall
            be human-readable (i.e. not binary) scripts.
            \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 every 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 consist 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}

\fontshape {it}
\selectfont

This section describes the requirements for the EVLA on-line data
processing pipeline. Note that the following observing modes are not
considered in the present version:
\begin{itemize}
   \item VLBI observations;
   \item solar observations;
   \item pulsar observations.
\end{itemize}

We distinguish three different groups of pipeline operations, the 
Real-time Calibration Operations, the Quick Look Operations, and the 
Science Operations. Each of these groups has different functions; they 
should include (but are not limited to):

\fontseries {b}
\selectfont
Real-time Calibration Operations

\fontseries {m}
\selectfont

The Real-time Calibration Operations are performed to process all 
operations that are necessary to avoid the system halting.
\begin{itemize}
   \item[$\circ$] Atmospheric modelling
   \item[$\circ$] Astronomical Calibration
   \begin{itemize}
      \item reduce and archive astronomical calibrations, e.g.:
      \begin{itemize}
         \item[--] bandpass calibration
         \item[--] flux density scale
         \item[--] polarization calibration
         \item[--] antenna gain vs. elevation curves
         \item[--] atmospheric calibration
      \end{itemize}
      \item compute preliminary phase rms and 
         preliminary phase and amplitude calibration 
   \end{itemize}
   \item[$\circ$] Telescope/Array Calibration
   \begin{itemize}
      \item reduce and archive telescope/array calibrations, e.g.:
      \begin{itemize}
         \item[--] pointing
         \item[--] focus
         \item[--] delay
      \end{itemize}
      \item allow use of ``plug-ins'' tools to reduce e.g.:
      \begin{itemize}
         \item[--] baselines measurements
         \item[--] pointing models
         \item[--] holography
      \end{itemize}
   \end{itemize}
\end{itemize}
\vspace{5mm}

\fontseries {b}
\selectfont
Quick Look Operations

\fontseries {m}
\selectfont

The Quick Look Operations are processing data in a fast and/or 
approximate way, in order to allow the EVLA staff and the PI to monitor 
the on-going observations.
\begin{itemize}
   \item[$\circ$] Monitoring
   \begin{itemize}
      \item display subsets of the current properties of the 
         observations and/or array 
   \end{itemize}
   \item[$\circ$] Quick data processing
   \begin{itemize}
      \item works on subsets [channel ranges] or pre-processed data 
         [resampled or integrated]
      \item apply preliminary phase and amplitude calibration
      \item produce and display images (no or simplified deconvolution)
   \end{itemize}
\end{itemize}
\vspace{5mm}

\fontseries {b}
\selectfont
Science Operations

\fontseries {m}
\selectfont

The Science Operations process the data and produce images to be
archived.
\begin{itemize}
   \item[$\circ$] Calibration: process the data acquired during the
      observing session, e.g.:
   \begin{itemize}
      \item bandpass calibration
      \item polarization calibration
      \item final phase and amplitude calibration
      \item flux density scale
   \end{itemize}
   \item[$\circ$] Imaging: process all data of the project; 
      results are preliminary after completion of observing session, 
      final after completion of project
   \begin{itemize}
      \item produce tables of visibilities 
      \item produce and archive deconvolved images 
   \end{itemize}
\end{itemize}

We define the following terms:
\begin{itemize}
   \item {\em Astronomical Source}: any astronomical object or
      position in the sky observed by the EVLA for astronomical
      purposes.  This excludes arbitrary positions observed for
      calibrations (e.g., skydips).
   \item {\em Target Source}: astronomical source whose observation is 
      the goal of the current project.
   \item {\em Calibration Source}: astronomical source observed for 
      calibration purpose. It could be a a point-like source (quasar) 
      or any source with known flux density or structure (including 
      planets) or spectral features (e.g., masers).
\end{itemize}

The term ``calibration'' refers to several types of operations that
have to be performed. We distinguish three categories of calibrations:
\begin{itemize}
   \item {\em Instrumental calibration}: pointing, focus, delay,
      baseline, etc. A fast feedback to the control software is 
      required.  In particular, there are critical calibrations (focus, 
      pointing, delay) which must be executed successfully before 
      telescope operations can resume -- these are the most 
      time-critical and have highest priority.
   \item {\em Calibrations that do not require time interpolation}:
      as the atmospheric calibration, or the bandpass and instrumental
      polarization measurements: each time such an observation is 
      acquired, a certain quantity can be immediately derived and 
      stored, to be applied to all following observations, until a new 
      calibration of that kind is observed.
   \item {\em Calibrations that require time interpolation}: as, e.g.,
      the phase and amplitude calibration: a calibration curve has to
      be fitted using data taken over a range in time. This curve is 
      then applied to target observations that were observed in between
      calibrations.
\end{itemize}

The first two categories are real-time calibration operations, as
described in section~\ref{sec:pl:cal}.

The third category will be handled partly as Real-time Calibration
Operations (for calculating quantitites like phase noise up to a
certain point or as function of time, to assess the data quality and
interact with the Scheduling Tool), partly as Quick Look Operations (for
producing intermediate images), and partly as final Science
Operations.  It will probably be sufficient to include only the simple
methods in the Real-time Calibration and Quick Look Operations, with
more elaborate calibrations occurring in the Science Calibration
Operations.

Finally, we consider in this document that all data are taken and
calibrated in spectral line mode, the continuum measurements being
only the average of observed spectra over a given bandwidth. Similarly,
polarization data are not distinguished, but are included in all
steps, the model that we consider being the processing of one or more
Stokes parameter.

\fontshape {}
\selectfont

%--------------------------------------------------------------------
\newpage
\subsubsection{General requirements} \label{sec:pl:gen} 

\begin{reqlist}
   \item The Pipeline shall be able to process all data coming from the
      array in standard modes designated by the project. It must not
      constitute a bottle-neck in the data flow.
      \priority{1}{C}
      \begin{subreqlist}
         \item Some projects will require unusually high data rates or 
            processing requirements. These may require processing 
            outside of the EVLA system and should be flagged 
            appropriately so they are not processed by the EVLA 
            pipeline.
            \priority{1}{C}
      \end{subreqlist}
   \item The Pipeline shall be data-driven. All necessary parameters 
      will be specified either by the PI/CoIs at the observing 
      preparation stage (science data) or by EVLA staff (telescope 
      calibration).
      \priority{1}{C}
   \item The Science Pipeline shall operate through readable and
      comprehensible data reduction scripts.  
      \priority{1}{C}
      \begin{subreqlist}
         \item These scripts may be automatically generated from 
            templates, on the basis of the observing mode being used 
            \priority{2}{D}
      \end{subreqlist}
   \item The Pipeline shall include automatic flagging of data, to
      bypass data which do not fulfill some given conditions (in terms,
      e.g., of weather conditions, antenna temperature, difference 
      from a running mean or rms, level of interference, etc.) The data 
      must nevertheless be archived, and the flagging must be reversible
      in an off-line data reduction system. 
      \priority{1}{D}
   \item The Pipeline should output and archive a comprehensible
      summary of the operations performed with diagnostic information to
      allow checking of results and a record of the processing. 
      \priority{1}{C}
   \item All pipeline operations shall be supported in the off-line
      data reduction package debugging, technical developments, 
      inspection by qualified EVLA staff. In this mode, both a Command 
      Line Interface (CLI) and a Graphical User Interface (GUI) shall 
      be available. 
      \priority{1}{B}
   \item The Pipeline (especially the Science Calibration and Imaging
      Operations) shall also be runnable at any ``shadow'' archive 
      locations.  Some of the actions described below are not relevant 
      in that case, as the interactions with the dynamic scheduling and 
      with the real-time control system.
      \priority{3}{D}
\end{reqlist}

%--------------------------------------------------------------------
\newpage
\subsubsection{Real-time calibration operations} \label{sec:pl:cal} 

\begin{reqlist}
   \item The Real-time Calibration Operations shall be activated after
      each calibration scan, except during autophasing, where it must
      run during scans.
      \priority{1}{C}
   \item Whenever the results of the Real-time Calibration 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}
\end{reqlist}

\paragraph{Atmospheric Model} \label{sec:pl:cal:atm}

\begin{reqlistthree}
   \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{reqlistthree}

\paragraph{Astronomical calibration: Interferometric Data}
   \label{sec:pl:cal:int}

\begin{reqlistthree}
   \item The Pipeline shall reduce, and store the results for further 
      use in the archive in such a fashion that they are accessible to 
      all users:
      \begin{subreqlistthree}
         \item the temperature scale calibration data, using the 
            Atmospheric Model; in real-time mode, the results must be 
            made available for access by the dynamic scheduling system; 
            they must also be made available to later operations to 
            convert the raw data into temperature scale whenever 
            required.
            \priority{1}{C}
         \item the bandpass calibration data;
            \priority{1}{C}
         \item the instrumental polarization.
            \priority{1}{C}
      \end{subreqlistthree}
   \item For suitable observations of a calibration source, the Pipeline
      shall perform operations that include:
      \begin{subreqlistthree}
         \item compute the rms phase over the observed time and the 
            rms phase change since the last observation of a phase 
            calibrator;
            \priority{1}{C}
         \item compute the antenna efficiencies using the known source 
            flux density;
            \priority{1}{C}
         \item do the previous operations both with and without 
            applying the atmospheric phase correction, and deduce from 
            the comparison whether the atmospheric phase correction 
            improves the results or not; this may involve having 
            performed several observations with different parameters 
            for the atmospheric phase correction;
            \priority{2}{D}
         \item derive amplitude and phase time-dependent variations by 
            fitting smoothed curves (e.g., polynomials or splines) using
            all observations of calibrators since the beginning of the 
            session; fast-swtiching observations shall be supported; 
            this derivation shall be done either per antenna or per 
            baseline or both.
            \priority{2}{D}
      \end{subreqlistthree}
      In real-time mode, these results shall be made available to the
      dynamic scheduling system. They must also be made available to 
      later Science Operations for gain transfer to target sources.
      \priority{1}{C}
\end{reqlistthree}

\paragraph{Telescope/Array Calibration} \label{sec:pl:cal:tel}

\begin{reqlistthree}
   \item The Pipeline must reduce:
      \begin{subreqlistthree}
         \item measurements of the pointing offsets;
            \priority{1}{C}
         \item the focus measurements; 
            \priority{1}{C}
         \item the delay measurements. 
            \priority{1}{C}
      \end{subreqlistthree}
      The results must be archived. They must be made available
      to the real-time control system.
   \item The Pipeline shall have access to additional tools, in
      order to:
      \begin{subreqlistthree}
         \item determine the antenna locations from the observations
            of several calibration sources;
            \priority{1}{C}
         \item determine pointing models from the observations of 
            calibration sources;
            \priority{1}{C}
         \item determine focus corrections from the observations of 
            calibration sources;
            \priority{1}{C}
      \end{subreqlistthree}
      The results must be made available to the real-time control 
      system to update the instrument parameters.
   \item Single Dish data -- The Pipeline must reduce:
      \begin{subreqlistthree}
         \item the pointing measurements;
           \priority{2}{E}
         \item the focus measurements;
           \priority{2}{E}
         \item the skydip measurements;
           \priority{1}{D}
      \end{subreqlistthree}
      The results must be archived. They must be made available to the
      real-time control system. Note however that in most cases these
      determinations will be done interferometrically.
\end{reqlistthree}

%--------------------------------------------------------------------
\newpage
\subsubsection{Quick Look operation} \label{sec:pl:ql}

\paragraph{Monitoring}

\begin{reqlistthree}
   \item Quick Look Operations shall be activated automatically after
      each occurrence of the Real-time Calibration Operations.
      \priority{1}{C}
   \item The results of Quick Look monitoring must be made available
      in summary form to PI/CoIs astronomers of the project, via the 
      Internet. 
      \priority{2}{D}
   \item A Calibration Monitoring Tool shall be available, plotting and 
      archiving in a log file various real-time calibration results, 
      including:
      \begin{subreqlistthree}
         \item the results of the last pointing or focus scan;
         \item the rms phase computed over the last scan and computed 
            over the current session;
         \item the corresponding seeing;
         \item the atmospheric opacity.
      \end{subreqlistthree}
      This tool shall include 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 by the monitoring tool should 
      be reasonably simple, and the plot option should be able to 
      quickly be changed by the staff astronomer/operator.
      \priority{1}{C}
   \item Automatic checks shall be available to detect anomalous or 
      erroneous results, triggering alarms if necessary.
      \priority{1}{C}
   \item The Pipeline shall be able to detect interference, e.g., due to
      communication satellites operating at ar near the observed 
      frequencies, flag the data accordingly, and trigger alarms if 
      necessary.
      \priority{3}{D}
   \item An Array Monitoring Tool shall be available to plot the current
      properties of the array, such as:
      \begin{subreqlistthree}
         \item the $uv$ coverage and dirty beam, integrated over the
            current session;
         \item the thermal noise rms reached since the beginning of the 
            observing session (from theory, using actual system 
            temperatures);
         \item for mosaic observations: the above quantities for each
	    pointing center.
      \end{subreqlistthree}
      \priority{2}{D}
\end{reqlistthree}

\paragraph{Data processing} 

\begin{reqlistthree}
   \item Quick Look Data processing Operations shall be activated
      automatically under given conditions (e.g., after a certain time
      interval, after each scheduling block, if a rms has been reached,
      etc.). It must also be possible to start those operations whenever
      requested by the staff astronomer or operator.
      \priority{1}{C}
   \item The results of Quick Look Data processing must be made 
      available to PI/CoIs astronomers of the project, via the Internet 
%% Check the number ...
      (see requirement 4.0-R9).
      \priority{2}{D}
\end{reqlistthree}

\paragraph{Data processing: Interferometric Data}

\begin{reqlistthree}
   \item The visibilities observed on a target source shall be
      calibrated, using the results of the Real-time Calibration 
      Operations:
      \begin{subreqlistthree}
         \item convert the raw data into flux density, including a 
            factor based on antenna efficiency;
         \item apply the current bandpass calibration;
         \item apply the current amplitude and phase correction (using
	    the scaling factor between the calibration and observing
	    frequencies);
      \end{subreqlistthree}
      \priority{1}{C}
   \item The spectra observed on an astronomical source shall be
      displayed (amplitude/phase or real/imaginary) with various 
      options such as:
      \begin{subreqlistthree}
         \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{subreqlistthree}
   \item The Quick Look Pipeline shall compute the dirty image of
      astronomical sources, using the fastest algorithm possible.
      The resulting maps shall be displayed. The supported observing
      modes should include:
      \begin{subreqlistthree}
         \item normal single-field synthesis;
            \priority{1}{C}
         \item multiple sources observations (``snapshots'');
            \priority{1}{C}
         \item mosaicing;
            \priority{2}{D}
         \item on-the-fly mosaicing.
            \priority{3}{E}
      \end{subreqlistthree}
   \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 
            range, or possibly a velocity range defined by the staff 
            astronomer or operator.
      \end{subreqlistthree}
      \priority{1}{C}
   \item The following calibration modes shall be supported:
      \begin{subreqlistthree}
         \item calibration transfer (including fast switching);
            \priority{1}{C}
         \item self-calibration.
            \priority{1}{C}
      \end{subreqlistthree}
   \item For the observations of point-like, bright sources (e.g.,
      quasars) the Pipeline shall include tools allowing fast data
      analysis in the $uv$ and image planes, in order to check the data
      consistency.
      \priority{2}{D}
\end{reqlistthree} 

%--------------------------------------------------------------------
\newpage
\subsubsection{Science Calibration operations:} \label{sec:pl:sci}
{\red REMOVE THIS SECTION?}

\begin{reqlist}
   \item The Science Calibration Operations shall be activated after
      reaching a break point or at the end of an observing session).
      \priority{1}{D}
   \item The Pipeline shall use all data observed during the session. 
      \priority{1}{D}
\end{reqlist}

\paragraph{Interferometric Data} \label{sec:pl:sci:int}

\begin{reqlistthree}
   \item The Pipeline shall use calibration sources to derive:
      \begin{subreqlistthree}
         \item the bandpass calibration;
            \priority{1}{C}
         \item derive amplitude and phase time-dependent variations by
            fitting smoothed curves (e.g., polynomials or splines) using
            all observations of calibrators since the beginning of the
            session; fast-switching observations shall be supported.
            \priority{1}{C}
      \end{subreqlistthree}
   \item The Pipeline shall check and correct the flux density scale by 
      using observations of sources of known flux density. Any effect 
      due to the source being resolved shall be taken into account.
      \priority{1}{C}
   \item The Pipeline shall calibrate the source observations by 
      applying:
      \begin{subreqlistthree}
         \item the bandpass calibration;
         \item the phase calibration (using the appropriate scaling 
            factor between the calibration and observing frequencies);
         \item the amplitude calibration.
      \end{subreqlistthree}
      \priority{1}{C}
\end{reqlistthree}

\paragraph{Single Dish Data} \label{sec:pl:sci:sd}

\begin{reqlistthree}
   \item The data taken on astronomical sources shall be reduced,
      depending on the observing mode. All EVLA modes (as designated by 
      the project) shall be supported, including:
      \begin{subreqlistthree}
         \item position switch;
            \priority{?}{?}
         \item nutator switch;
            \priority{?}{?}
         \item frequency switch;
            \priority{?}{?}
         \item raster maps using one of the above modes;
            \priority{?}{?}
         \item OTF maps using one of the above modes.
            \priority{?}{?}
      \end{subreqlistthree}
   \item The resulting spectra shall be corrected for a baseline, fitted
      on all spectra channels but a window automatically determined, or
      pre-defined, or defined by the Operator or Staff Astronomer.
      \priority{?}{?}
   \item The Pipeline shall check and correct the flux density scale, 
      using observations of sources of known flux density.
      \priority{?}{?}
\end{reqlistthree}

%--------------------------------------------------------------------
\newpage
\subsubsection{Science operations} \label{sec:pl:ima}

\begin{reqlist}
   \item The Science Operations shall be activated after reaching a 
      monitor break-point defined by the user in the Observing Tool (see
      Section~\ref{sec:ObservingTool}) or at the project completion.
      \priority{1}{C}
   \item The Science Operations shall be routinely completed no later 
      than 24~h (?) after the end of the data acquisition.  There may 
      be special cases for certain observing modes which will take 
      longer.
      \priority{1}{D}
   \item The manipulation of data cubes shall be the default mode of
      operation of the imaging processing. The final product will be
      the deconvolved images.
      \priority{1}{D}
   \item The Science Pipeline must process all data from all standard 
      modes and attach a quality measure to the result.
      \priority{1}{D}
   \item All the data previously obtained since the project has been 
      started shall be available for processing. This includes data 
      obtained in different array configurations, as well as total 
      power data for measurements of zero and short-spacings.
      \priority{2}{D}
   \item The results of the Science Operations must be made available 
      to PI/CoIs astronomers of the project, via consultation with the 
      Archive Operations.
      \priority{2}{D}
   \item The Science Pipeline shall process all data from all standard 
      modes to the highest level of quality, reprocessing older archive 
      projects when necessary.
      \priority{3}{E}
\end{reqlist}

\paragraph{Interferometric Data} \label{sec:pl:ima:int}

\begin{reqlistthree}
   \item The Pipeline shall use calibration sources to derive:
      \begin{subreqlistthree}
         \item the bandpass calibration;
         \item derive amplitude and phase time-dependent variations by
            fitting smoothed curves (e.g., polynomials or splines) using
            all observations of calibrators since the beginning of the
            session; fast-switching observations shall be
            supported.
      \end{subreqlistthree}
      \priority{1}{C}
   \item The Pipeline shall check and correct the flux density scale by 
      using observations of sources of known flux density. Any effect 
      due to the source being resolved shall be taken into account.
      \priority{1}{C}
   \item The Pipeline shall calibrate the source observations by 
      applying:
      \begin{subreqlistthree}
         \item the bandpass calibration;
         \item the phase calibration (using the appropriate scaling 
	     factor between the calibration and observing frequencies); 
         \item the amplitude calibration.
      \end{subreqlistthree}
      \priority{1}{C}
   \item The Pipeline shall find in the archive the calibrated data
      obtained during all previous observing sessions, and check 
      whether the data are compatible with the current dataset (in 
      terms of instrument setup and properties, noise rms, etc.). If 
      not compatible, the data shall not be used together, and the 
      Pipeline shall process only the current dataset.
      \priority{2}{D}
   \item Careful cross checks of the flux density scales between the 
      data sets shall be performed. In case of inconsistancies, the 
      quality measure shall be affected.
      \priority{2}{D}
   \item Direct comparison of the redundant data (obtained 
      simultaneously or not) shall also be performed. In case of 
      inconsistencies, the quality measure shall be affected.
      \priority{2}{D}
   \item The Pipeline shall extract the visibilities with the 
      appropriate frequency resolution, plus the pseudo-continuum 
      measurement if required.
      \priority{1}{C}
   \item The Pipeline shall compute images for each (non-blanked,
      possibly user-specified) frequency channel, as well as for the
      continuum emission if required. This includes gridding the whole 
      data set and computing the Fourier transform, using the most
      appropriate algorithm. Several weightings shall be available
      (including natural, uniform, robust).
      \priority{1}{C}
   \item The images shall be deconvolved using the most appropriate
      algorithm. The algorithms supported shall include:
      \begin{subreqlistthree}
         \item CLEAN and its various flavors;
         \item multi-resolution and multi-scale CLEAN;
         \item Maximum Entropy Method (MEM).
      \end{subreqlistthree}
      \priority{1}{C}
   \item In the case of a complicated imaging problem, it should be 
      possible to have several algorithms running in parallel, the best 
      (according to criteria TBD) image being eventually selected. 
      \priority{3}{E}
   \item Designated observing modes shall be supported, including:
      \begin{subreqlistthree}
         \item normal single-field synthesis;
            \priority{1}{C}
         \item multiple sources and/or multiple frequency setups
            observations (``snapshots'');
            \priority{1}{C}
         \item mosaic observations;
            \priority{1}{C}
         \item wide-field imaging;
            \priority{1}{D}
         \item on-the-fly mosaics;
            \priority{3}{E}
         \item combination of single dish and interferometer data. 
            \priority{2}{D}
      \end{subreqlistthree}
   \item Self-calibration techniques shall also be available to 
      calibrate and image the data.
      \priority{2}{D}
   \item Subtraction of continuum level from spectral data may be
      required. This can be done in both Fourier and image domain. In 
      the case of $uv$-plane subtraction, flexible setting of the 
      frequency channel ranges for the calculation of the continuum 
      level should be available. It shall eventually be possible to 
      make trial subtractions and select the best solution in an 
      automated manner.
      \priority{2}{D}
\end{reqlistthree}

\paragraph{Single Dish Data} \label{sec:pl:ima:sd}

\begin{reqlistthree}
   \item The data taken on any astronomical source shall be reduced,
      depending on the observing mode. All EVLA + Single Dish (e.g.,
      GBT) modes (as designated by the project) shall be supported, 
      including:
      \begin{subreqlistthree}
         \item position switching;
         \item nutator switching;
         \item frequency switching;
         \item raster maps using one of the above modes;
         \item OTF maps using one of the above modes.
      \end{subreqlistthree}
      \priority{1}{C}
   \item The resulting spectra shall be corrected for a baseline, fitted
      on all spectra channels but a window automatically determined, or
      pre-defined, or defined by the Operator or Staff Astronomer. 
      \priority{1}{C}
   \item The Pipeline shall check and correct the flux density scale, 
      using observations of sources of known flux density.
      \priority{1}{C}
   \item The Pipeline shall find in the archive previous observations 
      and calibration data, and check whether the data are compatible 
      with the current dataset.
      \priority{2}{D}
   \item The Pipeline shall then grid the whole data set if the project
      requires imaging. Combination of data observed on diffrent 
      rasters, possibly with different (regular or irregular) spacings 
      shall be supported.
      \priority{1}{D}
   \item Provision shall be taken to allow running appropriate 
      algorithms (deconvolution, destriping), if required by the data 
      or by the experience gained using the EVLA. 
      \priority{3}{E}
\end{reqlistthree}

%-------------------------------------------------------------------
\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 projects 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 script, which 
      describes (in greater detail than is available in the proposal) 
      how the observations are to be completed for the program.

      The observing script 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);
         \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 Schedule
      \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}
