Re: [alma-sw-ssr] Definition pipelines

[Joseph Schwarz <jschwarz@eso.org>]

Frederic Gueth wrote:

> Real-time calibration pipeline
> ------------------------------
>
>   - Data acquisition part     - store in all incoming observation the
> current
>                                 calibration paramaters (Tsys, bandpass, ...)
>
>   - Telescope calibration     - reduce array calibrations (pointing,
> focus, delay,
>                                 baselines,...)
>                               - results are made available to the Sequencer
>

What is likely to be the limiting factor, time to acquire the calibration data, or time
to reduce it? Presumably baseline calibrations won't change during the execution of a
Scheduling Block (unless the observing process is supposed to compensate for
earthquakes in real time). Delay calibrations (according to the Use Cases, section
4.8.5 of the main requirements doc) are performed "at least once per receiver tuning"
or "at least once per observing session" or (Lucas & Muders, private communication)
"after reconnections of cables/fibres and after antenna moves". So while it's true that
ALMA can't observe without these results, which certainly need to be known by the
observing process (Sequencer?), there might be more time to produce them than the
phrase "real-time" implies.

As for pointing and focus, the Use Cases specify a "Pointing Session", which I
understand results in a pointing model, but also a "Pointing Calibration", whose
purpose is to update the parameters of that pointing model. The Pointing Session is an
array- (or observatory-) level calibration which is done "after moving one or more
antennas and/or at regular time intervals (weekly ?)", while the Pointing Calibration
gets done fairly often. When we were generating the Use Cases, I had understood that
there was no hard requirement on how quickly the results from the "Pointing
Calibration" were needed: that an observing procedure could continue to execute even if
the updates to the pointing and focus parameters weren't available for some time. How
long this "some time" could be was never specified. It would be helpful for the
analysis if this could be made a little clearer.

>
>   - Astronomical calibration  - reduce astronomical calibrations
> (atmopheric
>                                 calibration, phase rms, flux scale, bandpass, ...)
>                               - results are made available to the Dynamic Scheduler
>

>From prior discussions and from the Use Cases, I had understood that phase rms results
would be made available to the observing process (not just to the Scheduler), so that
an executing Scheduling Block could adjust cycle and dwell times on target and phase
calibrator based on the results. Similarly, an SB might want to terminate once a
certain noise level had been reached. Might not the time constraints be tighter than
those on the telescope calibrations?