[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [alma-sw-ssr] Definition pipelines
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.
The time to reduce the delay calibration is small compared to the time
to acquire the data.
But the feedback is real time, that is you have to apply them right
away, particularly with the delay calibration (if you would proceed and
apply the new delay offsets after some time, you would get a data set
that is non-homogeneous).
> 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.
In the pointing calibration Use Case the pointing offsets are applied in
a loop, the way Steve has written it (BC steps 2-5, remember that this
had to be included in that specific ObservePointingCalibration sequence
diagram). So at the end the offsets are already applied! Focus is the
same though we never wrote the relevant Use Case.
> >
> > - 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?
You're right. The time constraint is however not tighter since the
results are used to modify loop parameters; therefore a delay of the
order of one or a few loop cycles is tolerable.
Regards
Robert
--
Robert LUCAS, Institut de Radioastronomie Millimetrique
300 rue de la Piscine, F-38406 St Martin d'Heres Cedex (FRANCE)
Tel +33 (0)4 76 82 49 42 Fax +33 (0)4 76 51 59 38
E-mail: mailto:lucas@iram.fr http://iram.fr/~lucas/