Re: Random remarks about report

[Robert Lucas <lucas@iram.fr>]

Barry Clark wrote:
> 
> p. 3 para 2 line 8, typo se => we.  Spell check the document?

OK I'll do it
 
> p. 6  I think the scripting language should be lifted a level (2.3, instead
> of a subhead under "Manual observing mode").  I do not see the need for
> the division headed Functionalities, and suggest its deletion, with the
> text forming one unit.

OK. I'll rename 2.2 as "Script language for Manual Operation"

> 
> p. 10.  Phased Array.  The remarks about phase switching are not relevant
> for the implementation on ALMA, with a digital beam former.  The "shadowed"
> remark needs to be generalized, to something like "flexible control over
> which antennas are used for the phased array must be provided, to optionaly
> eliminate antennas which are deeply shadowed or which have other problems."

OK
> 
> p. 11.  Phase calibration is needed for all interferometric observations
> rather than "most".

I agree with Harvey's comment, naturally. That was why the "most" was
there.
 
> 
>   Delay calibration?  Belongs with Array calibrations rather than project,
> I think.  These numbers are stable to a few hundred ps on the VLA, and
> ALMA should be much better because of the smaller dishes and shorter
> baselines.  Even in its widest band mode, the correlator provides +/- 8
> nanosec, so delay calibration is inexpensively applied post hoc from the
> same data that provides the phase calibration.

Agreed, let's put that into Array calibration. 

> 
>   Pointing/focus calibration shouldn't be needed at the lowest frequecies;
> we should be able to point and shoot.  So "needed for many" astronomical
> observations.

OK May be "needed for most" ?
> 
>   Polarization calibration, while there are uncertainties, can probably be
> derived from the phase calibration observations.
Let's add this comment.
> 
>   "Amplitude calibration" would better be called "System temperature
> calibration".
> 
> p 12.  This bothers me a bit, because these things only translate into
> what the instrument will actually do with the aid of assumptions that may
> not hold for every case.  Somewhere there has to be a bit of software
> that says to itself "OK, this implies 10 seconds integration, correlator
> bandwidths 128, 128, 128, 1000 MHz."  It should then say back to the
> astronomer something like "OK, with the available setups, you will get
> resolutions of 0.06, 0.06, 0.06 km/s, 8 MHz, rejection of objects in the
> skirts of the beam by about 28 db, an integration time smearing in the
> outer parts of your map corresponding to a 6% loss of peak flux for a
> point source, and a data output rate of 37 Gbytes per hour.  Is this
> close enough to what you had in mind?"

I wanted to add these things after Comments. I would like the astronomer
to be able to specify  "100 km/s", and have the tool also answer: "For
the correlator, this will translate into 128 MHz, but  the upper 5 MHz
and the lower 8 MHz will not be available all year round due to Doppler
tracking roundoff." and give information on the first LO and second LO
being used at various times of the year. And give the velocity range
covered if you specify input in terms of frequencies.

> 
> p. 19.  Perhaps we should say a few words about the processing of calibrators.
> I would hope for a reaction from something that looks at the calibrator
> data only in a lot less than the mentioned "typically half an hour".  Or
> is this not part of the "pipeline system"?

The "typically half an hour" refers to the dime scale od data evaluation
available to the dynamical scheduling. For each calibrator observation
one should get the phase rms and detected flux information right away,
(with the relevant uncertainties due to statistical noise). May be 6.3.2
should be more explicit on this point.
> 
> p. 22.  Not obvious to me that the image archives are of lower volume than
> the raw data archive.  Typically, astronomers do not engage in data
> reduction but data expansion.  After all, deconvolution is merely the
> discipline of making up data in places in the u,v plane where you haven't
> measured it.

Well this depends on the configuration. By mapping you also average a
lot of data from the short baselines vectors which move slowly (in terms
of antenna diameters per second). Also the frequency coverage for the
maps could be reduced by dropping unused 
edge frequencies, and smoothing to the desired velocity resolution input
in the configuration tool (sec 2.4.2)
> 
> p. 23.  Still no words about proprietary intervals.   As well as protecting
> recent data, it would be a kindness to send an E-mail to the PI when
> somebody accesses his old data.

We have definitely to add this.
> 
>   It is possible that in the future CPU will get so cheap that one simply
> re-runs the pipeline rather than storing images.  But the current wording
> ignoring such possibilites is probably best.

OK

Best 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/