Re: [alma-sw-ssr] Definition pipelines

[Frederic Gueth <gueth@iram.fr>]

Joseph Schwarz wrote:
> 
> 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.
> 

I was refering to the pointing calibration done very regularly -- each 
hour or so. Of course, alma can continue to observe without having the 
result of this pointing measurement, but then you have all chances to 
point at a slighlty wrong position. So a much wiser approch, used with all
existing antennas or interferometers, is to wait for the results of the
pointing calibration before continuing the observations. The same is true 
for focus measurements. The SSR document (req. 6.1-R1) mentions a max 
delay of 0.5 sec to have the calibration results passed to the observing 
system.


> >
> >   - 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?

Yes, the results of the astronomical calibrations have to be made available to 
the observing process. But I think that the reduction time constraints for the
telescope calibration are tighter. For the phase rms, it's a matter of deciding 
what has to be observed; if the pointing or focus are wrong, the data are affected 
by errors that you cannot correct (bad pointing, bad focus). 

Frederic.