Comments to Barry and Jeff emails:

[Robert Lucas <lucas@iram.fr>]

Comments to Barry and Jeff emails:


> Barry> 1.  Pre-proposal software.
> Barry> In the early days of the VLA, Alan Bridle's spreadsheet for recommending
> Barry> configurations, bands, integration times, time required, etc. was a
> Barry> great help for novice users.  At least the equivalent is needed for
> Barry> Alma.  (Converting the recent Butler & Wootten memo into a Java program
> Barry> would be a reasonable first step.)  There are various simulation tools
> Barry> running under AIPS or AIPS++.  These are, I think, needed only by
> Barry> people who know how to take care of themselves - we don't need to
> Barry> take a hand in this.
> 
> I whole-heartedly agree.  A good example of the type of tool that
> would be useful for this task is the correlator setup tool that Ken
> Young (Taco) wrote for the SMA.  It is a Java-based application that
> handles in a very intuitive and complete way the often opaque problem
> of doing the observational setup for a correlator.  Another nice thing
> about this tool was that it ran within a web browser, so no special
> software was needed.

I agree on that.  We should have a tool that accepts astronomical
information such as "Observe these lines with this velocity coverage (at
that redshift) 
and velocity resolution" and the correlator should be configured with no
risk of error.
 We all have examples of observing time lost due to errors in
configuring correlators. A web-based tool is the desired solution.

Do you agree on the phase1 - phase 2 approach (before/after proposal
evaluation) ?
> 
> Barry> 2.  Proposal preparation software.
> Barry> Do we want proposals to be machine parsable?  If so, we need to provide
> Barry> tools to help in the effort and to complain at the user if he violates
> Barry> the syntax.  In my mind, this is about a break-even.  The programmer
> Barry> time to construct the tools would only be repaid by reduced effort in
> Barry> operations over years if at all.
> 
> I agree.  I do think that we want proposals to machine readable,
> though.  Since it will likely be necessary for quite a few people from
> various locations to be able to get information from the proposals,
> machine readability is a must.

I agree too. 
> 
> Barry> 3.  Proposal evaluation tools.
> Barry> I would expect at least as many proposals for ALMA as for the VLA,
> Barry> which runs about 400 per year.  This is enough that software help is
> Barry> mandatory for routing proposals to referees, collating their ratings,
> Barry> looking for conflicts, sorting out previous observations, and deciding
> Barry> what proposals will fit in the available time.
> 
> I agree.  This in fact might argue for some amount of machine
> parsability for the proposals.
> 
> Barry> 4.  Scheduling tools - chunking
> Barry> If we are to have dynamic scheduling, all long proposals must be divided
> Barry> into chunks.  It is unclear to me who divides the proposal into chunks -
> Barry> the proposer or array operations.  (This is a policy question, not a
> Barry> software question.)  Do we want to have standard sized chunks of say a
> Barry> couple of hours?  Doing so simplifies life downstream by a lot.  If we
> Barry> do have standard sized chunks, it simplifies things even more if they
> Barry> occur on standard boundaries - eg 0000-0200 LST, 0200-0400 LST, etc.
> Barry> (Another policy question which has largish software implications.)
> 
> There are a lot of thorny issues related to dynamic scheduling.  I
> have kind of felt that we need a set of rules which define the
> decision tree for dynamic scheduling.  I think that Barry has come up
> with a good first rule with his suggestion of having a "standard
> chunk" of time.

I don't think the preset chunks are a good idea. The unit of observing
time for interferometry is the cycling time to do
calibrator/source/calibrator; this is much smaller than 2 hours: typ. 15
min, or smaller in we do fast phase calibration. When the observing
conditions degrade quickly, there is no point in continuing a project
for 2 hours, the data will be useless. We should be prepared to switch
projects nearly anytime.
Also using fixed LST boundaries doesn't help much, except for low dec
(sorry, high dec !)
sources which can only be observed for a short time. It puts hard
constraints where there is in fact a continuous transition between
observing at low elevation with higher noise and near zenith.  
> 
> Barry> There are a lot of decisions to make on which side of the scheduling
> Barry> tool/real-time system various features are to be put.  Most of these
> Barry> I favor putting on the non-real-time side, because it is easier to
> Barry> change things there.  For instance
> Barry> -  Doppler tracking.  (VLA does doppler tracking relatively infrequently
> Barry> to keep bandpasses stationary.  With digital filter bandpass formation,
> Barry> this might be unnecessary, so put in the scheduling tools so you can
> Barry> change your mind easily.)
> Barry> -  Mosaicing.  (Requires that the tool/real-time interface have separate
> Barry> specifications for antenna pointing and phase tracking.)  Real-time
> Barry> system need know nothing about mosaicing, but instead just have the
> Barry> capability of changing tracking or phase tracking centers very quickly.
> Barry> Of course, data reduction systems must be able to figure out what the
> Barry> scheduling tool had in mind in the way of mosaicing.  (Possibly a mechanism
> Barry> for passing messages from the scheduling tools to be archived with the
> Barry> data.)  (I lump with mosaicing scanning in any sort of reasonable or
> Barry> unreasonable coordinate system.)
> Barry> -  Ephemerides for solar system bodies.
> Barry> -  Subarraying.  (This would be a second level of subarraying - the
> Barry> array operator must be able to accommodate more than one user on the
> Barry> array at once, but an observer may want to be able to divide his antennas
> Barry> into subarrays as well, for example to track ephemeral phenomena at two
> Barry> frequencies.)
> 
> I like Barry's suggestions for the scheduling tool hierarchy and his
> points regarding the non-real-time placement of certain tasks.

I understand non-real-time as `being prepared before observing'. I
fully agree.  Note that at Plateau de Bure we keep the phase center on
the pointing center for mosaics; this has the adveantage that we can
integrate the data in real time to check that the signal is there (at
the center of the field). We correct the phase center off-line.

Sharing the array between many simultaneous users may appear very
democratic, but is not efficient for sensitive synthesis mapping; it
should mainly be used for ephemeral phenomena as Barry says; even in
that case, for instance for a comet, it might be more efficient to time
share the observations at different frequencies.

> 
> Barry> 6.  The real-time system.  The real work of the real-time system is the
> Barry> control of the hardware according to the script provided.  However, most
> Barry> of the software of the real-time system will be concerned with human
> Barry> interfaces.  There are three sets of interfaces needed, for different
> Barry> users.  They should be similar enough in style so that a technician
> Barry> is not totally at sea if he looks at the operator's display, or if the
> Barry> array operator looks at a scientist's array.  These interfaces should
> Barry> be networked, so that any interface may be invoked from any of a large
> Barry> number of possibly distant computers.  The three interface systems are
> Barry> -  The technician's interface.  A separate window for each device in the
> Barry> system, that enables the technician to examine any monitor point it contains,
> Barry> and to perform diagnostics on it.
> Barry> -  The operator's interface.  Lots of information screens showing what
> Barry> hardware devices are doing and if they are in good health.  Control screens
> Barry> for putting devices offline for repair or maintenance, or for swapping
> Barry> antennas from one observer to another.  Communications facilities for
> Barry> talking to technicians or observers, including but not limited to writing
> Barry> an observing log.
> Barry> -  Scientist's interface.  Information screens about what is happening on
> Barry> the array, and what the weather is like.  (Scientist interfaces into data
> Barry> processing systems are a separate question.)
> 
> The three interfaces Barry describes are quite similar to the system
> that we have at the 12 Meter.  It has been a great system for us.
> Note that all should probably be designed with remote operation as the
> default configuration given the likely operations model for ALMA.

These are good suggestions.

> 
> Barry> 7.  The data archiving system.  This is also a real-time system.  It's work
> Barry> is to get the data flowing from the correlator written on a permanent medium.
> Barry> It must also provide a port that can be tapped to provide data to data
> Barry> reduction systems in a quasi-real-time mode for the quick-look systems.
> Barry> As well as archiving the correlator data, it must also archive the
> Barry> ancillary and instrumental data coming from sensors on the instrument or
> Barry> such sources.  An important part of the activity of this system is
> Barry> providing locators, so that the data can be found again by the distribution
> Barry> system.
> 
> I guess I see the port to the real-time data display coming from the
> monitor and control system, not the archiving system.

Do we want to monitor data as it is coming from the correlators, or as
it has just been written to disk ? There is not much difference. 

Something that is very useful is an interactive tool to plot any
parameter with respect to any other, for a given list of
antenna/baselines. This can be based on the data files, but should be
available as soon as they are written.

> 
> Barry> 8.  Quasi-real time systems with feedback.  I primarily have in mind pointing
> Barry> offset determination, focus measurement, and antenna phase determination
> Barry> for phased array operation.  However, it might also be called upon to
> Barry> evaluate and adjust parameters for the real-time system task which adjusts
> Barry> phase based on radiometry.  Might well also include accumulating calibrator
> Barry> information for determination of calibrator fluxes and evaluation of
> Barry> phase stability.

Add also side band gain ratio in case of double side band
operation. Keeping an up-to-date value of calibrator fluxes is needed
to detect antennas with degraded efficiency - bad pointing or
focussing, but also may be LO problems.


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 - Tlx 980753 F
E-mail: mailto:lucas@iram.fr                http://iram.fr/~lucas/