Use Case: Quick Look Pipeline: Monitor Array Data: Interferometric Data

Quick Look Array Monitor Use Case for ALMA (based on ALMA SW Memo 11, Science Requirements and Use Cases, modified to include detailed Quick Look array monitoring requirements). The Quick Look array monitor is activated after every interferometric scan and runs in quasi real time.

Goal:   Provide monitoring information on status of the array, primarily faults, uv coverage, and thermal rms noise.

Contact Authors:   C. Wilson, R. Lucas

Role(s)/Actor(s):
Primary: Pipeline Subsystem, quick look array monitor; Control and/or Correlator Subsystem.
Secondaries:

Priority:   Critical

Performance:   Need to feedback data and results in a 'timely fashion.' Exact timing requirements TBD. At a minimum, will need to complete processing of array properties for one scan or observation before the next is completed.

Frequency of Use:   Minutes to seconds. Perform this Quick Look Array Monitor Use Case after each observation or scan. This Array Monitor will normally be activated many times per scheduling block.

Preconditions:

  1. Data from a new observation or scan are available from the Correlator subsystem running in parallel.
  2. Control activates the Quick Look Array Monitor when an observation or scan is completed via an ObsEnd event.

Basic Course:

  1. Quick-Look Array Monitor receives data for most recent scan from the Correlator
  2. Quick-Look Array Monitor check for faults and in some cases triggers an alarm. Examples of faults to be checked for are:
  3. The Quick Look Array Monitor plots the current properties of the array using the default parameters. Items to be plotted include the current uv coverage, the corresponding weight distribution (natural weighting), and the corresponding dirty beam.
    Alternate course: current properties of the array are plotted using parameters specified by the Operator, Staff Astronomer or Interactive Observer.
  4. The Quick Look Array Monitor plots the properties of the array integrated over this session using the default parameters. Items to be plotted include the uv coverage, the corresponding weight distribution (natural weighting), and the corresponding dirty beam.
    Alternate course: integrated properties of the array are plotted using parameters specified by the Operator, Staff Astronomer or Interactive Observer.
  5. The Quick Look Array Monitor shall plot the thermal noise rms reached since the beginning of the observing session (from theory, using actual system temperatures).
  6. For snapshot observations, the above actions shall be performed for the target observed in the most recent scan.
    Alternate course: the above actions shall be performed for any target in the current session specified by the Operator, Staff Astronomer, or Interactive Observer.
  7. For mosaic observations, the above actions shall be performed for the mosaic pointing center.
    Alternate course: the above actions shall be performed for a field in the mosaic specified by the Operator, Staff Astronomer, or Interactive Observer.

Postconditions:

  1. The Quick Look Array Monitor stores the raw uv data from the correlator between activations of the Quick Look Data Processor in a temporary database until the end of the observing session. This database is emptied at the end of an observing session.
  2. Standard plots and summary tables of array properties to this point are sent to the archive.
  3. The Observer is notified (by email) that plots and summary tables of array properties are available

Issues to be Determined or Resolved:  

  1. Details of how faults are identified and when alarms are triggered.
  2. How often do we want to email the observers that array monitoring has started and that plots and summary tables are available? We want to avoid sending 100 emails per observing session, but once per session may not be enough. Maybe they should just be given a URL (that they can monitor) at observing startup.
  3. How often do we want to send array monitoring plots and summary tables to the archive? At a minimum they must be sent at the end of the session. To allow monitoring during the session, perhaps once per scheduling block would be frequent enough? Depends a bit on how interactive a remote observer wants to be what the program is. Perhaps the user can set this as a parameter (with reasonable limits). Some guidance from operations on this would be helpful.

Notes:  

  1. This Use Case was created by C. Wilson to help define Quick Look requirements. Relevant SSR Use Case from SSR Memo 11 is 4.5.2 (Process Quick Look Data) (parts of it) by R. Lucas.
  2. An Observer must be able to look at the Pipeline results of recently observed Programmes without downgrading the Quick Look peformance on the currently observed Programme.

    Last modified: 12aug03