\documentclass[10pt]{article}
\usepackage{EVLADocumentationStandard}
\newcommand{\isotoday}{\space\number\year-{\ifcase\month\or
   Jan\or Feb\or Mar\or Apr\or May\or Jun\or
   Jul\or Aug\or Sep\or Oct\or Nov\or Dec\fi}-{\ifnum\day<10
   0\number\day \else \number\day \fi}}
\newcommand{\simgt}{\raisebox{0.3ex}{$> \kern -1em {\lower 1ex \hbox{$\sim$}}$\thinspace}}
% uncomment the following, and re-make the dvi file, if you
% subsequently want to make a pdf file via dvi2pdf
% \usepackage{times}
%
% --- modifications to the standard LaTeX styles

%
% Page size parameters.
%
\parindent 0pt
\brokenpenalty=10000
\parskip 2mm
%
% requirement numbering and referencing.
%
\makeatletter
\newcounter{reqseci}
\newcounter{reqsecii}[reqseci]
\newcounter{reqseciii}[reqsecii]
\newcounter{reqseciv}[reqseciii]
\newcounter{reqsecv}[reqseciv]
%
\renewcommand*{\thereqseci}{%
   \ifnum\c@subsection=\z@
      \thesection%
   \else
      \ifnum\c@subsubsection=\z@
         \thesubsection%
      \else
         \thesubsubsection%
      \fi
   \fi
   -R\arabic{reqseci}%
   }
\renewcommand*{\thereqsecii}{\thereqseci.\arabic{reqsecii}}
\renewcommand*{\thereqseciii}{\thereqsecii.\arabic{reqseciii}}
\renewcommand*{\thereqseciv}{\thereqseciii.\arabic{reqseciv}}
\renewcommand*{\thereqsecv}{\thereqseciv.\arabic{reqsecv}}
%
\newcommand*{\labelreqseci}{\textbf{\thereqseci}}
\newcommand*{\labelreqsecii}{\textbf{\thereqsecii}}
\newcommand*{\labelreqseciii}{\textbf{\thereqseciii}}
\newcommand*{\labelreqseciv}{\textbf{\thereqseciv}}
\newcommand*{\labelreqsecv}{\textbf{\thereqsecv}}
%
\newcount\@reqdepth \@reqdepth = 0
%
\def\reqlist{%<--can be nested
   \ifnum \@reqdepth >4\relax\@toodeep\else
      \advance\@reqdepth\@ne
      \edef\@reqctr{reqsec\romannumeral\the\@reqdepth}%
      \expandafter\list\csname label\@reqctr\endcsname
        {\usecounter\@reqctr%
         \renewcommand\makelabel[1]{##1\hfill}%<- roll your own
%         \settowidth{\labelwidth}{\csname label\@reqctr\endcsname}%<-ditto
         \setlength{\labelwidth}{5truemm}
         \setlength{\leftmargin}{\labelwidth}%
         \addtolength{\leftmargin}{\labelsep}%
        }%
   \fi}
\let\endreqlist=\endlist
\makeatother
%
% ---COMMAND FOR EVLA PRIORITIZATION
%
\newcommand{\priority}[2]{\par\noindent{\em Priority:~#1}\ {\em Timescale:}~#2}
%
% to hard-code date, fill in next line, e.g.:
%\date{2002-Oct-11}
\date{\isotoday}
\DocumentType{Requirements}
\DocumentNumber{SW-001}
%
\Revision{2.0}
\ContactAuthor{B.\ Butler, S.\ Myers}
\title{EVLA e2e Science\\[3truemm] Software Requirements}
\author{
{\em EVLA Science Software Requirements Committee:}\\
        C. Brogan, B. Butler, C. Chandler, B. Clark, S. Myers, 
        P. Napier, F. Owen, R. Perley, M. Rupen}
\sloppy
\owner{B. Butler, S. Myers}
\keywords{EVLA, e2e, Software, Science, Requirements}
\rhead{EVLA e2e Science Software Requirements}
%

\begin{document}
\maketitle
\newpage
\begin{center}
{\it Change Record}\\[5mm]
\begin{tabular}{|l|l|l|l|l|}
\hline
Revision & Date & Author & Section/ & Remarks \\
         &      &        & Page affected  &   \\
\hline
1.0 & 2002-Sep-09 & S. Myers  & All & Initial Version \\
1.1 & 2002-Oct-11 & B. Butler & All & First Revision  \\
1.2 & 2002-Oct-25 & S. Myers  & All & Second Revision \\
1.3 & 2002-Oct-29 & B. Butler & All & Third Revision, mostly pipeline \\
1.4 & 2002-Nov-06 & B. Butler & All & Fourth Revision \\
1.5 & 2002-Dec-09 & B. Butler & All & First Release \\
\hline
\end{tabular}
\vfill
\verb|$Id: evla_requirements.tex,2002-Dec-09 bbutler Exp bbutler $|

\end{center}
\newpage
\tableofcontents
%---------------------------------------------------------------
\newpage
\section*{Introduction}
\addcontentsline{toc}{section}{\numberline{}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).  It 
should be noted that this document does not apply to software required 
to run the VLA currently, or when operating in the ``VLA-mode'' during 
the transition period.

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

The requirements herein are structured according to the EVLA contract 
with the Data Management Division of NRAO, which is summarized in 
project 10 of the EVLA project book (at:
http://www.aoc.nrao.edu/evla/pbook.shtml).  This contract has 6 
specific areas:
\begin{enumerate}
  \item Proposal submission and handling (section~\ref{sec:Propose});
  \item Observation preparation (section~\ref{sec:ObsPrep});
  \item Real-time observing (sections~\ref{sec:RCalAnal} and 
     \ref{sec:WhatsUp});
  \item Scheduling of sets of observations (section~\ref{sec:ObsSched});
  \item Archiving of observations (section~\ref{sec:Archive});
  \item Pipeline processing including calibration and
     imaging (sections~\ref{sec:QuickPipe} and \ref{sec:DefPipe}).
\end{enumerate}
We have generated EVLA specific requirements in all of these areas to
some degree.  However, there are several areas of the software effort 
that we have not addressed in this document.  These include the offline
data processing (most of the Pipeline processing), proposal handling, 
and requirements based on engineering considerations.  These areas will
be considered in separate documents: {\it EVLA Offline Data Processing 
Requirements}, {\it EVLA Operations Software Requirements}, and {\it 
EVLA Engineering Software Requirements}.  In addition, science 
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 Science Requirements for Real-Time 
Software}.

We stress here that this is a living document, and subject to revision 
at any time by the EVLA Software Science Requirements (SSR) committee.  
The intent is to write down the requirements as completely as possible 
at a given time, but we must retain the ability to remedy oversights, 
reflect changes in philosophy with respect to the software, and react 
to the realities of schedule and budget (via feedback from the e2e and 
EVLA projects).

The prioritizing scheme is described below.  Where possible we have 
made the requirements quantitative, and clearly defined 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 the numbered sections below, we enumerate requirements in a formal 
way; these are grouped in sections corresponding to the main software
components outlined in this 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}
\addcontentsline{toc}{subsection}{\numberline{}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 and submission of proposals are 
contained in a single software ``Tool'' - the Proposal Tool.  This 
tool might also be used to manage the proposals for the observatory, 
but that is an operations decision which is beyond the scope of this 
document.

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

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

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

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

At this point in the information flow, we leave the regime which is the 
responsibility of 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 are collected and archived, they must be retrieved 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 functional equivalent).

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

The Tools described herein all interact with each other.  For instance, 
we imagine a prospective observer invoking the Proposal Tool, and while 
creating the proposal, requesting a simulation of the observation (from 
within the Proposal Tool).  To simulate the observation, the Observing 
Tool is invoked from the Proposal Tool to determine how to actually 
perform the observations.  The data created by the simulation are fed 
to the Pipeline Tool, which reduces the data (e.g., makes a map and 
deconvolves it).  The results are then available in the Proposal Tool.  
The observer then makes a query into the Archive Tool to see if this 
observation has already been done, and if so, may request the data, and 
feed them 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 functional 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}
\addcontentsline{toc}{subsection}{\numberline{}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 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 shall be through {\bf Graphical
   User Interfaces} (GUIs) with only a few exceptions (e.g., the ability
   to type Control Scripts directly into the real-time system when 
   observing in manual mode).
\item The instrument shall be dynamically scheduled on timescales from
   near real time (a few minutes in advance of real time) to several 
   hours into the future, 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 
   or manual 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,
   which will be both automated and easy to change (and use) 
   interactively.
\item Observing descriptions (Program Blocks, Schedule Blocks, and 
   Control 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 an initial 
   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).  The final peak data rate is 5 GB/sec.  The correlator is 
   capable of producing as much as 352 GB/sec!  See Tim Cornwell's 
   {\it EVLA Memo 24} for an analysis of the EVLA processing needs.
\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.
\item It is expected that there will be close and frequent collaboration
   between the e2e programmers and the EVLA SSR committee members during
   software development (on a much shorter timescale than the 9 month 
   formal development cycle for e2e).
\end{enumerate}

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

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

The importance can have the following values:

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

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

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

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

These are the same as the priorities which will be used in
{\it EVLA Data Post-processing Science Requirements}.

%---------------------------------------------------------------------
\newpage
\section{Proposal generation and submission requirements} \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}{C}
      \begin{reqlist}
         \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}{D}
      \end{reqlist}
   \item The proposals shall be submitted electronically and all 
      observer input shall be in digital form.
      \priority{1}{C}
%
% bjb - this is really an operations constraint
%
%   \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}{C}
   \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}{C}
      \begin{reqlist}
         \item This stored version shall be easily transferred (across 
            platforms) between 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).
            \priority{3}{D}
      \end{reqlist}
   \item If the Proposal Tool stores input information on NRAO computers
      for later modification (intermediate stages), then access to that
      information should be restricted via a password generated 
      uniquely for that proposal, emailed only to the author of that
      proposal.
      \priority{1}{C}
   \item Proposals output from the tool shall be readable by the tool. 
      \priority{1}{C}
   \item The Proposal Tool should require input of the following 
      information:%
      \label{req:PropInfoOne}
      \begin{reqlist}
         \item Proposal title;
         \item Proposal author information, including name, institution,
            presence at EVLA for observations, whether the observations
            are for a Ph.D. thesis, and if so, anticipated graduation
            year.  It should be possible to enter this information:
            \begin{reqlist}
               \item via direct input into the tool;
                  \priority{1}{A}
               \item by selection from a database of such information
                  (at least for name and institution);
                  \priority{2}{C}
            \end{reqlist}
         \item An indication of which author is the contact author,
            and contact information for that author, including address,
            phone number, and email address.  It should be possible to 
            enter this information:
            \begin{reqlist}
               \item via direct input into the tool;
                  \priority{1}{A}
               \item by selection from a database of such information;
                  \priority{2}{C}
            \end{reqlist}
         \item References to previous proposals related to this one;
         \item The category of observation, selectable from a list of,
            e.g., solar system, galactic, extragalactic, other;
         \item The type of observation, selectable from a list of, e.g.,
            continuum, spectroscopy, polarimetry, solar, pulsar, 
            mosaicing, other, etc...;
         \item Keywords which apply to the proposal (from a list
            provided by the observatory);
         \item An indication of whether observations from other 
            telescopes will also be necessary (e.g., for combining GBT
            data with mosaiced EVLA data, or for planetary radar), 
            which telescopes are required, whether observing time has 
            already been obtained on them, if so, what are the 
            dates/times, if not, when will it be known;
         \item A short summary (abstract) of the proposed observations 
            and scientific justification, length to be set by NRAO
            management, and enforced by the tool if possible;
         \item An indication of the level of staff help required (e.g.,
            none, light consultation, heavy consultation, staff 
            collaborator);
         \item An indication of whether the data will be reduced at the
            observers home institution or at the AOC;
         \item An indication of preferred dates, or dates that should 
            not be allowed (i.e., prioritization as a function of date).
      \end{reqlist}
      \priority{1}{C}
   \item The Proposal Tool should support source lists.%
      \label{req:PropInfoTwo}
      \begin{reqlist}
         \item The tool should require entry, for all sources, of all 
            fields useful to decide scientific priority and technical
            feasibility.  These include:
            \begin{reqlist}
               \item Common name;
               \item Coordinates;
               \item Requested VLA configurations;
               \item Requested observing frequencies;
               \item Continuum flux density;
               \item Angular size of largest structure;
               \item Required continuum rms (or, equivalently, required 
                  dynamic range);
               \item Requested number of antennas (in the case that
                  subarrays are desired);
               \item Requested time on source (possibly calculated by
                  the tool itself).~\\
            \hspace*{-8truemm} Spectroscopic observations also include:
               \item Line identifications or frequencies;
               \item Requested frequency or velocity resolution;
               \item Requested frequency, velocity or redshift range;
               \item Required rms in a spectral channel;
               \item Flux density at line peak.
            \end{reqlist}
            \priority{1}{C}
         \item The submission tool shall supply a flexible interface for
            importing the source information from another medium, e.g., 
            as an imported file listing the above information.
            \priority{1}{C}
         \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}{D}
         \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}{D}
         \item The submission tool shall allow access to a pulsar
            catalog.
            \priority{2}{D}
         \item The submission tool shall be able to calculate the
            position, distance, size, and flux density as a function of 
            frequency of the Sun, Moon, major planets, satellites, and 
            asteroids (all bodies \simgt 200 km diameter), and be able 
            to insert them into the source list.  Note that at this 
            point, extremely accurate positions are not needed - they 
            are merely a guide to the scheduling committee.
            \priority{2}{D}
         \item The submission tool should allow for entry of orbital
            elements (as a 6 element vector) for other solar system
            bodies, and from those orbital elements, calculate 
            coordinates.
            \priority{3}{E}
         \item A connection to commonly available astronomical databases
            (e.g., the CDS and NED databases) shall be available.
            \priority{3}{E}
      \end{reqlist}
   \item The Proposal Tool should require the input of the scientific
      justification, which should be a single file prepared by the 
      observer in one of a small number of preferred formats (ASCII, 
      PostScript, or PDF).  The allowable size of the scientific
      justification is to be set by NRAO management, and enforced if
      possible by the Tool.%
      \label{req:PropInfoThree}
      \priority{1}{C}
   \item The Proposal Tool shall allow for the input of requirements
      on observing conditions.  These can be in the form of crude 
      indicators (``any'', ``average'', ``good'', ``exceptional'', 
      etc...), a requirement on the specific rms phase of the 
      atmospheric phase monitor, a requirement on the wind speed, a 
      requirement on the opacity, or a specification of ``stringency'' 
      (see Appendix A for a definition of stringency), or combinations 
      thereof.%
      \label{req:PropInfoFour}
      \priority{1}{C}
   \item The Proposal Tool should allow for an indication that a 
      proposal is for Target-of-Opportunity Observations (TOO).%
      \label{req:PropInfoFive}
      \priority{1}{D}
      \begin{reqlist}
         \item The Proposal Tool should allow for an indication of 
            whether this is a Type 1 or Type 2 TOO (Type 1 are 
            relatively common but, in detail, unpredictable phenomena, 
            Type 2 are newly discovered bodies or phenomena and truly 
            exotic events).
            \priority{1}{D}
         \item For Type 1 TOO proposals, the Proposal Tool should allow 
            for an indication of what should trigger the observation.
            \priority{2}{D}
      \end{reqlist}
   \item It should be straightforward to add further input options to
      the tool.
      \priority{1}{C}
   \item The Proposal Tool shall perform certain simple calculations, 
         including:
      \begin{reqlist} 
         \item the integration time required:
            \begin{reqlist}
               \item for a given bandwidth and channel (e.g., velocity) 
                  width;
                  \priority{1}{C}
               \item under poor, average and good observing conditions;
                  \priority{1}{C}
               \item using real observing statistics;
                  \priority{2}{D}
               \item for the measured RFI enviroment;
                  \priority{2}{D}
               \item given sky coordinates, for low frequency (the
                  Tool should know about the distribution of background
                  temperature and confusing sources).
                  \priority{3}{E}
            \end{reqlist}
         \item the calculation of integration time should incorporate
            simple calibration overhead heuristics (TBD).
            \priority{1}{C}
         \item the appropriate configurations needed given desired 
            brightness sensitivity, resolution, and source angular size.
            \priority{1}{C}
         \item the amount of time required to achieve a specified rms
            level, given the specification of required observing 
            conditions (e.g., required phase stability at the specified 
            frequency).
            \priority{2}{D}
      \end{reqlist}
   \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{reqlist}
         \item hardware limitations, including feasibility of using
            the correlator at the requested spectral resolution and
            total bandwidth;
            \priority{1}{D}
         \item data rate/volume;
            \priority{1}{D}
         \item expected data quality;
            \priority{2}{D}
         \item expected stringency limitations (e.g., weather, RFI,
            ionospheric conditions).
            \priority{2}{D}
      \end{reqlist}
   \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.  This might be effected by calling the
      Archive Search Tool (but this is an implementation question).
      \priority{1}{C}
      \begin{reqlist}
         \item The search results should be ordered by relevance.
         \priority{3}{D}
      \end{reqlist}
   \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 a facility to take all of the information
      contained in the proposal (i.e., that described in 
      Requirements~\ref{req:PropInfoOne}, \ref{req:PropInfoTwo}, 
      \ref{req:PropInfoThree}, \ref{req:PropInfoFour}, and 
      \ref{req:PropInfoFive}) and turn it into the proper electronic 
      representation (a PostScript or PDF file) of the hard-copy 
      required by NRAO operations, which can be easily accessed by the 
      user (either by being stored on a local disk, or easily 
      downloaded from an NRAO computer).
      \priority{1}{C}
   \item There shall be a facility to formally submit the proposal for
      consideration by the scheduling committee, i.e., to bundle up
      all information described in Requirements~\ref{req:PropInfoOne}, 
      \ref{req:PropInfoTwo}, \ref{req:PropInfoThree}, 
      \ref{req:PropInfoFour}, and \ref{req:PropInfoFive}, and make it 
      available to NRAO (e.g., via emailing the information directly, 
      or by placing it in a location where it can be easily accessed by 
      NRAO operations staff on an internal computer, and emailing a 
      pointer to its location).  Additional information shall be 
      calculated at the time of submission, and included as part of the 
      Proposal:%
      \label{req:PropSubmit}
      \begin{reqlist}
         \item Submission date and time;
         \item A list of all configurations and wavelengths being asked
            for (this can be compiled by the tool given the 
            information in the source list);
         \item The total time being requested in this proposal (this 
            can be compiled by the tool given the information in the 
            source list);
      \end{reqlist}
      \priority{1}{C}
\end{reqlist}

%---------------------------------------------------------------------
\newpage
\section{Observation preparation requirements} \label{sec:ObsPrep}

{\it 
 These requirements cover the preparation of Program Blocks (collections
 of Schedule Blocks) for submission to the Scheduling Tool by the 
 observer using the Observing Tool.  

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

 We note here that the Observing Tool is extremely important, in that 
 it is the second point of contact for many observers (the first being
 the Proposal Tool), and the first one in which they interact in a more 
 detailed way with the EVLA instrument.  Because of this, it is very 
 important that this tool be robust and easy to learn and use.  We do 
 not want to repeat the experience of OBSERVE and JOBSERVE.

}

\subsection{The Observing Tool}

\begin{reqlist}
   \item There shall be an Observing Tool for the generation of Program 
      Blocks as input to the Scheduling Tool.
      \priority{1}{C}
      \begin{reqlist}
         \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}{D}
      \end{reqlist}
%
% bjb - this is really an operations constraint
%
%   \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}{D}
   \item The Observing Tool shall be able to read in the output from
      the Proposal Tool, and use the information therein to initialize 
      parameters.
      \priority{1}{C}
   \item The output of the Observing Tool shall be a Program Block, 
      which is a set of Scheduling Blocks that are to be considered as 
      an ensemble by the Scheduling Tool.
      \priority{1}{C}
      \begin{reqlist}
         \item The Program Blocks produced by the Observing Tool shall 
            be human-readable (i.e., not binary). 
            \priority{2}{C}
      \end{reqlist}
   \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}{C}
      \begin{reqlist}
         \item This tool shall operate using a GUI;
            \priority{1}{C}
         \item There shall be built-in help capability;
            \priority{1}{C}
         \item There shall be a batch or script mode for automated 
            generation of Program Blocks;
            \priority{1}{D}
         \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 roughly 1 working day of 
            dedicated use, and truly neophyte users (e.g., graduate 
            students in other areas of astronomy) should reach 
            proficiency with an investment not exceeding a few working 
            days of dedicated use;
            \priority{1}{D}
         \item It shall be easy to extend the capability of the Tool,
            for instance by adding more available methods of setting
            up the correlator or by adding further specifications for
            the pipeline reduction.
            \priority{1}{D}
      \end{reqlist}
   \item Program Blocks output from the tool shall be readable by 
      the tool. 
      \priority{1}{C}
      \begin{reqlist}
         \item Program Blocks output from the tool shall contain all of
            the 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{reqlist}
   \item The Observing Tool shall allow its state and intermediate 
      output to be saved and restored at any time. 
      \priority{1}{C}
      \begin{reqlist}
         \item Saved outputs shall (by default) be distinguished by name.
            \priority{2}{A}
         \item It shall be possible to save outputs locally (on the 
            user's home computer).
            \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{reqlist}
   \item The Observing Tool shall include as components tools for: 
      \begin{reqlist}
         \item Observation setup;
            \priority{1}{C}
         \item Hardware setup (including a Correlator setup 
            subcomponent);
            \priority{1}{C}
         \item Calibrator selection;
            \priority{1}{C}
         \item Pipeline data reduction setup;
            \priority{2}{D}
         \item Observation prediction;
            \priority{2}{D}
      \end{reqlist}
   \item The Observation setup component shall:
      \begin{reqlist}
         \item Allow the user to specify which configuration is 
            desired (in the case where a Project is observing in 
            multiple configurations);
            \priority{1}{C}
         \item Allow the user to create and manipulate (add to and 
            delete from) a source catalog derived from:
            \begin{reqlist}
               \item direct entry into the tool;
                  \priority{1}{C}
               \item output from the Calibrator selection component;
                  \priority{1}{C}
               \item user-supplied source lists in ASCII format;
                  \priority{1}{C}
               \item the source list from the proposal;
                  \priority{1}{C}
               \item a list of solar system bodies;
                  \priority{2}{C}
               \item access to standard astronomical catalogs (e.g.,
                  CDS, NED).
                  \priority{2}{C}
             \end{reqlist}
         \item Allow the user to easily construct a {\em Source List} 
            from the source catalog which contains all of the sources 
            to be observed.  Sources in the Source List should be 
            selectable via:
            \begin{reqlist}
               \item interactive selection from the source catalog;
                  \priority{1}{C}
               \item sequential extraction of targets from a list of 
                  sources (e.g., to conveniently schedule survey 
                  programs);
                  \priority{2}{D}
               \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}{D}
               \item on the basis of an image (e.g., from survey 
                  databases, or from the EVLA archive) one shall be 
                  able to define the area to be mapped interactively 
                  (e.g., with a mouse). 
                  \priority{3}{E}
            \end{reqlist}
         \item Allow the user to specify, for each source in the Source
            List:
            \begin{reqlist}
               \item valid time ranges or extents, which can include:
                  \begin{reqlist}
                     \item valid specific date ranges;
                     \item valid specific time ranges;
                     \item valid relative time ranges (relative to the
                        rest of the sources in the Source List);
                  \end{reqlist}
                  \priority{1}{C}
               \item other constraints on when the source may be 
                  observed, including:
                  \begin{reqlist}
                     \item valid hour-angle ranges;
                     \item valid elevation angle ranges;
                     \item valid current observing conditions, including
                        opacity, phase rms, RFI, wind speed, etc...;
                  \end{reqlist}
                  \priority{1}{C}
               \item a hardware setup (via the Hardware setup component,
                  see below);
                  \priority{1}{C}
               \item for target sources, associated ``phase'' 
                  calibrators:
                  \begin{reqlist}
                     \item by denoting calibrator(s) from the Source 
                        List, along with applicable date ranges (in
                        most cases, a single calibrator will be chosen
                        over the entire range, but for moving sources,
                        there will need to be different calibrators on
                        different dates, and in some cases [notably
                        astrometry], multiple calibrators may be
                        desired);
                        \priority{1}{C}
                     \item by denoting a list of possible phase 
                        calibrators, the ``best'' of which is to be 
                        picked automatically by the Scheduling Tool, 
                        based on some heuristics TBD (e.g., ``pick the 
                        brightest one within 5 deg'') - this is useful 
                        for moving sources;
                        \priority{2}{C}
                     \item by denoting a list of possible phase 
                        calibrators, {\it which are to be observed at 
                        the beginning of the execution of the SB}, and 
                        the ``best'' picked, based on some heuristics 
                        TBD;
                        \priority{2}{D}
                     \item by indicating that at the beginning of the 
                        execution of the SB, the sky should be searched 
                        in the area around the source of interest for 
                        the ``best'' calibrator, based on some 
                        heuristics TBD;
                        \priority{3}{E}
                  \end{reqlist}
               \item for target sources and their associated phase 
                  calibrators, a cycle time, and how much time is spent
                  on each source in each cycle (if more than one 
                  phase calibrator is associated with the source, then
                  the ordering of observing must also be specified);
                  \priority{1}{D}
                  \begin{reqlist}
                     \item the ability to indicate that the cycle time
                        should be chosen by the Scheduler at the time
                        of execution of the SB should be provided;
                        \priority{2}{D}
                  \end{reqlist}
               \item a list of antennas which are to be used, to 
                  facilitate subarrays:
                  \priority{1}{C}
                  \begin{reqlist}
                     \item as a list of antenna numbers or pad locations;
                        \priority{1}{C}
                     \item via clicking on desired antennas in a 
                        display showing the pad locations of the 
                        antennas, given the configuration;
                        \priority{2}{C}
                     \item via more complicated heuristics, e.g.,
                        ``all antennas with a functioning Ka-band
                        receiver'', or, ``the 13 antennas with the best
                        pointing'', or, ``the 9 antennas with the best
                        combined $T_{sys}/\eta_a$ at Q-band''.
                        \priority{2}{D}
                  \end{reqlist}
               \item an associated position and velocity.  Note that 
                  the coordinates and velocities must be allowed to be 
                  functions of time, either as parameterized 
                  trajectories, or as tabulated values (to allow for 
                  moving sources).  It should be possible to specify
                  that the position and velocity are unknown (e.g., 
                  for some types of TOO observations).
                  \priority{1}{C}~\\
                  For moving sources, the tool shall be able to 
                  calculate positions and velocities via:
                  \begin{reqlist}
                     \item a built-in ephemeris calculator, for all 
                        solar system bodies \simgt 200 km in diameter 
                        (note that at this point, extremely accurate 
                        positions are not needed - they are merely a 
                        guide to choosing calibrators and for the 
                        Scheduling Tool);
                        \priority{1}{D}
                     \item user input orbital elements (6 element 
                        vector) for other solar system bodies;
                        \priority{3}{E}
                     \item user input solar longitude and latitude.
                        \priority{3}{E}
                  \end{reqlist}
            \end{reqlist}
         \item Check for and report hardware setup conflicts between 
            subarrays, for multiple subarray observing;
            \priority{1}{C}
         \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{1}{C}
            \begin{reqlist}
               \item Allow for user-input standard observing modes to
                  be read from an input file.
                  \priority{1}{C}
            \end{reqlist}
         \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{reqlist}
               \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{reqlist}
         \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{reqlist}
               \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{reqlist}
         \item Provide the capability for the user to specify a minimum
            allowable length of an SB within the PB.
            \priority{1}{C}
            \begin{reqlist}
               \item Allow for an additional constraint on uv coverage 
                  in the case that short SBs are allowed (e.g., ``uv 
                  coverage must be complete except for an allowance for 
                  the existence of small gaps of T duration'', or ``uv
                  coverage is completely unimportant'').
                  \priority{1}{D}
            \end{reqlist}
         \item Provide a warning if ``interfering sources'' are near 
            any target source over the date/time range of interest.
            Such sources are defined as: Sun, Moon, planets, strong 
            sources at low frequency (Cas A, Cyg A, galactic plane, 
            etc...), or others TBD.  If desired, such warnings should 
            be allowed to be turned into date/time constraints attached 
            to the SBs in the PB.
            \priority{3}{E}
      \end{reqlist}
   \item The Hardware setup component shall provide:
      \begin{reqlist}
         \item The ability to specify the integration time for written
            data;
            \priority{1}{C}
         \item The ability to specify solar observing (e.g., if certain
            filters or other special hardware is required);
            \priority{1}{C}
         \item The ability to specify whether autophasing is desired;
            \priority{1}{C}
         \item The ability to specify the receiver band(s);
            \priority{1}{C}
         \item The ability to specify the central observing frequencies
            or velocities (in any of geocentric, LSR, or heliocentric
            velocity frames), or choose from a number of defaults based 
            on band (for continuum) or known line transition, for each
            correlator baseband (or subband).
            \priority{1}{C}
         \item The ability to specify how the velocity (doppler) 
            tracking is to be done (e.g., continuous, per scan, per 
            session, etc...).
            \priority{1}{C}
         \item The ability to specify multiple central observing
            frequencies in different receiver bands, as allowed by the 
            correlator and hardware (e.g., observing simultaneously in 
            C- and Q-bands).
            \priority{2}{D}
         \item Links to a standard provided line catalog (e.g., based on
            the JPL or Lovas line catalogs), in order to facilitate
            selection of less common line transition frequencies.
            \priority{2}{D}
         \item Output which can be fed automatically into the 
            Observation setup component (to be attached to sources in
            the Source List);
            \priority{1}{C}
         \item A Correlator setup subcomponent, which shall provide:
            \begin{reqlist}
               \item The ability to choose a correlator setup from a 
                  menu based on actual hardware setup (e.g., number of 
                  channels, width in Hz), for each central frequency or
                  velocity;
                  \priority{1}{C}
               \item The ability to specify desired total bandwidth or
                  velocity width and channel width in frequency or
                  velocity units (the tool should then display 
                  close available matches in correlator setup parameter 
                  space, and make them available for selection), for
                  all of the central velocities specified (for each
                  baseband/subband so that, e.g., simultaneous 
                  wide- and narrow-band observations can be done, or
                  multiple transitions may be observed at once);
                  \priority{1}{C}
               \item The ability to specify the required polarization 
                  products, for each baseband (and subband);
                  \priority{1}{C}
               \item Pre-configured setups (templates) shall be 
                  available for frequently observed transitions and 
                  standard continuum frequencies for each band;
                  \priority{1}{C}
               \item The ability to choose a correlator setup from a 
                  menu based on observational parameters (e.g., based 
                  on molecular transitions and velocity widths);
                  \priority{2}{D}
            \end{reqlist}
         \item A warning if the combination of center frequency plus 
            correlator setup causes known RFI to be observed.
            \priority{2}{D}
      \end{reqlist}
   \item The Calibrator selection component shall provide:
      \begin{reqlist}
         \item A built-in calibrator catalog;
            \priority{1}{C}
         \item The ability to import calibrators from a user-supplied 
            source list in ASCII format;
            \priority{1}{C}
         \item The ability to directly input calibrators;
            \priority{1}{C}
         \item The ability to select the following types of calibrators,
            based on source location, frequency, and array 
            configuration:%
            \label{req:CalTypes}
            \begin{reqlist}
               \item primary and secondary flux density scale 
                  calibrator(s);
                  \priority{1}{C}
               \item calibrators for tracking time variable complex 
                  gain as a function of time (``phase'' calibrators);
                  \priority{1}{C}
                  \begin{reqlist}
                     \item there shall be a display to show the 
                        distribution of these sources relative to 
                        target source location, with associated 
                        properties (flux density, position accuracy,
                        flux density vs. frequency, etc...), and to 
                        allow for interactive selection of the 
                        calibrators to be used;
                        \priority{1}{C}
                     \item astrometric phase calibrators;
                        \priority{2}{D}
                  \end{reqlist}
               \item reference pointing calibrator(s);
                  \priority{1}{C}
                  \begin{reqlist}
                     \item it shall be possible to select different 
                        reference pointing patterns, either from a menu 
                        (showing, e.g., classical 5-point, triangles, 
                        shifted triangles, the 'Craig cross', etc...) 
                        or via input as an ordered table of offsets and 
                        dwell times;
                        \priority{2}{D}
                  \end{reqlist}
               \item bandpass calibrator(s);
                  \priority{1}{C}
               \item polarization calibrator(s);
                  \priority{1}{C}
               \item focus calibrator(s);
                  \priority{2}{D}
                  \begin{reqlist}
                     \item it shall be possible to select different 
                        focus patterns, either by specifying number of 
                        points, focus distance between points, center 
                        focus, and dwell time per point, or via input 
                        as an ordered table of focus positions and 
                        dwell times.
                        \priority{2}{D}
                  \end{reqlist}
               \item delay calibrator(s).
                  \priority{2}{D}
            \end{reqlist}
         \item The ability to have the tool pick all the appropriate 
            calibrators from the above list automatically, given the 
            type of observation (e.g., flux density and phase 
            calibrators are needed for all, bandpass only for 
            spectroscopy, polarization only as needed), the observing
            band and configuration, and the target source location
            (selection heuristics to be provided by NRAO scientific
            staff);
            \priority{2}{D}
         \item Output which can be fed automatically into the 
            Observation setup component source catalog;
            \priority{1}{C}
         \item The ability to input a description of the sky brightness 
            distribution for any chosen calibrator, either as a FITS 
            image, or a set of CLEAN components;
            \priority{2}{C}
         \item The ability to do any of the above as a function of
            date, attaching the appropriate date range to the 
            calibrator (for moving target sources).
            \priority{2}{C}
      \end{reqlist}
   \item The Pipeline data reduction setup component shall provide:
      \begin{reqlist}
         \item The ability to specify the desired spatial and spectral
            extent of the final image cubes.
            \priority{1}{D}
         \item The ability to specify the desired u-v tapering and
            weighting (e.g., robustness parameter) for creation of the
            final image cubes.
            \priority{1}{D}
         \item The ability to specify the desired frequency or velocity
            selection, averaging, smoothing, etc..., of the final image 
            cubes.
            \priority{1}{D}
         \item A mechanism for the observer to convey intent to
            the pipeline, including at least the following information:
            \begin{reqlist}
               \item How calibrators are to be used (see 
                  Requirement~\ref{req:CalTypes});
               \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{reqlist}
            \priority{2}{D}
         \item A mechanism for the observer to select from a number of
            pre-defined heuristics for pipeline data reduction, for 
            common observing modes (e.g., flag; set flux density scale; 
            compute time variable complex gain from calibrator; compute 
            bandpass calibration from calibrator; apply calibrations to 
            target source; decimate in frequency; loop: image, 
            deconvolve, self-calibrate).  The specific heuristics are 
            TBD.
            \priority{2}{D}
         \item A mechanism for the software to impose constraints on the
            observer's specification of all of the above items.
            \priority{1}{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{reqlist}
               \item after observing session;
                  \priority{2}{D}
               \item at the end of program execution;
                  \priority{2}{D}
               \item when certain sensitivity levels are reached.
                  \priority{3}{E}
            \end{reqlist}
         \item The ability to specify all of the above quantities 
            separately for both the default archive image pipeline, and
            the quick-look pipeline.
            \priority{2}{D}
         \item The ability to specify times at which the quick-look
            Pipeline Tool should be run during execution, e.g., at the 
            end of each SB.
            \priority{2}{D}
         \item An estimate of how long it will take the quick-look
            Pipeline Tool to complete for each requested execution.
            \priority{2}{D}
         \item The ability to specify pulsar dispersion measure.
            \priority{2}{E}
      \end{reqlist}
   \item The Observation prediction component shall be able to:
      \begin{reqlist}
         \item estimate S/N;
            \priority{2}{D}
         \item estimate synthesized beam size;
            \priority{2}{D}
         \item estimate primary beam size;
            \priority{2}{D}
         \item estimate surface brighness sensitivity;
            \priority{2}{D}
         \item estimate range of angular scales well sampled;
            \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}
         \item provide simulated spectra based on physical models and
            given observing parameters.
            \priority{3}{E}
      \end{reqlist}
      {\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 have a ``check'' function, in which 
      it presents expected sensitivities on all target sources, as well 
      as verifying correlator modes, LO setups, etc.
      \priority{1}{D}
   \item The Observing Tool will support specification of science 
      goals (e.g., in the form of source lists from the proposal - see
      Requirement~\ref{req:PropInfoTwo}) in lieu of detailed 
      specification of total time, integration times, configurations, 
      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}{E}
\end{reqlist}

\subsection{Generation of Program Blocks} \label{sec:PBGen}

\begin{reqlist}
   \item The Observing Tool shall divide a Program Block into
      Scheduling Blocks based upon parameters chosen:
      \begin{reqlist} 
         \item by observer input, e.g., by specification of 
            cycle times and counts;
            \priority{1}{C}
         \item automatically, for standard observing modes with 
            ``science oriented'' input (e.g., sensitivity).
            \priority{2}{D}
      \end{reqlist}
   \item The Program Block shall have a timestamp and revision number
      assigned to it upon submission.
      \priority{1}{C}
   \item The observer shall be able to assign the Scheduling Blocks 
      within a particular Program Block a relative priority amongst 
      themselves, to ensure the proper order of execution.
      \priority{1}{C}
      \begin{reqlist} 
         \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{reqlist}
   \item The proposer shall be able to specify what is needed for 
      real-time checking of data quality, including:
      \begin{reqlist}
         \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{reqlist}
\end{reqlist}

%---------------------------------------------------------------------
\newpage
\section{Observation scheduling requirements} \label{sec:ObsSched}

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

 It is envisioned that the Scheduling Tool is a software program (or 
 equivalent), accessed only by the operator and NRAO staff.
}

\subsection{The Scheduling Tool}

\begin{reqlist}
   \item There shall be a Scheduling Tool whose function is to pass a 
      Control Script to the EVLA real-time system to control the 
      telescope.
      \priority{1}{B}
      \begin{reqlist}
         \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.  Note that it is not required that observers be 
            given access to the Scheduling Tool, but operators and 
            NRAO staff must have access to it.
            \priority{1}{D}
      \end{reqlist}
   \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{reqlist}
         \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{reqlist}
   \item The Scheduling Tool shall handle the observing for the EVLA in
      the main modes:
      \begin{reqlist}
         \item {\bf Manual mode:} a facility shall be provided for 
            direct submission of Control Scripts to the real-time 
            system, either from a file, or directly from keyboard 
            input.
            \priority{1}{B}
         \item {\bf Normal mode:} normal EVLA observing shall be 
            dynamically scheduled in quasi-real time based upon the 
            queue of SBs.
            \priority{1}{C}   
         \item {\bf Interactive mode:} a facility shall be provided 
            for the normal dynamic queue to be suspended, and control
            passed over to an observer (e.g., overriding priorities
            in the main queue, or through use of an auxiliary queue) 
            so that the observer can submit a PB or SBs for immediate
            observing.
            \priority{1}{C}   
      \end{reqlist}
   \item The Scheduling Tool shall support observing in multiple 
      subarrays;
      \priority{1}{C}   
   \item The Scheduling Tool should display in a window the current
      status of the queue, including the SB currently being observed,
      the next few scheduled SBs, and SBs currently under consideration
      with high priority.
      \priority{1}{C}
   \item The Scheduling Tool shall have a facility enabling the operator
      or NRAO staff to abort the current SB and interrupt the normal 
      operation of the queue.  Any aborted SB is automatically 
      reinserted into the queue.
      \priority{1}{C}
   \item The Scheduling Tool shall have a facility enabling the operator
      or NRAO staff to modify the priorities of SBs in the queue.  Such
      priority modifications shall always have an associated length of 
      time, which shall be specified at the time of the change (e.g.,
      for the next hour, for the next day, forever).
      \priority{1}{C}
   \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{reqlist}
         \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{reqlist}
   \item The Scheduling Tool shall check submitted Scheduling Blocks for
      correctness, to prevent malformed SBs from being executed.
      \priority{1}{C}
   \item For SBs that indicate so, the Scheduling Tool should be able
      to choose an appropriate calibrator:
      \begin{reqlist}
         \item When the SB is being considered for scheduling, in the
            case that a list of possible calibrators with associated
            dates, or a list of possible calibrators associated with
            a moving source, is provided in the SB;
            \priority{1}{C}
         \item After being chosen for scheduling, if there is an 
            indication that the ``best'' calibrator (either from a 
            provided list, or from an indication that an area of sky
            is to be searched) should be found at the time of observing,
            then the Scheduling Tool should submit a short Control
            Script to the real-time system to initiate this, and use 
            the output from the Real-time Calibrator Analysis Tool to
            make the decision of which calibrator to use, based on a
            set of provided heuristics (TBD).
            \priority{2}{D}
      \end{reqlist}
   \item For SBs that indicate so, the source-calibrator cycle time,
      and amount of time spent on each, should be calculated by the 
      Scheduling Tool, based on current observing conditions (opacity,
      phase stability, etc...).
      \priority{2}{D}
   \item For SBs that indicate so, source positions must be able to
      be inserted after the SB is in the queue.
      \priority{2}{D}
   \item For observations of moving sources, the Scheduling Tool must 
      insert appropriate calibrators into the Control Script (lists 
      with dates are provided in the SB), and must calculate accurate 
      target source position and velocity trajectories based on:
      \begin{reqlist}
         \item an internal ephemeris calculator (for all solar system 
            bodies \simgt 200 km diameter - note that this must be a 
            very accurate ephemeris);
            \priority{1}{C}
         \item provided orbital elements;
            \priority{1}{C}
         \item provided tabulated positions and velocities as a function
            of time (e.g., output from the JPL horizons system);
            \priority{1}{C}
         \item provided solar longitude and latitude;
            \priority{3}{E}
      \end{reqlist}
   \item As SBs are scheduled, feedback to the observers (PIs) shall be 
      the following:
      \begin{reqlist}
         \item A Scheduler web page is maintained which lists priority 
            ranked programs;%
            \label{req:SchedWeb}
            \priority{1}{C}
         \item An email 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{2}{C}
         \item A Project Web page is created (with password or other
            access protection) which gives the current status of the 
            Project.
            \priority{2}{D}
         \item An email 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 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{reqlist}
\end{reqlist}

\subsection{Scheduling Operations}

\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{reqlist}
         \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{reqlist}
   \item The dynamic priority of a given SBs shall be calculated at the
      decision time based upon the criteria:
      \begin{reqlist}
         \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 required 
            observing conditions (e.g., number of functioning antennas,
            phase rms, wind speed, opacity, RFI, solar interference, 
            etc...) are not met or would compromise the observations 
            with the specified observing parameters (including a 
            consideration of whether self-cal will help or not);
            \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{reqlist}
   \item The following criteria will be used in evaluating the 
      Scientific Value of an SB:
      \begin{reqlist}
         \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 elevation, atmospheric opacity and/or 
            ionospheric conditions, current or past RFI environment, 
            and the number of available antennas, is to be considered, 
            not just the time.);
            \priority{3}{D}
      \end{reqlist}
   \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{reqlist}
         \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 or parallactic angle coverage);
            \priority{2}{D}
      \end{reqlist}
   \item Environmental Priority Modifiers include:
      \begin{reqlist}
         \item Current 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 - note that 
            this assumes the availability of this information in the
            Scheduling Tool, which may require auxiliary instruments
            such as an atmospheric phase monitor or a tipper meter, the
            data from which must be treated appropriately [e.g., raw 
            output from the phase monitor is turned into phases vs. time
            which are then used to derive the rms phase at the frequency
            of the phase monitor, which is then used to derive the rms 
            phase at the observing frequency; or raw output from the
            tipper is turned into atmospheric temperatures vs. elevation
            which are then used to derive opacity at the tipper meter 
            frequency which is then used to derive the opacity at the 
            observing frequency]);
            \priority{1}{C}
         \item Current ionospheric conditions (phase rms at the 
            observing frequencies used in the SB - this may require
            processing of raw data from GPS receivers or other auxiliary
            devices to derive the phase rms);
            \priority{1}{C}
         \item Current RFI conditions at the observing frequency (or
            frequencies), if known.
            \priority{1}{C}
         \item Stringency factor: SBs requiring rare conditions may be
            preferred when those conditions occur.
            \priority{2}{D}
         \item Predictions of future observing conditions (far enough 
            into the future to complete the SB), including possibly 
            detailed weather predictions from mesoscale models or as 
            provided by the National Weather Service, if possible.
            \priority{2}{D}
      \end{reqlist}
   \item Depending upon the algorithm chosen for implementation of the 
      system, the following heuristics may also be appropriate to 
      consider for Operational Priorities:
      \begin{reqlist}
         \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}
      \end{reqlist}
   \item Special calibration observations may be required at the 
      beginning and/or end of execution of one or more SBs, which we 
      denote as preamble and postamble blocks.  These are particular
      versions of Control Scripts.  The Scheduling Tool must account
      for these when determining priority, e.g., if a particular SB
      requires long preamble and postamble blocks, that should be 
      factored into the required time to complete the SB, modifying its
      priority.
      \priority{2}{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
\section{Archiving requirements} \label{sec:Archive}

\subsection{Archive Definition}

\begin{reqlist}
   \item There shall be an EVLA archive which stores all data obtained 
      with the EVLA.  This archive shall include:
      \begin{reqlist}
         \item interferometer data taken for any reason (science, 
            testing, calibration);
            \priority{1}{C}
         \item environmental data (e.g., weather data, WVR, APM, GPS);
            \priority{1}{C}
         \item monitor and control data;
            \priority{1}{C}
         \item project data:
            \begin{reqlist}
               \item proposal, PBs, operator logs;
                  \priority{1}{C}
               \item links to papers, related data, etc...
                  \priority{3}{E}
            \end{reqlist}
         \item data products (e.g., calibrated data and images from the
            pipeline);
            \priority{1}{D}
      \end{reqlist}
   \item There shall be an Archive Tool capable of accessing (including 
      searching and retrieving) the information in the archive.
      \priority{1}{C}
      \begin{reqlist}
         \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}{D}
      \end{reqlist}
   \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 have 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}

\subsection{Raw Data}

\begin{reqlist}
   \item The raw data in the archive shall include:
      \begin{reqlist}
         \item raw interferometer data;
            \priority{1}{C}
         \item header information;
            \priority{1}{C}
         \item calibration data, including WVR data (at $\sim 1$s 
            intervals).
            \priority{1}{C}
      \end{reqlist}
   \item All information describing the observation shall be 
      accessible through the header (or an equivalent object).
      \priority{1}{C}
   \item In the presence of irreversible data corrections, flagging, 
      or modifications, such as RFI excision on time scales shorter 
      than the integration time, the archive must be able to store and 
      recognize both the corrected (modified) and uncorrected 
      (original) data.
      \priority{1}{D}
   \item Each scan within the data shall be identified by its type 
      (``phase'' calibrator, target observation, pointing scan, etc...).
      \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}

\subsection{Environmental Data}

\begin{reqlist}
   \item The environmental data in the archive shall include:
      \begin{reqlist}
         \item all measured weather data (e.g., temperature, relative
            humidity, wind speed and direction, barometric pressure);
            \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{reqlist}
   \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 these data with appropriate observation
      periods.
      \priority{2}{D}
\end{reqlist}

\subsection{Monitor and Control Data}

\begin{reqlist}
   \item Monitor and control data stored in the archive shall include:
      \begin{reqlist}
         \item instrumental parameters (pointing model parameters, 
            referenced pointing offsets, antenna locations, 
            transmission delays, subreflector rotation, focus curve 
            parameters, etc...).
            \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{reqlist}
   \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}

\subsection{Data Products}

\begin{reqlist}
   \item Data products stored in the archive shall include:
      \begin{reqlist}
         \item calibrated data (or the ability to generate on-the-fly),
            with the most up-to-date calibration;
            \priority{1}{D}
         \item images/image cubes (or the ability to generate on-the-fly);
            \priority{1}{D}
         \item the pipeline or post-processing 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 history of flux density determinations of calibration 
            sources;
            \priority{2}{D}
         \item catalog information (e.g., flux density, spectral index, 
            source size) extracted from images or data;
            \priority{3}{D}
      \end{reqlist}
   \item Submission of products to the archive shall be controlled.
      \begin{reqlist}
         \item the Pipeline and Calibrator Analysis Tools shall have 
            access to the archive to deposit resulting calibration 
            information (possibly the fully calibrated data, or 
            information on how to obtain it) 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{reqlist}
   \item The submission process shall provide a link between the
      submitted data and the original raw data.
      \priority{1}{D}
   \item Images produced by the pipeline are stored in the archive when
      appropriate:
      \begin{reqlist}
         \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 decision 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{reqlist}
      \priority{1}{C}
   \item Updates to the calibration must be transparently incorporated
      in the archive.
      \begin{reqlist}
         \item The archive should contain all calibrations which are 
            applicable. 
            \priority{1}{D}
         \item The archive should support different versions of the 
            same image, made with differing calibrations, imaging 
            parameters, deconvolutions, or software.
            \priority{2}{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 recomputed based on the new
            calibration.
            \priority{2}{D}
      \end{reqlist}
   \item Quick-look data products are not stored in the final archive by
      default (see pipeline requirements).
      \priority{3}{D}
\end{reqlist}

\subsection{Project Data}

\begin{reqlist}
   \item Project data stored in the archive shall include:
      \begin{reqlist}
         \item all user (observer) input including the project
            proposal;
            \priority{1}{C}
         \item operators log (electronic version);
            \priority{1}{C}
         \item the Program Block as submitted to the Scheduling Tool;
            \priority{1}{D}
         \item all Control Scripts actually executed by the real-time
            system;
            \priority{1}{D}
         \item all Program Blocks, Scheduling Blocks, Control Scripts,
            or any other command submitted to the system (via GUI or
            directly typed in) during interactive or manual observing
            mode.
            \priority{2}{D}
      \end{reqlist}
   \item Submission of Project data to the archive shall be controlled.
      \begin{reqlist}
         \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{reqlist}
   \item The submission process shall provide a link between the
      submitted data and the original raw data.
      \priority{2}{D}
   \item It should be possible for the observer to insert notes into the
      archive related to the project, including observing notes, 
      descriptions of why it was set up as it was, etc... (an 
      ``electronic logbook''.
      \priority{2}{D}
   \item The archive shall include any relevant maintenance forms,
      e.g., detailing problems with receivers during observation.
      \priority{2}{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.
      \priority{3}{E}
   \item The archive shall have the ability to attach references and/or
      links to published papers (e.g., via ADS) that used the data.
      \priority{3}{E}
\end{reqlist}

\subsection{Archive Search Tool}

\begin{reqlist}
   \item There shall be an Archive Search Tool to access the archive.
      \priority{1}{B}
      \begin{reqlist}
         \item The Archive Search Tool shall be operated through 
            a web-based GUI.
            \priority{2}{B}
         \item The Archive Search Tool shall have a CLI to interrogate 
            the archive from scripts or other Tools.
            \priority{2}{B}
         \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{reqlist}
   \item The Archive Search Tool shall operate on supported platforms as
      designated by the project.
      \priority{2}{B}
      \begin{reqlist}
         \item The appearance and operation of the Archive Search Tool
            shall be platform independent.
            \priority{3}{D}
      \end{reqlist}
   \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{reqlist}
         \item An up-to-date and complete Reference Manual for the
            Archive Search Tool functions, operation, and installation.
            \priority{2}{B}
         \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{2}{C}
         \item Interactive context-based help provided in the GUI.
            \priority{3}{E}
      \end{reqlist}
   \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{reqlist}
         \item a technical interface aimed at EVLA staff users of the 
            archive, and for Archive Tool development and debugging;
            \priority{2}{D}
         \item a user-friendly but comprehensive interface aimed at EVLA
            observers and archive users with knowedge of radio astronomy;
            \priority{2}{E}
         \item a user-friendly interface aimed at novice users or 
            astronomers outside the expert radio astronomy community 
            (e.g., casual browsers, NVO users).
            \priority{3}{E}
      \end{reqlist}
   \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{reqlist}\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 Subarray;
         \item Observation mode;
         \item Whether observation is for target or calibration;
         \item Whether the object is a moving source or not;
         \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 Program;
         \item Program Blocks;
         \item Scheduling Blocks;
         \item Control Scripts;
         \item Telescope operator or duty astronomer;
         \item Reduction date;
         \item Data quality (noise level or dynamic range);
         \item A list of observatory supplied keywords;
         \item Other header info.
      \end{reqlist}
      \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{2}{D}
   \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
      a combination of search fields (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{2}{C}
\end{reqlist}

\subsection{Archive Retrieval Tool}

\begin{reqlist}
   \item There shall be an Archive Retrieval Tool to access the archive.
      \priority{1}{A}
      \begin{reqlist}
         \item The Archive Retrieval Tool shall have a CLI to access the
            archive from scripts or other Tools.
            \priority{1}{C}
         \item The Archive Retrieval Tool shall be operated through 
            a web-based GUI (possibly the same one as the Archive Search
            Tool).
            \priority{1}{C}
         \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
            Data Post-processing Package.
            \priority{3}{D}
      \end{reqlist}
   \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{reqlist}
         \item a raw uv data file;
            \priority{1}{C}
         \item header information;
            \priority{1}{C}
         \item environmental data;
            \priority{1}{C}
         \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 cube;
            \priority{1}{D}
         \item other data products;
            \priority{2}{D}
         \item project data;
            \priority{2}{D}
         \item Run the pipeline on raw data with optional input 
            parameters.
            \priority{3}{E}
      \end{reqlist}
   \item For retrieval of raw or calibrated uv data files, optional 
      averaging over time or frequency must be available.
      \priority{2}{D}
   \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{2}{B}
      \begin{reqlist}
         \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{2}{B}
         \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 image (e.g., 10 km/s for 
            Galactic, 300 km/s for extragalactic, centered on the 
            observer-specified rest frequency and tracking velocity).
            \priority{2}{D}
         \item A simple image viewer for the preview image shall be also
            provided.
            \priority{2}{D}
      \end{reqlist}
\end{reqlist}

\subsection{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{reqlist}
         \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{reqlist}
   \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}

\subsection{Proprietary requirements}

{\it Whether data are public or proprietary will usually be decided 
on the basis of the associated proposal, with rare exceptions based 
on the project, on the proposal group, or on an NRAO management 
decision.  The default rules for access will be determined by NRAO 
management.}

\begin{reqlist}
   \item Astronomical data may be public or proprietary.  
      \begin{reqlist}
         \item Technical data and header information shall be freely 
            available;
            \priority{1}{C}
         \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{reqlist}
   \item The enforcement of access control to proprietary data will be
      consistent with EVLA policy.  
      \priority{1}{C}
      \begin{reqlist}
         \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{reqlist}
   \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
\section{Pipeline data processing requirements} \label{sec:Pipeline}

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

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

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

\subsection{Real-time Calibrator Analysis} \label{sec:RCalAnal}

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

\subsection{Quick-look Pipeline} \label{sec:QuickPipe}

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

\begin{reqlist}
   \item The quick-look Pipeline Tool shall be activated automatically 
      under given conditions (e.g., after a certain time interval, 
      after each scheduling block, etc...).  These intervals should 
      be specified in the Observing Tool.  The output from the Tool 
      shall be accessible to operators and observers.
      \priority{1}{D}
   \item It should also be possible to run the quick-look Pipeline Tool 
      whenever requested by the staff astronomer, operator, or observer
      (assuming a reasonable request).  Inputs will be requested 
      (the Pipeline data reduction setup component of the Observing 
      Tool or its equivalent will be executed), and an estimate of the 
      time to complete the requested operations will be given.
      \priority{1}{D}
   \item It should be possible to abort execution of the quick-look
      Pipeline Tool gracefully, including cleaning up of files, 
      killing all spawned processes, etc...
      \priority{1}{D}
   \item The time-lag between when data is collected by the real-time
      system and when it is available to the quick-look Pipeline Tool 
      should be less than 30 seconds.  This may guide a decision on 
      whether data is all archived first, and then retrieved from the 
      archive into the Tool, or fed directly from the real-time system 
      into it (the fear is that the time lag between when data is 
      collected and when it is actually available in the archive could 
      be as long as minutes).
      \priority{1}{D}
   \item The quick-look Pipeline Tool should use the pipeline data 
      reduction parameters as specified in the Observing Tool, including
      the heuristic for data reduction.
      \priority{1}{D}
      \begin{reqlist}
         \item If the quick-look Pipeline Tool is being run on request
            by a person, then that person should be able to modify the 
            pipeline data reduction parameters for that particular run
            of the Tool, i.e., that person should have access to the 
            Pipeline data reduction setup component of the Observing 
            Tool.
            \priority{2}{D}
      \end{reqlist}
   \item The quick-look Pipeline Tool shall be able to process data
      in multiple subarrays.
      \priority{1}{D}
   \item The quick-look Pipeline Tool should apply all flags generated
      by the real-time system, and should include facilities for 
      generating flags based on the data itself, either of calibrators 
      or of data taken on the target object.  This includes recognition
      of RFI.  Flags generated from data taken on the target object
      must be reported to operations.  The setup parameters of the 
      pipeline shall include a list of such facilities to be used, 
      and a selectable level of flagging, e.g., light, nominal, heavy.
      \priority{1}{D}
   \item The quick-look Pipeline Tool should create calibrated image 
      cubes and/or spectra, with the best calibration information 
      currently available, including:
      \begin{reqlist}
         \item conversion of correlation coefficients into flux density,
            including any of the following corrections not already made 
            to the data: Tsys, gain, opacity, Van-Vleck, flux density
            scale;
         \item bandpass calibration;
         \item polarization calibration;
         \item transfer of amplitude and phase correction from 
            calibrator(s) (using the scaling factor between the 
            calibration and observing frequencies if necessary);
         \item WVR phase correction, if desired and available.
      \end{reqlist}
      \priority{1}{D}
   \item The following calibration modes shall be supported:
      \begin{reqlist}
         \item calibration transfer (including fast switching);
            \priority{1}{D}
         \item self-calibration.
            \priority{1}{D}
      \end{reqlist}
   \item The quick-look Pipeline Tool shall always compute the dirty 
      image of astronomical sources when directed to do so (the operator
      or astronomer should be able to select spectra only), using the 
      fastest algorithm possible.  The supported observing modes should 
      include:
      \begin{reqlist}
         \item normal single-field synthesis;
            \priority{1}{D}
         \item multiple source observations (``snapshots'');
            \priority{1}{D}
% bjb - do we really even want this in there?
         \item mosaicing;
            \priority{2}{E}
      \end{reqlist}
   \item The quick-look Pipeline Tool should deconvolve the dirty 
      images, if possible in the short time allowed, using a fast 
      deconvolution algorithm, with minimal controlling inputs.
      \priority{1}{D}
   \item The processing described in the previous requirement shall be 
      done for:
      \begin{reqlist}
         \item the continuum data;
         \item the line-averaged spectra, over a pre-defined velocity 
            or frequency range (defined either by the astronomer or by
            the staff astronomer or operator).
      \end{reqlist}
      \priority{1}{D}
   \item The quick-look Pipeline Tool should allow for a modest number 
      of self-calibration + imaging/deconvolution iterations, if time
      allows.
      \priority{2}{D}
   \item The quick-look Pipeline Tool should complete its execution on 
      a time scale which is reasonable for astronomy decision making 
      (current thinking is a few minutes at most).
      \priority{2}{D}
   \item It should be possible to reproduce any function of the 
      quick-look Pipeline Tool in the off-line data reduction package.
      \priority{2}{D}
\end{reqlist}

\subsection{Default Archive Image Pipeline} \label{sec:DefPipe}

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

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

\subsection{Atmospheric Model}

\begin{reqlist}
   \item Atmospheric modelling shall be available in the Pipeline and
      to the Scheduling Tool.  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{reqlist}
         \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 FTSs, 
            if available;
         \item measured electron content from GPS or other techniques.
      \end{reqlist}
      \priority{2}{D}
   \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{2}{D}
   \item Atmospheric modelling shall be able to provide the conversion 
      factors between WVR data and the water contribution to the 
      astronomical phase in all EVLA bands.
      \priority{2}{D}
\end{reqlist}

\subsection{The Astronomer's ``what's up'' Screen} \label{sec:WhatsUp}

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

\begin{reqlist}
   \item There shall be made available over the internet an astronomer's
      ``what's up'' screen, giving current observational and 
      instrumental information for the EVLA.
      \priority{1}{C}
   \item The following quantities and their time histories (where
      appropriate) shall be able to be displayed via the ``what's up'' 
      screen:
      \begin{reqlist}
         \item current date and time.
            \priority{1}{C}
         \item begin and end time of current scan.
            \priority{1}{C}
         \item source being observed, with frequency or velocity
            (selectable), and position (selectable as sky or 
            azimuth/elevation).
            \priority{1}{C}
         \item correlator setup.
            \priority{1}{C}
         \item surface meteorological parameters (temperature, dew
            point temperature [or humidity], wind speed and direction,
            pressure);
            \priority{1}{C}
         \item auxiliary monitoring device output:
            \begin{reqlist}
               \item Atmospheric Phase Monitor - raw data and related
                  derived quantities (structure function, rms phase, 
                  corner time, exponent);
                  \priority{1}{C}
               \item current opacity estimate for all observing bands, 
                  from either surface data, seasonal estimate, TIPs of 
                  the array itself, separate tipping radiometers, 
                  separate FTS devices, etc...
                  \priority{2}{D}
               \item Water Vapor Monitor byproduct data (e.g., derived
                  precipitable water vapor from WVM data);
                  \priority{2}{E}
               \item RFI monitor (if available);
                  \priority{3}{E}
               \item Atmospheric electron content information (if 
                  available, via GPS, e.g.);
                  \priority{2}{D}
            \end{reqlist}
         \item visibility amplitude and phase, on a specified baseline, 
            over a specified frequency or velocity range, for all 
            polarization products (u, v, and w should also be displayed).
            \priority{1}{C}
         \item array properties, such as:
            \begin{reqlist}
               \item array status (e.g., number of functioning antennas,
                  error flags);
                  \priority{1}{C}
               \item current system temperature on each antenna at the
                  observing frequency;
                  \priority{1}{C}
               \item the $uv$ coverage and dirty beam, integrated over 
                  the current session, for a chosen target source;
                  \priority{2}{D}
               \item the thermal noise rms reached since the beginning 
                  of the observing session (from theory, using actual 
                  system temperatures);
                  \priority{2}{D}
               \item for mosaic observations: the above quantities for 
                  each pointing center.
                  \priority{3}{E}
            \end{reqlist}
         \item results of real-time calibrator analysis output for the 
            current session, including any focus, delay, reference 
            pointing, complex gain, etc..., data.  There should be a 
            variety of options, to control the display parameters, to 
            plot the variation of these results with time, to allow the 
            staff astronomer and operator to monitor one antenna or 
            baseline in particular, etc.  Since it is required that the 
            EVLA staff can efficiently check out the status of ongoing 
            observations, all the plots should be reasonably simple, 
            and the plot option should be able to quickly be changed by 
            the staff astronomer/operator.
            \priority{1}{C}
         \item the (uncalibrated) spectrum observed on an astronomical 
            source (amplitude/phase or real/imaginary) with various 
            options such as:
            \begin{reqlist}
               \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{reqlist}
         \item the resultant image cube and/or spectrum from all 
            quick-look pipeline executions related to the current
            observing session.
            \priority{1}{D}
         \item pulsar information, including:
            \begin{reqlist}
               \item Pulsar name and its current period (calculated for 
                  ongoing observation);
                  \priority{2}{E}
               \item Dispersion measure (provided by astronomer) and
                  derived quantities (dispersion smearing time at 
                  observed frequency/bandwidth);
                  \priority{2}{E}
               \item Time bin configuration, as required by hardware;
                  \priority{2}{E}
               \item A time averaged pulse profile made using time bins.
                  A dispersion correction should be applied to the data.
                  This display could be analogous to the display of 
                  an uncalibrated spectrum, with similar options.  If 
                  pulse-phase dependent trigger(s) is/are generated 
                  (for gating or for driving external hardware), 
                  it/they should be marked.  The zero-phase (as defined 
                  by the provided polynomial) should be marked also.
                  \priority{2}{E}
            \end{reqlist}
      \end{reqlist}
   \item The time-lag between when data is collected by the real-time
      system or produced from the quick-look Pipeline Tool and when it 
      is available to the ``what's up'' screen should be less than 10 
      seconds.  This may guide a decision on whether data is all 
      archived first, and then retrieved from the archive into the 
      ``what's up'' screen, or fed directly from the real-time system 
      into it (the fear is that the time lag between when data is 
      collected and when it is actually available in the archive could 
      be as long as minutes).
      \priority{1}{C}
   \item It should also be possible for the staff astronomer, operator,
      or observer to initiate execution of the quick-look pipeline from
      the ``what's up'' screen (assuming a reasonable request).
      \priority{2}{D}
      \begin{reqlist}
         \item The person initiating the execution of the quick-look
            pipeline should be able to modify the pipeline data 
            reduction parameters associated with the Program Block,
            i.e., should have access to the Pipeline data reduction 
            setup component of the Observing Tool.
            \priority{2}{D}
      \end{reqlist}
   \item There should be a link to the Scheduling Tool web page (see 
      Requirement~\ref{req:SchedWeb}) from the ``what's up'' screen.
      \priority{2}{D}
   \item There should be a link to the Project web page from the 
      ``what's up'' screen (see Requirement~{3.1-R11.4}).
      \priority{2}{D}
\end{reqlist}


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

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

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

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

      An observer submits a proposal to perform a set of observations. 
      At the time of submission, a proposal has associated with it all 
      quantities described in section~\ref{sec:Propose} under 
      Requirements~\ref{req:PropInfoOne}, \ref{req:PropInfoTwo}, 
      \ref{req:PropInfoThree}, \ref{req:PropInfoFour}, 
      \ref{req:PropInfoFive}, and \ref{req:PropSubmit}.

%      After submission, it is assigned a ``synoptic referee rating''.
%
%      If accepted for scheduling, additional information it might be 
%      useful to associate with the proposal 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;
%         \item First observation under this proposal;
%         \item Most recent observation under this proposal;
%      \end{itemize}			

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

   \item[Project:]~\\

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

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

   \item[Program:]~\\

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

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

      The Program Block is a set of Scheduling Blocks (SB).

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

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

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

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

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

      When the observer is notified that their project is approved for
      observing, 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;
         \item A maximum single execution duration of the SB;
         \item A maximum total observing time to be spent using this SB;
         \item The sensitivity goal to be reached by repeated executions;
         \item The maximum atmospheric water vapor 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 A list of dates for which priority modifiers exist
            (either lowering or raising priority);
         \item A list of alternative calibrators, with an indication of
            time range to be used (used, e.g., for moving target 
            sources);
         \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 noted as either a member of the 
      proposal source list or a calibrator.

   \item [Control Script:]~\\

      A script in the language of the on-line computer system directing 
      the EVLA or a subarray thereof to collect data with a specified 
      receiver setup, phase tracking center, and antenna pointing.  The 
      EVLA is operated by having the Scheduling Tool, human operator, 
      or observer pass a Control Script to the real-time computer 
      system.  Specifically, a Control Script contains:
      \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 (although this
            setup may specify more than one receiver/frequency);
         \item A single correlator configuration.
      \end{itemize}

      We note here that there is an implementation choice to be made
      regarding subarrays.  We see at least two ways of allowing for
      subarrays:
      \begin{itemize}\itemsep 0pt
         \item A single SB contains all of the information to define
            all of the different subarrays needed;
         \item Each subarray requires a separate SB.
      \end{itemize}
      In the first case, either an SB must be allowed to spawn multiple
      Control Scripts, or a CS must allow for multiple versions of the
      above quantities (driving pattern, frequency, etc...) within it.
      We do not recommend one over the other, merely point out that
      the implementation of subarray support may require a change in 
      the definitions of Scheduling Blocks and Control Scripts slightly.

      Preambles and postambles are particular versions of Control 
      Scripts, and have several possible functions.  The purpose of 
      these scripts is to collect calibration data for use in the data 
      reduction phase, e.g.:
         \begin{itemize}\itemsep 0pt
            \item Flux density scale calibration;
            \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 [Record:]~\\

      A Record is the minimal amount of data taking that can be
      commanded within a Control Script. 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 would cause
      a Record to be obtained as described by the Control Script. 
      An example of a Record is a single pointing within a holography
      Scan (which might contain several Integrations).

   \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 [Pipeline:]~\\

      A sequence of data reduction operations performed according to a 
      script present at the initiation of Pipeline operation, usually 
      resulting in an image cube.  The script may include conditional 
      operations based on results or conditions generated by individual 
      data reduction operations.  A Pipeline Tool consists of a 
      supervisor to execute such scripts, a collection of standard 
      scripts, and an interface to the archive or the real-time system, 
      from which it may extract the data upon which it operates.

   \item [Stringency:]~\\

      The stringency is formally defined as: $S = t_a / t_p$, where 
      $t_a$ is the total time available for scheduling, and $t_p$ is 
      the time during which the required conditions are met.  So, 
      observations requiring conditions which occur only very rarely 
      have a high stringency, while those which only require average
      conditions would have a stringency of 2, and those which could
      be observed at any time have a stringency of 1.  See Appendix A 
      of the ALMA ASAC report of October 2002 for a complete description
      and study of this quantity for ALMA.

   \item [Real-time System:]~\\

      The software that actually controls the EVLA at the hardware
      level.  This software is designed and implemented by the EVLA
      project personnel.

   \item [On-line System:]~\\

      The portion of the e2e software which directly interfaces to the 
      real-time system software, namely the Scheduling Tool, the 
      Archive Tool, the Real-time Calibrator Analysis Tool, the 
      quick-look Pipeline Tool, the Astronomer's What's Up Screen, and 
      any other required software (for instance, that required to do
      the interfacing).  This software is designed and implemented by
      the e2e project and Data Management division personnel.

\end{description}

%-------------------------------------------------------------------
%\newpage
%\section{Scheduling Block Examples} \label{sec:SBExamples}
%
%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, however, they might be useful templates to 
%provide to the Observing Tool, possibly with the numbers below being 
%default values for the associated parameters.
%
%\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}
