\documentclass[10pt]{article}
\usepackage{EVLADocumentationStandard}
\usepackage{color}
\newcommand {\red}    {\color[rgb]{1,0,0}}

%
\date{2002-09-11}
\DocumentType{Requirements}
\DocumentNumber{SW-001}
%
\Revision{1.0}
\ContactAuthor{Steven T.\ Myers}
\title{EVLA Software\\ Science Requirements}
\author{
{\em EVLA Software Science Requirements Committee:}\\
        S. Myers, B. Butler, C. Chandler, B. Clark, F. Owen, 
        M. Rupen, C. Brogan, R. Perley, P. Napier}
\sloppy
\owner{Steven Myers \href{mailto:smyers@nrao.edu}{(\tt smyers@nrao.edu)}}
\keywords{Requirements, Software, Science}
\rhead{Software Science Requirements}
%
\usepackage{color}
\usepackage[pdftitle={Software Science Requirements},
            bookmarks,bookmarksnumbered,
            a4paper,
            debug]{hyperref}
\usepackage{typehtml}
\newenvironment{reddish}{\red}{}
\SGMLdef<red>{\begin{reddish}}
\SGMLdef</red>{\end{reddish}}
%
% --- modifications to the standard LaTeX styles
%
% Root of Use Cases html files.
% 
%\newcommand{\ucroot}{/home/lucas/ALMA/Software/Analysis/UseCases/}
\newcommand{\ucroot}{/home/sandrock/smyers/VLA/EVLA/}
\newcommand{\htmlinputtarget}[1]{
	\hypertarget{#1}{}
	\htmlinput{\ucroot/#1} }
\makeatletter
\def\HTML@dosrc#1#2{\hyperlink{#1}{#2}}
\def\HTML@doname#1#2{\hypertarget{#1}{#2}}
%
% Change in enumerate because of high nesting in Use Cases.
%
\renewcommand\theenumi{\@arabic\c@enumi}
\renewcommand\labelenumii{\theenumii.}
\renewcommand\theenumii{\@arabic\c@enumii}
\renewcommand\theenumiii{\@arabic\c@enumiii}
\renewcommand\theenumiv{\@arabic\c@enumiv}
\@definecounter{enumv}
\@definecounter{enumvi}
\def\enumerate{
  \ifnum \@enumdepth >5\@toodeep\else
    \advance\@enumdepth\@ne
    \edef\@enumctr{enum\romannumeral\the\@enumdepth}
      \expandafter
      \list
        \csname label\@enumctr\endcsname
        {\usecounter\@enumctr\def\makelabel##1{\hss\llap{##1}}}
  \fi}
\let\endenumerate =\endlist
%
% Page size parameters.
%
\parindent 0pt
\brokenpenalty=10000
\parskip 2mm
\renewenvironment{itemize}
{\list{---}{\itemsep 0pt \parsep 0pt \topsep 0pt} }
{\endlist}
% 
% reqlist environment gives ordered requirement numbers 
% 
\newcounter{req}[section]
\newcounter{subreq}[req]
\newcounter{subsubreq}[subreq]
\newcommand {\rrr}{ \arabic{subsection}.\arabic{subsubsection}.\arabic{paragraph}--R\arabic{req}}
\newcommand {\rr}{ \arabic{subsection}.\arabic{subsubsection}--R\arabic{req}}
\newcommand {\rrs}{ \arabic{subsection}.\arabic{subsubsection}--R\arabic{req}.\arabic{subreq}}
\newcommand {\rrrs}{ \arabic{subsection}.\arabic{subsubsection}.\arabic{paragraph}--R\arabic{req}.\arabic{subreq}}
\newcommand {\rrss}{ \arabic{subsection}.\arabic{subsubsection}--R\arabic{req}.\arabic{subreq}.\arabic{subsubreq}}
\newenvironment{reqlist} 
  {\list{\bf \rr}
  {\usecounter{req}} }
{\endlist}
\newenvironment{reqlistthree} 
  {\list{\bf \rrr}
  {\usecounter{req}} }
{\endlist}
\makeatletter
\def\reqlabel#1{\@bsphack \protected@write\@auxout{}%
  {\string\newlabel{#1}{{\arabic{section}.\arabic{subsection}--R\arabic{req}}
    {\thepage}}}%
  \@esphack}
\def\subreqlabel#1{\@bsphack \protected@write\@auxout{}%
  {\string\newlabel{#1}{{\arabic{section}.\arabic{subsection}--R\arabic{req}.}
  \arabic{subreq} {\thepage}}}%
  \@esphack}
\newcommand{\reqpri}[1]{\par\noindent{\em Priority:~#1}}
\newcommand{\reqprip}[1]{ ({\em Priority:~#1})}
\newenvironment{subreqlist}
  {\list{\bf \rrs}
  {\usecounter{subreq}} }
{\endlist}
\newenvironment{subreqlistthree}
  {\list{\bf \rrrs}
  {\usecounter{subreq}} }
{\endlist}
\newenvironment{subsubreqlist}
  {\list{\bf \rrss}
  {\usecounter{subsubreq}} }
{\endlist}

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

\def\subreqlabel#1{\@bsphack \protected@write\@auxout{}%
  {\string\newlabel{#1}{{\arabic{section}.\arabic{subsection}--R\arabic{req}.\arabic{subreq}}
    {\thepage}}}%
  \@esphack}
%
% ---NEW COMMANDS FOR AUDITING
%
\newcommand{\grade}[1]{\par\noindent{\em Grade:~#1}}
\newcommand{\severe}[2]{\par\noindent{\em Grade:~#1}\ {\em Severity:}~#2}
\newcommand{\comment}[1]{\par\noindent{\em Comments:} #1}
%
% ---end of modifications to the standard LaTeX styles
%
\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& 2002-09-09 & S. Myers & All & Initial Version   \\
\hline
\end{tabular}
\vfill
\verb|$Id: evla_reqirements.tex,2002/09/11 smyers Exp smyers $|

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

This document intends to define science-driven software requirements
of the EVLA project.  Because of the increased capability of this instrument
and 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.  In particular, the goal of end-to-end (e2e) processing 
requires some specifications based on science drivers.  Thus, we will 
plan to combine in the software the high level of automation needed to deal
with the large data rates that will be attained, while for simple projects the
multi-wavelength astronomer with little or no experience of radio techniques
should be able to use the instrument and obtain scientific quality results.

% This is ALMA boilerplate:

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, parametrized
procedures, global variables and arrays. These scripts, once
fully developed and tested, will evolve into the basic observing
procedures of the instrument.

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

Proposal submission will be in two phases, the first before proposal
evaluation, the second to provide information needed for the actual
scheduling and observation. 

We believe that 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). We explain how these two
levels of dynamic scheduling can be implemented and what are the
requirements on software.

The whole real-time system will be under control of a telescope
operator, through a specially designed interface. This must provide
an overview of what observation is occurring, the state of the
instrument, and observing conditions on the site, and should enable
the operator to react to any unexpected event. A general monitoring
interface must be also accessible through the network.

The instrument should produce images, aiming to be final for most
projects, even when projects are spread over several sessions and
configurations, and/or include short/zero spacings.  For this
purpose an on-line pipeline is required.  
For most projects the data pipeline will produce results in a form
suitable for quality evaluation, and astronomical processing,
hopefully leading to fast publication. Uncalibrated $uv$ data will
be archived together with the calibration curves and the resulting
images. The archive should enable fast access to the observing
parameters and full reprocessing of the data set with improved
processing algorithms.

A general requirement is that the various parts of the system should
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.

The first set of requirements are a general set of reqirements on the
EVLA software (\ref{sec:general}).
The EVLA requirements are structured according to the EVLA contract with e2e. 
Thus, we have generated EVLA specific requirements in each of the 6 areas that
Data Management has contracted to do work for EVLA:
\begin{enumerate}
  \item Proposal generation and submission (\ref{sec:propose})
  \item Observation preparation (\ref{sec:preparation})
  \item Observation scheduling (\ref{sec:scheduling})
  \item Data archive (\ref{sec:archive})
  \item Image pipeline (\ref{req:pipeline})
  \item Data post processing
\end{enumerate}
The first five of these are dealt with in this document.  The final area
of Data post-processing is dealt with in a separate set of 
\href{http://www.aoc.nrao.edu/~smyers/evla/evla_offline.pdf}
{EVLA Offline Data Processing Requirements}.  In addition, there are
requirements on the Real-Time software (\ref{sec:realtime}).

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

This document is heavily based upon the 
\href{http://www.alma.nrao.edu/development/computing/docs/joint/0011/ssranduc.pdf}
{ALMA Science Software Requirements and Use Cases} document.

\newpage
\section{Observing Objects}

\label{sec:ObservingObjects}

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. This
is done in the Phase I Proposal Preparation Phase.  A proposal has
uniquely associated with it:

\begin{itemize}\itemsep 0pt
\item  A proposal identification code
\item  A status (eg New, Being Observed, Partially Scheduled, Rejected, etc.)
\item  A title
\item  A list of requested frequency bands
\item  A list of sources, explicit or generic (for large surveys)
\item  A crude technical categorization 
(such as Detection/Mapping, Spectroscopie Line Survey, ...)
\item  A crude scientific categorization 
(such as SolarSystem/Stars/Galaxies/Cosmology) in order to help reviewers
\item  A first author
\item  A contact person and contact information
\item  A staff contact person
\item  An author list
\item  A scientific justification
\item  A synoptic referee rating
\end{itemize}			

It has associated with it an author list, a time request list, and an
 optional source list.

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.

\item[Project:]~\\

When approving a proposal, the observing program committee creates a
project.  The project consists of the approved part of the proposal.

The project refers back to the proposal through the proposal
identification code.  It has associated with it additional
information.

At the discretion of the Program Committee, the proposal may be
split in several projects  with different scientific ratings.

\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).

\end{itemize}

\item[Program:~]~\\

Once a Project has been created, it has to be described by an
observing Program in order to be scheduled. This is the reason for
Phase II Program Preparation.

For the simplest proposals, Phase II may not require observer
intervention, if all the necessary information has been entered at
Phase I.

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

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

The program includes at least one scheduling block and may include
break points.

\item[Break Point:~]~\\

The observer may wish (or be required) to have break points in his
program, to check on progress and be able to interact.  

If so, he/she creates a breakpoint, which refers back to the proposal
through program, project, and proposal identification codes.  It
has associated with it additional information.

\begin{itemize}\itemsep 0pt

\item  A breakpoint identification code 

\item A logical condition required for the scheduling of any SB of the
programme. This condition is a logical expression based on the
execution status of any scheduling block in the program. It must
be ``true'' if no scheduling block has been executed. It must be
``false'' before all scheduling blocks have reached their goals.

\end{itemize}
\item[Scheduling Block:~] (SB)~\\

When the observer is notified that their project is approved for
phase II, they make a set of scheduling blocks.  The division into
scheduling blocks is under the observer's control, but for standard
observing modes, a template is provided, and observers warned that
deviating from 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 An observing script to be executed.

%  \item 
% {\tt Deleted: A maximum repeat count.}

  \item A maximum single execution duration of the SB.

  \item A maximum total observing time to be spent using this SB.

  \item A main target direction, to be used by the scheduler to
evaluate observing priority for the SB. All actual targets must lie
within a limited area around this direction ($\sim$ 5 degrees, TBD).

%  \item Observing scripts for preamble and postamble observations
%  \item Observing scripts for attached pre- and post-calibrations
  \item Required calibration operations (do we want this for EVLA?)

  \item The sensitivity goal to be reached by repeated executions to
  be checked using the nominal radiometry formula,  expressed in $T_{\rm
  A}^*$ units

  \item The maximum water content required for scheduling. Normally
  defaulted from frequency.

  \item  The maximum phase fluctuation (after phase correction) required for
  scheduling.  Normally defaulted from technical characterization,
  frequency and requested angular resolution.

  \item Conditions on the array configuration.

  \item An optional, observer assigned logical condition to be
  satisfied before scheduling. This is used for dependencies between
  SBs.

  \item A maximum pointing error (systematic and random components) including
  wind speed

  \item An optional preferred LST range, and preference for rising
  sources, which may  be used to increase the likelihood of contiguous
  UV tracks, over a system preference for high elevations. 

  \item Status information, including at least:

     \begin{itemize}\itemsep 0pt
        \item The number of successful executions
        \item The integration time, and theoretical rms for each execution
        \item The total integration time, and current resulting theoretical rms
        \item 
              The total array time used so far
	\item Whether the block goals are reached.
     \end{itemize}

\end{itemize}

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

Calibration operations have several possible
functions.  They may collect data for use in the data reduction phase:

  \begin{itemize}\itemsep 0pt

       \item They may do a bandpass calibration on a strong calibrator.

       \item They may do a polarization leakage bootstrap if partial
       calibration or source polarization is known

       \item They may do a polarization orthogonal receiver phase difference 
        determination

  \end{itemize}

\item [Observing Session:~]~\\

The time contiguous execution of one or more scheduling blocks in a
program constitutes an observing session.

%The observing session is a key object for the data processing since
%data taken in a session will have some technical coherence (e.g. no
%receiver tuning inside a session) which allows calibrations to be
%shared for that data.

\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:  for instance pointing and focus scans involve a pattern of
observations.

\item [Observation:~]~\\

An Observation is the minimal amount of data taking that can be
commanded at the script language level. It is highly desirable that
it should be a simple enough element so that the script language may
be used to define the content of scans (at the staff member/expert
level), as a means to develop and debug new observing modes. Ideally
a single generic command could execute any observation as described
by the Observation Descriptor. The Observation Descriptor features:

 \begin{itemize}\itemsep 0pt

   \item a simple driving pattern for each antenna, 

   \item a simple driving pattern for nutating subreflector

   \item a simple driving pattern for the array phase center

   \item a single receiver band

   \item a single frequency or a simple frequency switching pattern

   \item a single correlator configuration

 \end{itemize}

\item [Integration:]~\\

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

\item [Correlator Dump:] ~\\

A Correlator Dump corresponds to the minimum available integration time
output from the correlator backend. In the Project Book this is defined
as 100ms for all products.

\end{description}

\newpage

\section{Requirements}
\label{sec:req}

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

The priorities can have the following four values:

\begin{description}

\item [0] Essential feature: Must be present from the start.

\item [1] Must be there for Shared Risk Science period, when the system is
commissioned to produce meaningful science results.

\item [2] Must be there when the system is widely open for Science as
an operational instrument.

\item [3] Desirable feature for the final, complete system.

\end{description}

These priorities should be reflected in the order of implementation of
the features involved.  Some items recieve a range of priorities indicating
the timescale over which it can be refined after initial deployment.

\comment{STM: Or do we want to specify only the importance of an item?}

\subsection{General Requirements} \label{sec:general}

\begin{reqlist}

\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.\reqpri{2}

\item The EVLA software shall provide simple ways for the staff or expert
astronomers to refine observing modes and develop new ones.\reqpri{0}

\item The expert user/developer shall be able to send direct orders to the
hardware and to basic quasi real-time software through simple
scripts in a Command Control Language. These scripts, once fully
developed and tested, will evolve into standard observing modes.\reqpri{0}

\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.\reqpri{2}

\item All user interaction with the EVLA system shall be through {\bf
Graphical User Interfaces} (GUIs) except for the low level Command
Control Language.\reqpri{1}

\item The instrument shall be dynamically scheduled in near real time 
(a few minutes in advance of real time) to take full advantage of the
atmospheric conditions and of instrument availability.  \reqpri{1}

\item The EVLA final product shall be images for the large majority of
projects.  The data shall be calibrated and processed in
pipelines. \reqpri{1-3}

\item Raw data, monitor data, calibration data, and images will be
archived; archived data shall be easily accessible to the users.
\reqpri{1}

\item The EVLA processing system shall be able to handle the peak data rate
of 20 MB/s.
This corresponds roughly to one million (double-precision complex)
visibilities per second (1.0 MVPS), and one-half million (double-precision)
image pixels per second (0.5 MPPS).  See Tim Cornwell's 
\href{http://www.aoc.nrao.edu/evla/geninfo/memoseries/evlamemo24.pdf}
{EVLA Memo 24} for an analysis of the EVLA processing needs.
\reqpri{2}

\comment{STM: put real numbers here}

\item An Alarm System shall allow hardware and software faults to be
uniquely identified and suppress error cascades. Identification of
the faults shall be available to the operator and used in operating
EVLA. The faults shall be logged and used as input for system
maintenance and for the dynamic scheduling. \reqpri{0}

\comment{STM: is this in the EVLA plans? should it be?}

\item  Poorly behaving system hardware components detected by the data
pipelines will also be managed at the system level; their status will also be
made available to the system maintenance staff and to the dynamic
scheduler. \reqpri{1}

\comment{STM: I don't think the EVLA system will be as integrated as
the ALMA system, so this may not make sense.}

\end{reqlist}

%---------------------------------------------------------------------
\newpage

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

\begin{reqlist}

\item The proposals shall be submitted electronically and all observer input
shall be in digital form.
\reqpri{1}

\item The observer input shall be obtained in two phases: I: prior to
scientific evaluation, and II: after successful scientific evaluation.
\reqpri{1}

\item The same tool ({\bf Observing Tool}) shall be used in both phases, a
subset of input being required at Phase I to judge technical
feasibility and observing time needed; The remaining input
shall be optional at Phase I but required at Phase II to fully
specify the observations to be done.
\reqpri{1}

\item The scientific justification shall be provided (at Phase I) in a
easily printable format (Postscript, pdf, ...), including figures.
\reqpri{1}

\item The science goals should be input into the observing tool at Phase I;
they include: 

\begin{subreqlist}

\item full source identification and coordinates (whatever the size of the
source list).
%unless there are more than 10 sources (in which case the list may be
%replaced by selection criteria).

\item angular resolution and largest structure; 

\item source flux and S/N or rms;

\item line identification or frequencies; 

\item desired velocity resolution;

\item desired dynamic range.

\end{subreqlist}

\reqpri{1}

\item At Phase I the observing tool shall perform certain calculations,
e.g. of integration time required under average conditions, using
velocity width and resolution information, fraction of time available at the
site for the proposal requirements (e.g. required phase stability at
the specified frequency), etc.
\reqpri{1}
 
\item The basic input parameters shall be translated by the tool into
observing mode, configurations, observing time, correlator setup,
... which the expert shall be able to check; he/she will be able to
override all modes and parameters manually. 

\reqpri{2}

\item The tool shall react to user input by giving all sort of warnings 
based on the situation and selected observing mode, including

\begin{subreqlist}

\item hardware limitations \reqprip{1}

\item expected data quality \reqprip{2}

\item expected stringency limitations (e.g. weather efficiency) \reqprip{2}

\end{subreqlist}

\item The tool shall calculate the data rate and the total data
volume for the project.
\reqpri{1}

\item Basic checking for conflicts against a database of already
conducted observations shall be done at time of submission to give
instant warning to the proposer. This database shall also be
accessible for interactive searching prior to proposal writing.
\reqpri{2}
 
\item The tool shall allow storing of intermediate stages to local
disks, to enable trying out different parameter settings.
\reqpri{1}

\item The proposer shall specify what is needed for real-time
checking of data quality. This may include choosing a standard calibrator as a
{\em test source} to be observed with a short integration time and mapped, in
order to better assess the validity of the amplitude and phase
calibrations. The system shall optionally automatically choose a
test source at execution time.
\reqpri{1}
 
\item The proposer shall be able to define breakpoints after which
observations shall be stopped and only resumed (possibly in modified
form) after examination of the data obtained so far by the
proposer. Breakpoints shall be settable in terms of project goals:
e.g. fraction of targets observed, given rms or S/N.  
Observations after the breakpoint will have to stay within the project scope,
as defined in the observing proposal and accepted by the reviewers.
\reqpri{1}

\item The observing programmes shall be divided into scheduling
blocks either automatically (for standard observing modes) or from
expert observer input.
\reqpri{1}

\item For complex programmes with several different scheduling
blocks the observer shall be able to set up dependency rules between
these scheduling blocks.  

The dependency rule for a scheduling block shall be a logical
expression involving the execution status parameters of one or
several among the other scheduling blocks in the programme:

\begin{subreqlist} 

\item SB execution started

\item SB execution failed 

\item SB execution successfully terminated 

\item number of SB executions 

\item SB sensitivity reached 

\end{subreqlist} 

There shall be at least one SB in the programme with a dependency
rule that evaluates as {\tt false} (i.e. SB is independent) when the
program is started.

\reqpri{2}

\end{reqlist}

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

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

The Observing Tool is mainly used at Proposal Preparation and for
interactive observing. It is the main interface to EVLA for the
general user.

\begin{reqlist}
 
\item  The Observing Tool shall integrate as components: 

\begin{subreqlist}

\item observation setup \reqprip{1} 

\item correlator setup \reqprip{1}

\item data reduction setup \reqprip{2}

\item observation simulation \reqprip{2}

\end{subreqlist}

\item The Observing Tool shall only require {\em specification of science
goals} as input (see above).
\reqpri{1}

\item The Observing Tool shall be able to produce a human-readable
observing script that can be directly executed, or used as an input
for further development.  \reqpri{1}

\item The Observing Tool shall allow the user to easily construct a {\em
Source List} of coordinates and velocities by accessing standard
astronomical catalogs (CDS, NED). That Source List shall be editable
and re-usable for further submissions. \reqpri{1}

On the basis of a map (from survey databases, or from
databases of previous observations) one shall be able to define the
area to be mapped interactively with a mouse. 
\reqpri{2}

\item The Observing Tool shall allow sequential extraction of targets
from a list of sources to conveniently drive survey programs.
\reqpri{2}

\item The Observing Tool shall provide to the user a list of standard
observing modes that may be used to achieve the science goals, so
that he/she may choose the most efficient of the list.
\reqpri{2}

\item For the selected standard observing mode the Observation setup
component shall offer for all parameters sensible defaults deduced
from the science goals, making these parameters unnecessary to
manipulate for the general user. Some parameters (loop cycle times,
integration times) may be selected to be automatically calculated at
run-time depending on actual weather, phase fluctuations, pipeline
results.
\reqpri{1}

\item Projects shall be allocated a level of sensitivity under the
requested atmospheric conditions, rather than a fixed amount of
observing time. However, a hard limit on the total integration time
shall be set for each project to avoid an overflow due to
misestimated sensitivity, and some projects may be only allocated a total
integration time.
\reqpri{1}

\item The Correlator setup component shall provide a Spectral view and a
Hardware view.  The Spectral view is oriented toward the observation
and allows selection of spectral windows based on molecular
transitions. The Hardware view gives the details of the actual
hardware setup. The correlator setup component acts as a translator
between these two views; both can be visible at the same time with a
split screen if desired (see e.g. the BIMA and SMA setup
programs). It shall be possible to use the component as an aid in
rough sensitivity calculations. Pre-configured setups shall be
available for frequently observed transitions.  The spectral windows
shall be graphically movable, reflecting hardware constraints.
\reqpri{2}

\item The correlator setup component shall be linked to existing line
surveys for a variety of sources, to be able to place correlator
units visually at interesting regions, or to simulated
spectra\reqprip{3} based on physical models. This means a line
database (such as the JPL catalog) shall also be linked to the tool.
\reqpri{2}

\item The observing tool shall be able to run a simulator component 
(see Section \ref{sec:simulator}) to: \label{p:simulator} 

\begin{subreqlist}

\item estimate S/N \reqprip{2} 

\item produce dirty beams \reqprip{2}

\item for suitable source models, simulate maps with the desired
array configurations  \reqprip{2}

\end{subreqlist}

\item The observing tool shall allow its  state and intermediate output to be
saved and restored at any time. Saved outputs shall be local.
Saved outputs shall be distinguished by name and easy to use as
templates.\reqpri{1}

\item Based on the simulation the Observing Tool shall
estimate 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 ('monitor points'), for instance:

\begin{subreqlist}

\item  every time a given amount of integration time is obtained.

\item  after observing session

\item  after each breakpoint (if any).

\item  only at the end of program execution

\end{subreqlist}

\reqpri{1}

\end{reqlist}

\subsubsection{Simulation} \label{sec:simulator}

Capability of simulating all EVLA modes of observation is needed
for planning observations (with the Observing Tool), and
comparison of data with models (in data reduction, e.g. in
order to test data reduction procedures and their reliability).
Various levels of complexity and speed of execution will be
necessary.

The data reduction related components of the simulator are given
in the Simulation section of the Offline Data Processing Requirements.

\begin{reqlist}

\item A primary use of the EVLA simulator is to provide guidance
during the proposal and schedule preparation phases. As
such, it is critical that the relevant parts of the
simulation software be compatible with the Observing Tool,
preferably integrated seamlessly into its interface.
\reqpri{1}

\item It shall be possible to compute simple expected sensitivity
levels, dirty beams, and dynamic ranges, given the basic observing mode
parameters (including integration time, bandwidths and spectral resolutions,
array configuration, mosaicing strategy, atmospheric quality limits), used for
proposal and schedule preparation. It shoud be possible to compute the
integration time from a required sensitivity.  Timescale for execution
should be 0.1-5 minutes and should not require significant 
computational resources.  
\reqpri{1}

\item The sensitivity calculation shall be available to the
users through the Observing Tool at Proposal Preparation
stage.  
\reqpri{1}

\item It shall be possible to compute simple expected sensitivity
levels, dirty beams, and dynamic ranges, given the basic observing mode
parameters (including integration time, bandwidths and spectral resolutions,
array configuration, mosaicing strategy, atmospheric quality limits), used for
proposal and schedule preparation. It shoud be possible to compute the
integration time from a required sensitivity.  Timescale for execution
should be 0.1-5 minutes and should not require significant 
computational resources.
\reqpri{1}

\item Data simulation shall be available to the general user at
proposal preparation stage. In that case the data will
be simulated according to the needs of the observing program,
translated into observing parameters by the Observing Tool.  
\reqpri{1}

\end{reqlist}

%---------------------------------------------------------------------

\newpage

\subsection{Observation scheduling} \label{sec:scheduling}

%\subsection{Major requirements}

\begin{reqlist}

\item EVLA observing programs shall be dynamically scheduled in
quasi-real time. 
\reqpri{1}

\item The observing programs shall be split into Scheduling Blocks (SB); the
execution of an SB shall not be interrupted by the scheduling process
(though possibly through an error condition or manual intervention).  
A 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.
\reqpri{1}

\item The rating of all possible SBs shall be evaluated at the end of SB
execution and the best rated SB shall be executed. That rating will
depend on:

\begin{subreqlist}
  
\item Science rating 
  
\item source visibility, and remaining visibility time  in current transit
  
\item preferred LST

\item UT (for ephemeris dependent projects)
  
\item elapsed UT since previous execution (for monitoring projects,
e.g. observe a given source about every week)  

\item system noise (including atmosphere) averaged over antennas, to
define sensitivity
  
\item synthesized beam size and ellipticity, and required resolution 
  
\item phase noise at observing frequency, to define calibration feasibility
and dynamic range 

\item seeing parameter 
  
\item SB interdependency rules (see 3.0-R15)
  
\item breakpoint reached or released

\item total time limit, noise limit, SNR limit reached ? 
  
\item Programme execution status (started, approaching completion,
currently on the telescope ...)

\item SB execution time

\item Preamble/postamble execution times

\item Hardware availability and status (from quality control)

\item Stringency factor: SBs requiring rare conditions should get a 
preference whenever these conditions do occur.

\end{subreqlist}

The scheduling algorithm must be tuned for optimum overall
efficiency, and agreement with observatory policy, according to the
distribution of program requirements and the weather statistics on the EVLA
site. The ordering of programs according to scheduling probabilities should
match that of science ratings, in each range of observing conditions.

\reqpri{1}

\item Fully interactive observing shall be available 
(as a special case), using the whole array or a sub-array (when justified).  
\reqpri{1}

\item  A manual mode shall be available to the staff (as a special case), 
for testing new observing procedures, by sending commands directly to the
observing system, using the whole array or a sub-array \reqpri{0}

\item The time-contiguous execution of one or more SBs of a given
program may be started by a special setup SB (or a preamble block), 
and ended by a final SB (or postamble block). These are needed to 
ensure proper execution (instrument setup, choice and flux measurements of
phase and amplitude calibrators) and calibration (bandpass, phase, ...)
\reqpri{1}

\item Pipeline results from the astronomical targets themselves (for
instance, test point sources) can be used  in computing scheduling
block priorities.  \reqpri{3}

\item It shall be possible to run the scheduler off-line using recorded historical weather data, or model atmospheric data, as input.  
\reqpri{1}

\item As SBs are scheduled, feedback to the observer (PI) shall be the
following:

\begin{subreqlist}

\item An e-mail is sent to the PI when the first of his/her SBs gets
for the first time into the top $\sim 10$ ranked ones, 
as an announcement of approaching execution (but not a guarantee, the weather
being not easily predicted)

\item An e-mail is sent to the PI when the first of his/her SBs is 
executed for the first time

\item At this point, a Web page is created (password-protected) that
will be updated at regular intervals (e.g. each SB, or $\sim 10$min
whichever the greatest). This includes the quick look image,
quality check information from the quick look pipeline, and general
execution status of the programme.

\item An email is sent at the end of each session (either due to a
change in scheduling or a breakpoint status).

\item A final email is sent at the end of the project (when all the
data are archived and available).

\end{subreqlist}

\reqpri{1}

\end{reqlist}

%-------------------------------------------------------------------

\newpage

\subsection{Archiving} \label{sec:archive}

\subsubsection{Introduction}

\begin{reqlist}

\item The archive enables astronomers and engineers to access 
 and use data which has been obtained with EVLA, regardless of where the
information physically resides.  When requested, the archive shall let a user
know the list of available data. 
\reqpri{0}

\item The archive contains the observational data and the technical and 
environmental data.
\reqpri{1}

\end{reqlist}

\subsubsection{Archive of Observational and Technical Data}

\begin{reqlist}

\item The archive shall include raw data, header information,
calibration data, and images produced by the pipeline.
\reqpri{1}

\begin{subreqlist}

\item Not only scientific observations but also technical test observation
and measurements shall be archived to allow the system check.  By
default, all data taken by the array is archived.
\reqpri{1}

\item The quick-look data is not stored in the final archive by
default (see requirements for quick-look and scientific
imaging pipelines).
\reqpri{1}

\end{subreqlist}

\item The archive shall also include:

\begin{subreqlist}

\item all user (observer) input including the scientific justification of the
project

\item high-level observing scripts as they have been used to obtain the data

\item the low-level actual observation descriptors
which are made by expanding the high-level observing scripts and
(time-variable) instrumental/environmental parameters

%\item technical data relevant to data reduction (cf. 3.7.3-R2)

\item the pipeline or offline software versions and data reduction scripts

\item dataquality information (e.g. noise level and dynamic range, based
on pipeline results)

\item whether the observational data is scientifically meaningful or not (This
is to allow a user to eliminate test observation for technical purpose, e.g.,
out-of-focus astronomical observation, etc.) 

\item catalogs of line data or calibration sources, which are to be used in
observations 

\item all measured environmental data

\item the water vapor radiometric raw data (at $\sim 1s$ timescale)
 
\item all monitored data

\end{subreqlist}

\reqpri{1}

\item In case of irreversible on-line data corrections such as the
atmospheric phase correction on time scales shorter than the
integration time, the default action is to archive both the corrected
and the uncorrected data.  
\reqpri{1}

\item A user or staff member may submit the results of off-line reduction
and imaging for attachment to the archive.  Other data products, such
as the scientific paper resulting from the observations, or catalogs
derived from the data, might also be attached to the archive at a
later date.  The submission process should have the function
to make a link from submitted data to the original raw data or dataset
for effective use of these data by archive users.
\reqpri{2}

\item All information describing the observation should be accessable through
the header.
\reqpri{1}

\item The observational raw data shall be archived (in the accessible
archive) as soon as practical after they are taken, and the results from the
Science Pipeline shall be archived after it runs.
\reqpri{1}

\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
\reqpri{1}.

\item The principal archives should be easily accessed by users from all
EVLA partners and major collaborators
\reqpri{2}. 

\item There shall be a backup for the archive to protect the data from 
catastrophic failure and loss.
\reqpri{1}

\item The data within each scan shall be identifiable by its goal (phase
calibrator, target observation, pointing scan ...)
\reqpri{1}

\item The archive shall provide, in the observation header, the appropriate
links to all technical data available for the observation period. This link
is in addition to the set of technical data that is provided in the header.
reqpri{1}

\item Images produced by the pipeline are stored in the archive when
appropriate:

   \begin{subreqlist}

   \item For long integrations or large numbers of channels, the images
   are stored in the archive.

   \item For short integrations or small datasets, images shall be
   generated on-the-fly from the visibilities upon extraction from
   the archive.

   \item The break point between image storage and on-the-fly extraction
   shall be determined by the computing capability of the archive
   extraction pipeline, and may evolve with time.

   \end{subreqlist}

\reqpri{1}

\item Updates to the calibration must be transparently incorporated
in the archive. \reqpri{1}

   \begin{subreqlist}

   \item The archive should provide the most up-to-date
    calibration by default. \reqprip{1}

   \item The archive should contain all calibrations which are applicable. 
   \reqprip{1}

   \item If recalibration by using better calibration algorithm and/or
   better calibration data is recommended by the EVLA, then the stored image
   will be recalibrated \reqprip{1} 

   \item If recalibration is made by the EVLA, then the old calibrated image
   will be also stored in the archive system. 
   \reqprip{2}

   \end{subreqlist}

\item The archive shall include all technical/environmental data measured
by the EVLA system (including times when the array was not observing).
Each item shall contain a time-stamp.
\reqpri{1}

%\item
%  The technical archive shall include:
%\begin{itemize}\itemsep 0pt
%
%  \item environmental data (e.g. weather data)
%
%  \item the water vapor radiometric raw data and derived pathlength correction%%,
%   on $\sim 1s$ timescale
%
%  \item the monitor data
%\end{itemize}
%\reqpri{1}

\item  The archive shall store all high- and low-level scripts, 
not only of the Dynamic Scheduler
but also of interactive observing or other manual operation, 
whether they are made during observation or not.
\reqpri{1}

\item The archive shall include an electronic logbook to record
the notes of the observer and/or telescope operator.
\reqpri{1}


\end{reqlist}

\subsubsection{User Interface}

\begin{reqlist}

\item The archive shall be accessed through a web-tool GUI, the {\bf Archive
Search Tool}, on the internet. 
\reqpri{1}

\item A CLI must be available to interrogate the archive from scripts. 
\reqpri{1}

\item The Archive Search Tool shall allow searching the observation
database to see if observations have been previously done. It shall also be
used as a front end to the {\bf Data Extractor Tool}, which manages the data
extraction and delivery.
\reqpri{1}

\item The Archive Search Tool shall operate on supported platforms as
designated by the project.
\reqpri{1}

\item Comprehensive help facility shall be provided for the Archive Search
Tool. 
\reqpri{2}

   \begin{subreqlist}

   \item Interactive context-based help shall be provided in the GUI.
   \reqprip{2}

   \item An introductory cookbook, including examples, shall be
   provided to let a user know how to utilize database efficiently
   or how to do data mining by using the archive. 
   \reqprip{1}

   \end{subreqlist}

\item The Archive Search Tool shall have two interfaces: one mainly 
for astronomical product production; one mainly for technician use.
\reqpri{2}

\item The search criteria shall include all the information in the
observation headers, including any information pointed to in
sub-headers. Search criteria based on combination of search fields
should be possible (e.g. time * bandwidth).
They shall include (but not be limited to):

\begin{subreqlist}\itemsep 0pt

  \item Object name

  \item Position on the Sky (Equatorial, Galactic, Ecliptic coordinates)

  \item Hour angle

  \item Elevation

  \item Observation Date

  \item Integration Time

  \item Molecular transition

  \item Frequency

  \item Array Configuration

  \item Observation mode

  \item Whether observation is for target or calibration

  \item Angular resolution

  \item Spectral resolution

  \item Weather condition
 
  \item Name of Principal Investigator

  \item Project name

  \item Project number

  \item Title of the proposal

  \item Observing Programs (OPs)

  \item Scheduling Blocks (SBs)

  \item Telescope operator or Astronomer on Duty

  \item Reduction date

  \item Data quality (noise level or dynamic range).

  \item Other header info

\end{subreqlist}
\reqpri{1}

\item Regular expressions including wild card and ranges 
shall be available in search.
\reqpri{1}


\item The search criteria used for database search shall be shown 
with search results and shall be able to be modified.
reqpri{2}

\item For the Archive, the Data Extractor Tool shall receive the information 
from the Archive Search Tool to identify data, and return information
such as:

\begin{subreqlist}

  \item A raw data file, with averaging in time or frequency \reqprip{1}

  \item A reduced image \reqprip{2}

  \item Run the pipeline on raw data with optional input parameters \reqprip{3}

\end{subreqlist}

\item  A preview image (e.g. a small image cube) of the data found in
the search shall be made available before actual data transfer.
\reqpri{1}.

   \begin{subreqlist}

   \item  The preview image cube of the images and dirty beams shall be made
   either on-the-fly upon request or produced by the pipeline in advance
   (using the same criteria as for full images).
   \reqprip{1}

   \item If a user requests a preview image without specifying
   the frequency/velocity information in the line data search,
   the Data Extractor Tool shall provide a sensible default
   velocity integrated intensity map (e.g. 10 km/s for Galactic, 300 km/s
   for extragalactic, centered on the observer-specified rest frequency
   and tracking velocity, or the intensity-weighted velocity of
   the detected line emission from the pipeline). \reqprip{1}

   \item A simple image viewer for preview image shall be also provided.
   \reqprip{2}

   \end{subreqlist}

\item An archive user shall be able to browse all of the header information for
requested data. 
\reqpri{1}

\item An archive user as well as the Dynamic Scheduler, shall be able to use
calibration data immediately after the calibration observation. 
\reqpri{1}

\item The Archive Search Tool shall attach a persistent link info 
to external archives and catalogs (e.g. DSS image) of the corresponding sky
area, and to published papers e.g., ADS if available, that used the relevant
data, upon request.
\reqpri{2}

\item The Data Extractor shall be able to accept (properly verified) 
web-based search and extraction requests.
\reqpri{1}

\item The Data Extractor Tool shall be invoked from the Offline reduction
package (cf. OL-3.8-R1 to R3 of the Offline Requirements document).
\reqpri{1}

\item The archive user can select network transfer or the physical data
delivery (disk/tape) for data retrieval.
The Data Extractor 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.
\reqpri{1}

\item If an archive user requests a disk file transfer operation, 
then the Data Extractor 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.
\reqpri{1}

\item In any EVLA supported data transfer method, the data shall be delivered
to a user within the EVLA project defined maximum time.
\reqpri{1}

\item The Archive Search Tool shall use login identification to secure
access to proprietary data.  All information in the archive catalog tables
(header data) should be accessable to any qualified user.
\reqpri{1}

\end{reqlist}

\subsubsection{Relationship with the Virtual Observatory Projects}

\begin{reqlist}

\item The archive shall be designed to meet the requirements, if practical, 
for on-going virtual observatory projects so that the EVLA data can be used
more efficiently. 
\reqpri{2}

\item Whatever the final shapes of virtual observatories become,
the EVLA archive system shall be able to provide the basic elements:

\begin{subreqlist}

   \item  the archived image
   \reqprip{1}

   \item  catalogues derived from the archive, if available 
   \reqprip{1}

   \item image quality information for archived images
   \reqprip{1}

   \item data quality information for selected observations
   \reqprip{1}

   \end{subreqlist}

\item The interface shall be designed to meet the requirements for virtual
observatories. This assumes that the EVLA project receives the requirement
information early enough to meet the project's development plan.
\reqpri{1}

\end{reqlist}

%--------------------------------------------------------------------

\newpage
\subsection{Pipeline Data Processing} \label{req:pipeline}

\subsubsection{Introduction} 

This section describes the requirements for the EVLA on-line data
processing pipeline. Note that the following observing modes are not
considered in the present version:

The following observing modes are not considered in the present version:

\begin{itemize}
\item VLBI observations;
\item solar observations;
\item pulsar observations;
\end{itemize}

\paragraph{Pipeline Operations} % ------------------------------------------

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

{\bf Real-time Calibration Operations} \\ The Real-time
Calibration Operations are performed to process all operations that
are necessary to avoid the system halting.

  \begin{itemize}
  \item[$\circ$] Atmospheric modelling
  \item[$\circ$] Astronomical Calibration
      \begin{itemize}
      \item reduce and archive astronomical calibrations, e.g.\
          \begin{itemize}
	  \item[--] bandpass calibration
          \item[--] flux-density scale
          \item[--] polarization calibration
          \item[--] antenna gain vs. elevation curves
          \item[--] atmospheric calibration
          \end{itemize}
      \item compute preliminary phase rms and 
      preliminary phase and amplitude calibration 
      \end{itemize}
  \item[$\circ$] Telescope/Array Calibration
      \begin{itemize}
      \item reduce and archive telescope/array calibrations, e.g.\
          \begin{itemize}
          \item[--] pointing
          \item[--] focus
          \item[--] delay
	  \end{itemize}
      \item allow use of ``plug-ins'' tools to reduce e.g.\
	  \begin{itemize}
          \item[--] baselines measurements
	  \item[--] pointing models
          \item[--] holography
          \end{itemize}
      \end{itemize}
  \end{itemize}
  \vspace{5mm}
  
{\bf Quick Look Operations} \\
The Quick-Look Operations are processing data in a
fast and/or approximate way, in order to allow the EVLA staff
and the PI to monitor the on-going observations.
    \begin{itemize}
    \item[$\circ$] Monitoring
       \begin{itemize}
       \item display subsets of the current properties of the observations 
	and/or array 
       \end{itemize}
    \item[$\circ$] Quick data processing
        \begin{itemize}
        \item works on subsets [channel ranges] or pre-processed data 
	      [resampled or integrated]
        \item apply preliminary phase and amplitude calibration
        \item produce and display images (no or simplified deconvolution)
        \end{itemize}
    \end{itemize}
    \vspace{5mm}

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

\paragraph{Sources} % ------------------------------------------------------

We use the following terms in this document:

\begin{itemize}

\item {\em Astronomical Source}: any astronomical object or
position in the sky observed by the EVLA for astronomical
purposes.  This excludes arbitrary positions observed for
calibrations (OFF positions, skydips, etc.).\\

\item {\em Target Source}: astronomical source whose observation is the goal
of the current project.\\

\item {\em Calibration Source}: astronomical source observed for calibration
purpose. It could be a a point-like source (quasar) or any source with known
flux or structure (including planets) or spectral features (e.g.\ masers).

\end{itemize}

\paragraph{Calibration} % --------------------------------------------------

The term ``calibration'' refers to several types of operations that
have to be performed. We distinguish three categories of calibrations:

\begin{itemize}

\item {\em The instrumental calibration}: pointing, focus, delay,
baseline, etc. A fast feedback to the control software is required.
In particular, there are critical calibrations (focus, pointing,
delay) which must be executed successfully before telescope operations
can resume -- these are the most time-critical and have highest
priority. \\

\item {\em The calibrations that do not require a time interpolation},
as the atmospheric calibration, or the bandpass and instrumental
polarization measurements: each time such an observation is acquired,
a certain quantity can be immediately derived and stored, to be
applied to all following observations, until a new calibration of that
kind is observed. \\

\item {\em The calibrations that require a time interpolation}, as
e.g.\ the phase and amplitude calibration: a calibration curve has to
be fitted using data taken over a range in time. This curve is then
applied to target observations that were observed in between
calibrations.

\end{itemize}

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

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

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

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

\begin{reqlist}

\item The Pipeline shall be able to process all data coming from the
array in standard modes designated by the project. It must not
constitute a bottle-neck in the data flow. \reqpri{1}

   \begin{subreqlist}
   \item Some projects will require unusually high data rates or processing
         requirements. These may require processing outside of the EVLA system
         and should be flagged appropriately so they are not processed by the
         EVLA pipeline. \reqpri{1}
   \end{subreqlist}

\item The Pipeline shall be data-driven. All necessary parameters will
be specified either by the PI/CoIs at proposal preparation stages
(science data) or by the EVLA staff (telescope calibration).
\reqpri{1}

\item The Science Pipeline shall operate through readable and
comprehensible data reduction scripts.  
\reqpri{1}

   \begin{subreqlist}

   \item These scripts may be automatically generated from templates, on the
   basis of the observing mode being used 
   \reqpri{2}

   \end{subreqlist}

\item The Pipeline shall include automatic flagging of data, to
bypass data which do not fulfill some given conditions (in terms,
e.g., of weather conditions, antenna temperature, difference from a
running mean or rms, level of interference, etc.) The data must
nevertheless be archived, and the flagging must be reversible in an
off-line data reduction system. 
\reqpri{1}

\item The Pipeline should output and archive a comprehensible
summary of the operations performed with diagnostic information to
allow checking of results and a record of the processing. 
\reqpri{1}

%\item Sufficient recording of
%operations performed and control parameters shall be carried out so
%that any step can be reversed and redone if needed, without recourse
%to repeating an entire series of previous operations or resorting to a
%copy of the dataset at the intermediate state. \reqpri{2}

\item A manual, interactive mode of operations shall be available for
debugging, technical developments, inspection by qualified EVLA
staff. In this mode, both a Command Line Interface (CLI) and a
Graphical User Interface (GUI) shall be available. 
\reqpri{1}

\item The Pipeline (especially the Science Calibration and Imaging
Operations) shall also be runnable at the Regional Centers. Some of
the actions described below are not relevant in that case, as the
interactions with the dynamic scheduling and with the real-time
control system. \reqpri{2}

\item Antenna-based determination of calibration quantities shall be
the primary form of calibration. \reqpri{1}

   \begin{subreqlist}

   \item Baseline-based calibration shall also be available. \reqpri{1}

   \item Provision must be taken to accomodate more elaborate calibration
         schemes, e.g.\ physical modelling of antenna phases. \reqpri{3}

   \end{subreqlist}

\end{reqlist}

\newpage
\subsubsection{Real-time Calibration Operations} % ------------------------
\label{sec:pl:cal} 

\begin{reqlist}
  
\item The Real-time Calibration Operations shall be activated after
each calibration scan. \reqpri{1}

\item Whenever the results of the Real-time Calibration allow
one to identify poorly behaving hardware, a status report will be
logged at system level for maintenance purposes, and made available
both to the operator and to the Dynamic Scheduler. Affected data will
be flagged. \reqpri{2}
 
% \item The Telescope/Array Calibration Operations may also be re-invoked
% at any time with updated parameters or improved data. The results
% should not immediately overwrite old results so comparison is possible
% before adopting the new calibration. There will need to be a method
% for validation and acceptance of calibration updates.

\end{reqlist}

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

\begin{reqlistthree}

\item Atmospheric modelling shall be available in the Pipeline.  The
model shall be able to predict the absorption, emission and pathlength
on the line of sight through the atmosphere at all EVLA bands. The
prediction will be based on measured data, including, but not
limited to:

 \begin{subreqlistthree}
 
 \item measured atmospheric parameters at the site: temperature,
       pressure, humidity;

 \item measured atmospheric emission in the observed EVLA bands; 

 \item measured WVR data;
 
 \item measured atmospheric profiles of temperature and water
       content if available from atmospheric sounders;

 \item measured optical depths from tipper meters and/or FTS, if
       available.
 
 \end{subreqlistthree}

\reqpri{1}

\item Atmospheric modelling shall be used to derive the system
temperatures corrected for atmospheric absorption in all astronomical
bands in use, in order to correct the observed amplitudes at various
elevations. \reqpri{1}

\item Atmospheric modelling shall also be usable to provide the
conversion factors between WVR data and the water contribution to the
astronomical phase in all EVLA bands. \reqpri{1}

\end{reqlistthree}

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

\begin{reqlistthree}
  
\item The Pipeline shall reduce, and store the results for further use:

   \begin{subreqlistthree}

   \item the receiver sideband ratios; \reqpri{1}

   \item the temperature scale calibration data, using the Atmospheric
         Model; in real-time mode, the results must be made available
         for access by the dynamic scheduling system; they must
         also be made available to later operations to convert the raw
         data into temperature scale whenever required. \reqpri{1}
  
   \item the bandpass calibration data; \reqpri{1}

   \item the instrumental polarization. \reqpri{1}

   \end{subreqlistthree}

%\item For all observations of an astronomical source, the Pipeline shall
%convert the raw data into temperatures, or, alternatively, store the
%conversion factor ($T_{\rm sys}$) and defer the actual conversion to each step
%that requires calibrated data. \reqpri{1}}

%\item store the phase corrected from the atmospheric perturbation,
%using the WVR data and the Atmospheric Model (cf.\
%\ref{req.atm.2}); in subsequent operations, the corrected or
%uncorrected phase is to be used, depending on the selected
%mode \reqpri{1} 

\item For suitable observations of a calibration source, the Pipeline
shall perform operations that include:

   \begin{subreqlistthree}

   \item compute the phase rms over the observed time; \reqpri{1}

   \item compute the antenna efficiencies using the known source flux; 
         \reqpri{1}

   \item do the previous operations both with and without applying the
         atmospheric phase correction, and deduce from the comparison
         whether the atmospheric phase correction improves the results
         or not; this may involve having performed several
         observations with different parameters for the atmospheric
         phase correction; \reqpri{2}

   \item derive amplitude and phase time-dependent variations by fitting
         smoothed curves (e.g.\ polynomials, splines) using all observations of
         calibrators since the beginning of the session; fast-swtiching 
 	 observations shall be supported; this derivation shall be done either 
         per antenna or per baseline or both. \reqpri{2}

   \end{subreqlistthree}

In real-time mode, these results shall be made available to the
dynamic scheduling system. They must also be made available to later
Science Operations for gain transfer to target sources. \reqpri{1}

\end{reqlistthree}

\paragraph{Astronomical Calibration: Single Dish Data} % -------------------
\label{sec:pl:cal:sd}

\comment{STM: It is expected that the EVLA will work in concjunction with
single-dish telescopes e.g. GBT.  We may want to consider allowing pipeline
operations of this sort.}

\begin{reqlistthree}
  
\item The Pipeline shall reduce the temperature scale
calibration, using sideband ratios determined from the most recent
interferometric calibration. In real-time mode, the results must
be made available for access by the dynamic scheduling system; they
must also be made available to later operations to convert the raw
data into temperature scale whenever required.
\reqpri{1}
  
%\item For all observations of an
%astronomical source, the Pipeline shall convert the raw data into
%temperatures, or, alternatively, store the conversion factor ($T_{\rm
%sys}$) and defer the actual conversion to each step that requires
%calibrated data. \reqpri{1}}

\end{reqlistthree}

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

\begin{reqlistthree}

\item The Pipeline must reduce:

   \begin{subreqlistthree}

   \item measurements of the pointing offsets; \reqpri{1}

   \item the focus measurements; \reqpri{1}

   \item the delay measurements. \reqpri{1}

   \end{subreqlistthree}

   The results must be archived. They must be made available
   to the real-time control system. \reqpri{1}

\item The Pipeline shall have access to additional tools, in
order to:

  \begin{subreqlistthree}

  \item determine the antenna locations from the observations
   of several calibration sources; \reqpri{1}

  \item determine pointing models from the 
   observations of calibration sources; \reqpri{1}

  \item determine focus corrections from the observations of 
   calibration sources; \reqpri{2}

  \item reduce holography measurements; \reqpri{1}

  \item derive generic primary beam properties, including
  shape, polarization pattern, and half-power beam size and the
  main-beam efficiency from the observations of planets or point
  sources of known fluxes or small sources of known visibility model.
  \reqpri{2}

  \end{subreqlistthree}

The results shall be made available to the real-time control system
to update the instrument parameters.

\item Single Dish data -- The Pipeline must reduce:

   \begin{subreqlistthree}

   \item the pointing measurements; \reqpri{1}

   \item the focus measurements; \reqpri{1}

   \item the skydip measurements; \reqpri{1}
  
   \item the holography measurements. \reqpri{3}

   \end{subreqlistthree}

The results must be archived. They must be made available to the
real-time control system. Note however that in most cases these
determinations will be done interferometrically.

\end{reqlistthree}

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

\paragraph{Monitoring} % ---------------------------------------------------

\begin{reqlistthree}

\item Quick Look monitoring   Operations shall be activated automatically after
each occurrence of the Real-time Calibration Operations. \reqpri{1}

\item The results of Quick Look monitoring must be made available
in summary form to PI/CoIs astronomers of the project, via the Internet. 
\reqpri{2}

\item A Monitoring Tool shall be available, plotting and archiving in
a log file various real-time calibration results, including:

   \begin{subreqlistthree}

   \item the results of the last pointing or focus scan; \reqpri{1}

   \item the phase rms computed over the last scan and computed over the 
         current session. \reqpri{1}

   \item the corresponding seeing. \reqpri{1}

   \item the atmospheric opacity. \reqpri{1}

   \end{subreqlistthree}

This tool shall include a variety of options, to control the display
parameters, to plot the variation of these results with time, to allow
the staff astronomer and operator to monitor one antenna or baseline
in particular, etc.  Since it is required that the EVLA staff can
efficiently check out the status of ongoing observations, all the
plots by the monitoring tool should be reasonably simple, and the plot
option should be able to quickly be changed by the staff
astronomer/operator.

\item Automatic checks shall be available to detect anomalous or erroneous
results, triggering alarms if necessary. \reqpri{1}

\item The Pipeline shall be able to detect interference, e.g. due to
communication satellites operating at ar near the observed frequencies, flag
the data accordingly, and trigger alarms if necessary. \reqpri{3}

\item A Monitoring Tool shall be available to plot the current properties
of the array, such as:

   \begin{subreqlistthree}

   \item the current instantaneous $uv$ coverage; \reqpri{2}

   \item the corresponding weight distribution (natural weighting); \reqpri{2}

   \item the corresponding dirty beam; \reqpri{2}

   \item the previous quantities, integrated over the session;
         \reqpri{2}

   \item the thermal noise rms reached since the beginning of the observing 
	 session (from theory, using actual system temperatures); \reqpri{2}

   \item for mosaic observations: the above quantities for each
	pointing center. \reqpri{2}
   \end{subreqlistthree}

\end{reqlistthree}

\paragraph{Data processing} % ------------------------
\begin{reqlistthree}

\item Quick Look Data processing Operations shall be activated
automatically under given conditions (e.g.\ after a certain time
interval, after each scheduling block, if a rms has been reached,
etc.). It must also be possible to start those operations whenever
requested by the staff astronomer or operator. \reqpri{1}

\item The results of Quick Look Data processing must be made available
to PI/CoIs astronomers of the project, via the Internet (see
requirement 4.0-R9). \reqpri{2}
%% Check the number ...
\end{reqlistthree}

\paragraph{Data processing: Interferometric Data} % ------------------------

\begin{reqlistthree}

\item The visibilities observed on a target source shall be
calibrated, using the results of the Real-time Calibration Operations:

   \begin{subreqlistthree}

   \item convert the raw data into flux density; \reqpri{1}

   \item apply the current bandpass calibration; \reqpri{1}

   \item apply the current amplitude and phase correction (using
	 the scaling factor between the calibration and observing
	 frequencies); \reqpri{1}

   \item apply the flux conversion factor based on standard antenna 
         efficiencies. \reqpri{1}

   \end{subreqlistthree}

\item The spectra observed on an astronomical target shall be
displayed (amplitude and phase) with various options such as:

   \begin{subreqlistthree}

   \item time integration; \reqpri{1}

   \item choice of the baseline(s); \reqpri{1}

   \item baselines summation, with and without shifting phases to a
         specified position; \reqpri{2}

   \item intensity (amplitude and/or phase) as function of baseline
         and time (for a frequency), or time and frequency (for a
         baseline); \reqpri{1}

   \item phase and amplitude closure for calibrators. \reqpri{1}

   \end{subreqlistthree}

\item The Quick Look Pipeline shall compute the dirty image of
astronomical targets, using the fastest algorithm possible.
The resulting maps shall be displayed. The supported observing
modes should include:

   \begin{subreqlistthree}

   \item normal single-field synthesis; \reqpri{1}

   \item multiple sources observations (``snapshots''); \reqpri{1}

   \item mosaicing; \reqpri{2}

   \item on-the-fly mosaicing; \reqpri{3}

   \end{subreqlistthree}

\item The processing described in the previous requirement shall be done for:

   \begin{subreqlistthree}

   \item the continuum data; \reqpri{1}
     
   \item the line-averaged spectra, over a pre-defined velocity range,
         or possibly a velocity range defined by the staff astronomer or 
	 operator. \reqpri{1}

   \end{subreqlistthree}

\item The following calibration modes shall be supported:

   \begin{subreqlistthree}

   \item calibration transfer (including fast switching); \reqpri{1}
     
   \item self-calibration; \reqpri{1}

   \item frequency-switching; \reqpri{2}

   \item temperature calibration (e.g. the VLBA). \reqpri{3}

   \end{subreqlistthree}

\item For the observations of point-like, bright sources (e.g.\
quasars) the Pipeline shall include tools allowing fast data
analysis in the $uv$ and image planes, in order to check the data
consistency. \reqpri{2}

\end{reqlistthree} 

\paragraph{Data processing: Single Dish Data} % ----------------------------

\comment{STM: It is expected that the EVLA will work in concjunction with
single-dish telescopes e.g. GBT.  We may want to consider allowing pipeline
operations of this sort.}

\begin{reqlistthree}

\item The current spectra observed on the astronomical target shall be
corrected from the emission at a reference position or frequency.  All
EVLA modes (as designated by the project) shall be supported,
including:

   \begin{subreqlistthree}

   \item position switching; \reqpri{1}

   \item frequency switch; \reqpri{1}

   \item raster maps using one of the above modes; \reqpri{1}

   \item OTF maps using one of the above modes. \reqpri{1}

   \item nutator switch; \reqpri{2}

   \end{subreqlistthree}

\item The spectra shall be displayed with various options, such as:

   \begin{subreqlistthree}

   \item time integration; \reqpri{1}

   \item antenna summation; \reqpri{1}

   \item baseline fit, excluding a window automatically determined, or
         pre-defined, or defined by the Operator or Staff Astronomer;
         \reqpri{1}
         
   \item spectra on a grid corresponding to actually observed
         positions on a raster (a ``stamp" or ``profile"
         plot). \reqpri{1}

   \end{subreqlistthree}

\end{reqlistthree}

\newpage

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

\begin{reqlist}

\item The Science Calibration Operations shall be activated after
reaching a break point or at the end of an observing session). \reqpri{1}

\item The Pipeline shall use all data observed during the session. \reqpri{1}

\end{reqlist}

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

\begin{reqlistthree}

\item The Pipeline shall use calibration sources to derive:

   \begin{subreqlistthree}

   \item the bandpass calibration; \reqpri{1}

   \item derive amplitude and phase time-dependent variations by
         fitting smoothed curves (e.g.\ polynomials, splines) using
         all observations of calibrators since the beginning of the
         session; fast-switching observations shall be
         supported. \reqpri{1}

   \end{subreqlistthree}

\item The Pipeline shall check and correct the flux scale by using
observations of source of known fluxes. Any effect due to the source
being resolved shall be taken into account. \reqpri{1}

\item The  Pipeline shall calibrate the source observations by applying:

   \begin{subreqlistthree}

   \item the bandpass calibration; \reqpri{1}

   \item the phase calibration (using the appropriate scaling factor the
	 calibration and observing frequencies); \reqpri{1}

   \item the amplitude calibration. \reqpri{1}

   \end{subreqlistthree}

\end{reqlistthree}

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

\begin{reqlistthree}

\item The data taken on the astronomical target shall be reduced,
depending on the observing mode. All EVLA modes (as designated by the
project) shall be supported, including:

   \begin{subreqlistthree}

   \item position switch; \reqpri{1}

   \item nutator switch; \reqpri{1}

   \item frequency switch; \reqpri{1}

   \item raster maps using one of the above modes; \reqpri{1}

   \item OTF maps using one of the above modes. \reqpri{1}

   \end{subreqlistthree}

\item The resulting spectra shall be corrected for a baseline, fitted
on all spectra channels but a window automatically determined, or
pre-defined, or defined by the Operator or Staff Astronomer. \reqpri{1}

\item The Pipeline shall check and correct the flux scale, using
observations of sources of known fluxes. \reqpri{1}

\end{reqlistthree}

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

\begin{reqlist}

\item The Science Operations shall be activated after reaching a 
monitor break-point defined by the user in the Observing Tool (see
Section~\ref{sec:ObservingTool}) or at the project completion.
\reqpri{1}

\item The Science Operations shall be routinely completed no later than
24~h (?) after the end of the data acquisistion.  There may be special
cases for certain observing modes which will take longer.
\reqpri{1}

\item The manipulation of data cubes shall be the default mode of
operation of the imaging processing. The final product will be
the deconvolved images. \reqpri{1}

\item The Science Pipeline must process all data from all standard modes
and attach a quality measure to the result \reqpri{1}

\item All the data previously obtained since the project has been started
shall be available for processing. This includes data obtained in different
array configurations, as well as total power data for measurements of zero
and short-spacings. \reqpri{2}

\item The results of the Science Operations Imaging must be made available to
PI/CoIs astronomers of the project, via consultation with the Archive
Operations.
\reqpri{2}

\item The Science Pipeline shall process  all data from all standard modes
to the highest level of quality, reprocessing older archive projects
when necessary \reqpri{3}

\end{reqlist}

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

\begin{reqlistthree}

\item The Pipeline shall use calibration sources to derive:

   \begin{subreqlistthree}

   \item the bandpass calibration; \reqpri{1}

   \item derive amplitude and phase time-dependent variations by
         fitting smoothed curves (e.g.\ polynomials, splines) using
         all observations of calibrators since the beginning of the
         session; fast-switching observations shall be
         supported. \reqpri{1}

   \end{subreqlistthree}

\item The Pipeline shall check and correct the flux scale by using
observations of source of known fluxes. Any effect due to the source
being resolved shall be taken into account. \reqpri{1}

\item The  Pipeline shall calibrate the source observations by applying:

   \begin{subreqlistthree}

   \item the bandpass calibration; \reqpri{1}

   \item the phase calibration (using the appropriate scaling factor the
	 calibration and observing frequencies); \reqpri{1}

   \item the amplitude calibration. \reqpri{1}

   \end{subreqlistthree}

\item The Pipeline shall find in the Archive the calibrated data
obtained during all previous observing sessions, and check whether the
data are compatible with the current dataset (in terms of instrument
setup and properties, noise rms, etc.) {If not compatible, the
data shall not be used together, and the Pipeline shall process only
the current dataset}.  \reqpri{2}

\item Careful cross checks of the flux scales between the data sets
shall be performed. In case of inconsistancies, the quality
measure shall be affacted. \reqpri{2} 

\item Direct comparison of the redundant data (obtained simultaneously
or not) shall also be performed. In case of inconsistencies,
the quality measure shall be affected. \reqpri{2}

\item The Pipeline shall extract the visibilities with the appropriate
frequency resolution, plus the pseudo-continuum measurement if
required.  \reqpri{1}

\item The Pipeline shall compute images for each (non-blanked,
possibly user-specified) frequency channel, as well as for the
continuum emission if required. This includes gridding the whole data
set and computing the Fourier transform, using the most
appropriate algorithm. Several weightings shall be available
(including natural, uniform, robust). \reqpri{1}

\item The images shall be deconvolved using the most appropriate
algorithm. The algorithms supported shall include:

   \begin{subreqlistthree}

   \item CLEAN and its various flavors; \reqpri{1}

   \item multi-resolution and multi-scale CLEAN; \reqpri{2}

   \item Maximum Entropy Method (MEM). \reqpri{1}

   \end{subreqlistthree}

\item In the case of a complicated imaging problem, it should be possible to
have several algorithms running in parallel, the best (according to
criteria TBD) image being eventually selected. \reqpri{3}

\item Designated observing modes shall be supported, including:

   \begin{subreqlistthree}

   \item normal single-field synthesis; \reqpri{1}

   \item multiple sources and/or multiple frequency setups
   observations (``snapshots''); \reqpri{1}

   \item mosaic observations; \reqpri{1}
 
   \item on-the-fly mosaics; \reqpri{3}

   \item wide-field imaging; \reqpri{3}

   \item combination of single dish and interferometer data. \reqpri{2}

   \end{subreqlistthree}

\item Self-calibration techniques shall also be available to calibrate and
image the data. \reqpri{3}

\item Subtraction of continuum level from spectral data may be
required. This can be done in both Fourier and image domain. In the
case of $uv$-plane subtraction, flexible setting of the frequency
channel ranges for the calculation of the continuum level should be
available. It shall eventually be possible to make trial subtractions
and select the best solution in an automated manner. \reqpri{3}

\end{reqlistthree}

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

\begin{reqlistthree}

\item The data taken on the astronomical target shall be reduced,
depending on the observing mode. All EVLA + Single Dish (e.g. GBT)
modes (as designated by the project) shall be supported, including:

   \begin{subreqlistthree}

   \item position switching; \reqpri{1}

   \item nutator switching; \reqpri{1}

   \item frequency switching; \reqpri{1}

   \item raster maps using one of the above modes; \reqpri{1}

   \item OTF maps using one of the above modes. \reqpri{1}

   \end{subreqlistthree}

\item The resulting spectra shall be corrected for a baseline, fitted
on all spectra channels but a window automatically determined, or
pre-defined, or defined by the Operator or Staff Astronomer. 
\reqpri{1}

\item The Pipeline shall check and correct the flux scale, using
observations of sources of known fluxes. \reqpri{1}

\item The Pipeline shall find in the Archive previous observations and
calibration data, and check whether the data are compatible with the
current dataset. \reqpri{2}

\item The Pipeline shall then grid the whole data set if the project
requires imaging. Combination of data observed on diffrent rasters,
possibly with different (regular or irregular) spacings shall be
supported. \reqpri{1}

\item Provision shall be taken to allow running appropriate algorithms
(deconvolution, destriping), if required by the data or by the
experience gained using the EVLA. 
\reqpri{3}

\end{reqlistthree}

%---------------------------------------------------------------------

\newpage

\subsection{Real time software} \label{sec:realtime}

\subsubsection{Basic Operation Modes}

\begin{reqlist}

\item A {\bf Technical Interface} shall be available for engineers for
debugging and maintenance purposes. 
\reqpri{0}

\item In {\bf Manual Mode} a subset of the antennas shall  be directly
controlled through a {\bf Control Command Language}. 
\reqpri{0}

\item In {\bf Interactive Mode} the array shall be directly controlled by
the (guest or staff) astronomer through a GUI.
This will be done under the responsibility and with the assistance
of the Operator.  
\reqpri{1}

\item In {\bf Dynamically Scheduled Mode} the array shall execute the
highest priority observations (scheduling blocks) selected by the
dynamic scheduler. This shall be the default mode of operation.
\reqpri{1}

\item The same {\bf Observing Modes} shall be available in Interactive
Mode and Dynamically Scheduled Mode. They shall include:

  \begin{subreqlist} 

    \item Interferometric 
    \begin{subsubreqlist} 
      \item Single Field Mapping.
      \item Multi Field Mosaics
      \item On-The-Fly Mosaics
      \item Phased Array
    \end{subsubreqlist} 

    \item Total Power {\red (drop for EVLA)?}
    \begin{subsubreqlist}
      \item On the Fly Mapping 
      \item Position Switched Mapping 
      \item Frequency Switched Mapping 
    \end{subsubreqlist} 

    \item Special observations 
    \begin{subsubreqlist} 
      \item Pulsar observations
      \item Solar flare tracking.
    \end{subsubreqlist} 

    \item Project Calibrations 
    \begin{subsubreqlist} 
      \item Gain Calibration (amplitude and phase)
      \item Bandpass calibration 
      \item Pointing/Focus calibration 
      \item Flux calibration 
      \item Polarization calibration 
    \end{subsubreqlist} 

    \item Array Calibration 
    \begin{subsubreqlist} 
      \item Pointing calibration session
      \item Baseline calibration session
      \item Delays calibration
      \item Beam shape calibration
      \item Holography
    \end{subsubreqlist} 

  \end{subreqlist} 

\reqpri{1}

\item The same GUI ({\bf Observing Tool}) shall be used in both
interactive and dynamically scheduled modes to select the observing
modes and parameters.
\reqpri{1}

\item The antennas shall be divided into one or more {\bf sub-arrays},
operated simultaneously and independently, each sub-array being in
any of the above modes. However there should be only one program in the
dynamically scheduled mode at any time (see 2.1R11).
\reqpri{0}
  
\item The allocation of antennas to sub-arrays/sessions shall take into
account the hardware constraints imposed by local oscillator control
(EVLA number here), and by the correlator 
(EVLA number here).
\reqpri{0}

\item For allocation of resources the maintenance and array calibration
sessions shall  have the highest priority in the scheduling, unless otherwise
decided by the staff, e.g.\ to make the best possible use of exceptional
observing conditions. 
\reqpri{1}

\item EVLA software shall support a phased array mode for VLBI, using all
or a sub-array of antennas.
\reqpri{1}

\item As a baseline plan there shall be only one dynamically scheduled
research program at a time, using all available antennas while
some antennas have been taken out by the staff as one or several
interactively controlled subarrays, for calibration or research. 
Remaining antennas shall be made available to filler science programs, either
through a functionality of the scheduler, or by manual action of the
operator. The filler programmes must be able to release these
antennas on short notice as soon as they are needed by the main
(dynamically scheduled) research programme. This does allow special cases
where a continuous subarray (for monitoring etc.) runs while normal science
ops continue with a reduced number of antennas.
\reqpri{1}

\end{reqlist}

\newpage
\subsubsection{Control Command Language}

\begin{reqlist}

\item The minimum amount of observing activity that can be obtained by issuing 
a single observing command ({\bf observation}) is described by an {\bf
observation descriptor} (see appendix).  These
parameters fully describe the data taking activity during that
observation, including telescope motion and switching schemes.
\reqpri{0}
  
\item The Control Command Language shall include commands to actually
control the hardware (antennas, LOs, correlators) for data taking,
according to the observation descriptor.
\reqpri{0}

\item  During an observation each antenna shall move following a pattern
relative to the source direction.  That pattern shall be
independently defined for each antenna and shall be:

\begin{subreqlist}

   \item a fixed position 

   \item an arc of circle on the celestial sphere (defined by a
   starting point, the center point, the angular velocity)

   \item a general curve interpolated between a set of points on the
   celestial sphere, and the corresponding times\reqprip{2}.

\end{subreqlist}
\reqpri{0}

\item During an observation other possible switching schemes may include:

\begin{subreqlist}

   \item subreflector nutation (TBD), 

   \item LO1 frequency switching, 

   \item load or noise diode switching for calibration (TBD)

   \end{subreqlist}
\reqpri{2}

\item The Control Command Language shall include commands to convert
astronomer's input observing parameters into observation descriptor
parameters when this can only be done at the time of the
observation. This includes:

\begin{subreqlist}

   \item coordinate conversion to the antenna system,

   \item LO and IF filter setting according to frequency and Doppler
   tracking parameters (in the current baseline system design).

\end{subreqlist}
\reqpri{0}

\item The Control Command Language shall include commands to access
pipeline results or current environmental parameters in order to
tune up observing parameters (integration times, loop cycles) in
quasi real time, according to pre-defined formulae, when so
requested.
\reqpri{2}

\item The Control Command Language shall include commands to setup the
pipeline for data reduction.
\reqpri{1}
  
\item Features in the language built-in functionalities should include: 

\begin{subreqlist}

  \item macros for abbreviation of frequently typed sequences

  \item procedures to which parameters may be passed

  \item definition of variables and arrays, with numeric or character
  content

  \item evaluation of expressions, including built-in functions

  \item conditional execution facilities

  \item loops

  \item error recovery facilities including a time out 

  \item interruption facility in procedure execution

\end{subreqlist}
\reqpri{0}

\end{reqlist}

\subsubsection{Data Collection and Data Rates}
\begin{reqlist}

   \item Data taking shall be {\bf blanked} (i.e. data from a
   correlator dump will not be integrated) on an antenna-based basis
   whenever:

   \begin{subreqlist} 

     \item tracking errors are in excess of an observer specified
     value 

     \item any LO in the data path is out of lock (base band based)

     \item the subreflector is out of position tolerance

     \item the receiver mechanical calibration system (e.g. vane) is
     out of position tolerance

   \end{subreqlist}

   The minimum amount of blanked data shall be:

   \begin{subreqlist} 

      \item an integer multiple of the 16ms correlator dump time.

      \item smaller than (TBD) 5 percent fraction of the integration
      time (if this fraction is larger than 16ms). 
      This means that for long integration times (tens of seconds), 
      being able to blank a single correlator dump is not necessary.
 
   \end {subreqlist}
   \reqpri{0}

   \item It shall be possible to {\bf flag} integration periods when
   the data is (or may be) affected in a way that could lead to wrong
   science.  The flagging information shall identify, e.g.\ as boolean
   information, the origin of the malfunction. 
   Conditions which shall cause flagging include at least:
   
   \begin{subreqlist}

     \item Antenna-based flags, integration based:

     \begin{subsubreqlist}

       \item Last WVR calibration failed 

       \item Current WVR hardware defect

       \item WVR currently degrades data (based on calibrator amplitude
       or phase)

       \item Last pointing calibration failed (or no pointing
       calibration done)

       \item Last temperature scale calibration failed (all data was blanked)

       \item Temperature scale calibration system hardware defect
    
       \item Last temperature scale calibration failed, Tsys is currently
       estimated and not measured (by baseband)
      
       \item Shadowing: the antenna aperture is shadowed for any reason
       (the amount of shadowing shall be kept along with data, in addition 
       to the flagging information).

       \item Total power out of range (by baseband)

       \item Integration partly blanked (including  blanking condition
       identification): as a warning.

       \item Integration totally blanked (including  blanking condition
       identification): obviously quite severe.

       \item Bad data (by baseband, reserved for use by pipeline) 

     \end{subsubreqlist}

     \item Baseline-based flags, observation based:

     \begin{subsubreqlist}

       \item Correlator malfunction (baseband based) e.g.: Correlator
       chip failed last self-test; Excessive closure error last
       calibrator observation, ...

     \end{subsubreqlist}

   \end{subreqlist}

   Parameters ranges leading to flagging shall be settable.  Flagged
   integration periods can later be optionally used or discarded for
   further data reduction.
   \reqpri{0}

   \item Data rates commensurate with the expected needs of the EVLA shall
   be supported by the system.

   \begin{subreqlist} 

   \item ({\red to be updated})
   The average data rate shall allow the recording of one
   million complex visibilities per second (1.0 MVPS) and one-half
   million image pixels per second (0.5 MPPS). These are the average over
   long periods of time and different programmes. These can be used to
   determine the archive size. The visibility data rate 
   scales with the number of operational baselines. The
   image data rates scale rather like the longest baseline squared
   (and like the image area for mosaics). Both rates scale like the
   number of spectral channels actually recorded.
   \reqpri{2}

   \item The peak data rates are ten times higher than the average
   data rates. 
   \reqpri{2}

   \end{subreqlist}

   \item Each visibility shall be stored as two 16-bit scaled
   integers, with occasional need for higher precision.  Switch to
   32-bit scaled integers could  be done automatically on each spectrum
   and baseline (for a spectrum normalized by its maximum channel, 
   the number of bits should be at least $1/2 \log_2{B \tau}$, where
   $B$ is the channel bandwidth and $\tau$ the integration time).
   Alternately one may choose to always use
   32-bit integers and rely on standard data compression techniques.
   \reqpri{0}

   \item Visibility data that has been (radiometrically) corrected for
   atmospheric phase effects shall be available as well as the
   uncorrected data. 
   \reqpri{0}

   \begin{subreqlist} 

     \item In the early phases of EVLA testing, both corrected and
           uncorrected data will be archived; \reqprip{0}  

     \item When the EVLA is a mature instrument, it shall
           ideally automatically choose the best, on an antenna or perhaps
           baseline basis, based on heuristics learned over the course
           of testing. \reqprip{1}  

   \end{subreqlist}

   Whether to archive corrected data, uncorrected, or both, or an
   automatic choice of the best will be a single observatory policy decision, 
   in order to preserve the uniformity of the archive.
   For integration times shorter than the shortest
   atmospheric time scales, only corrected or uncorrected data shall be 
   recorded, as the correction itself will be recorded too.
   \reqlabel{sec:phcor}

   \item The corrected and uncorrected visibility data shall be
   integrated over the same time periods. All baselines will be
   integrated over the same time periods.
   \reqpri{0}

   \item The shorter integrations allowed by the hardware shall be
   supported (16ms for correlation, 1ms for autocorrelation only, 2ms
   for the continuum detectors).
   \reqpri{0}

   \item The user shall be able to specify the number of spectral
   channels and integration time that is required in each spectral
   band to meet the science goals. Combined with the
   corrected/uncorrected selection, these choices will yield a data
   rate.
   \reqpri{1}

   \item For each spectral band the average of all channels shall be kept with
   a shorter integration time ($<1$ sec.), whatever the integration
   time chosen for the spectral data, on the basis of mapping
   requirements. This allows a check for atmospheric phase
   fluctuations using the source continuum emission, if present.  In
   this channel averaging band edges shall be taken into account.
   User-specified averaging regions (e.g. for celestial maser lines,
   or in order to avoid atmospheric lines) will be allowed.  
   \reqpri{0}

   \item The visibilities shall be stored as cross-correlation
   coefficients. At the data reduction stage they will have to be
   multiplied by stored system noise spectra to get $T_{\rm A}^*$
   scale and by stored Jy/K values to get visibilities in Janskys.
   The relative channel weights will also be computed from the
   stored system noise spectra.
   \reqpri{0}

   \comment{STM: not applicable to EVLA?}

\end{reqlist}

%---------------------------------------------------------------------

\newpage

\subsection{Operator Interface}

\begin{reqlist}

\item The Operator Interface shall include a basic ``current array
status'' display, including: 

  \begin{itemize}

  \item technical information such as current pointing position(s) in
  a variety of coordinate systems,

  \item  receiver status, 

  \item  correlator configuration,   

  \item and live information on data acquisition (current observation,
  scan, scheduling block, project, etc.)  

\end{itemize} 

\reqpri{0}

\item The Operator Interface shall include a weather display indicating
the current site conditions, with warnings issued whenever the
current conditions forbid outside activities by the local staff, or
when hardware (antennas) must be safely docked.  
\reqpri{0}
  
\item The Operator interface shall include a video display from cameras at
 strategic locations on the site. 
\reqpri{0}

\item The Operator interface shall have a hierarchical structure with:

  \begin{subreqlist} 

  \item a top level monitor to show integrated information, including
    the current observing plan, the array status,  and telescope
    status.

  \item a second level to show important monitoring items for the
    current observations.

  \item a third level with on-demand monitoring.

  \end{subreqlist} 

\reqpri{0}

\item The Operator Interface software shall be made available from 
any location where the Operator may work. It shall be available in a 
read-only mode from other 
locations, in order to support remote monitoring of the array system.
\reqpri{1}

\end{reqlist}
%-------------------------------------------------------------------
\appendix
\newpage
\section{Examples of Scheduling Blocks}

\label{sec:SBExamples}

\comment{STM: these are from ALMA.  Is this useful here?}

We give here a few examples of Scheduling Blocks, only in order to
precise their meaning. Actual implementation of the observing modes
we refer to in this Appendix will certainly be different.


\begin{itemize}\itemsep 0pt
  \item    Strong source, low frequency, interferometry:

    \begin{itemize}\itemsep 0pt
        \item One minute point source calibrator scan
        \item Nine minutes target scan
    \end{itemize}

  \item    Strong source, high frequency, interferometry:

    \begin{itemize}\itemsep 0pt
        \item Pointing scan
        \item Focus scan
        \item One minute point source calibrator scan
        \item Nine minutes target scan
        \item One minute point source calibrator scan
        \item Nine minutes target scan
        \item One minute point source calibrator scan
        \item Nine minutes target scan
    \end{itemize}

  \item    Weak source, low frequency, interferometry:

    \begin{itemize}\itemsep 0pt
        \item Twenty seconds point source calibrator scan
        \item Forty seconds target scan
    \end{itemize}

  \item    Weak source, high frequency, interferometry:
    \begin{itemize}\itemsep 0pt
        \item Pointing scan
        \item Focus scan
        \item Twenty cycles of
           \begin{itemize}\itemsep 0pt
             \item Twenty seconds point source 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 Focus scan
        \item Leakage calibrator scan, 1 minute
        \item Thirty cycles of
        \begin{itemize}\itemsep 0pt
                    \item Point source calibrator 20 seconds
                    \item Target 40 seconds
         \end{itemize}
    \end{itemize}

  \item    Mosaicing, interferometry:

    \begin{itemize}\itemsep 0pt
        \item Pointing scan
        \item Focus scan
        \item Up to 30 mosaic points at 30 seconds each
    \end{itemize}

  \item    Mosaicing, single dish, OTF:

    \begin{itemize}\itemsep 0pt
        \item Pointing scan
        \item Focus scan
        \item Off source point 1 minute
        \item Scan 300 map points at 5s each
        \item Off source point 1 minute
        \item Scan 300 map points at 5s each
    \end{itemize}
 
 \end{itemize}

\end{document}
