Re: ALMA Science Software Requirements - an alternate spin

[Jeff Mangum <jmangum@tuc.nrao.edu>]

Hi Folks,

I am glad to see that someone expanded on Robert's science software
requirements.  Let me add a couple of additions and twists to Barry's
suggestions...

"Barry" == Barry Clark <bclark@aoc.nrao.edu> writes:

Barry> Robert's document is a list of scientific desiderata.  For me, things
Barry> become much clearer if we take the next step, on converting the 
Barry> desiderata into an operational plan, in which we trace the flow
Barry> of information through the system.  I have done that below with
Barry> Robert's document, with additional remarks of my own about how 
Barry> I think things should be done.

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.

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.

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.

Barry> 5.  Scheduling tools - detailed scheduling
Barry> The detailed scheduling tools provide a reasonable human interface between
Barry> the astronomer and the real-time system.  I would suggest that the
Barry> detailed scheduling tools speak to the real-time system by way of a 
Barry> text interface that is human readable, at least by specialists.  We have
Barry> found that being able to read this stream is invaluable for the VLA and
Barry> VLBA - it lets real-time programmers talk directly to scientists without
Barry> having to go through the programmers of the scheduling tools.
Barry> Note that many of Robert's desiderata simply come down to being specs
Barry> on this script.

Barry> I can see valid arguments for having three different scheduling tools.
Barry> (They are enough effort to write that it's not clear that all three will
Barry> have sufficient priority to get done when push comes to shove.)  A
Barry> windows based scheduler, like the VLA's observe and Jobserve programs
Barry> lets the user see what he is getting in a very efficient manner.  A
Barry> language based scheduler, like the VLBA's sched program, is perhaps 
Barry> most efficient at taking advantage of contingencies; it could even
Barry> have conditionals built in, and it can conveniently optimize to keep
Barry> antenna move times under control.  The third mechanism would be a 
Barry> virtual control panel, like any other telescope control panel, with
Barry> a push button to send its setup to the real-time system.

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.

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.

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.

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.

Barry> 9.  Data distribution system.  Takes archive data, in whatever format or
Barry> medium, and produces a FITS output.  The system needs the capability of
Barry> extracting subsets of the data, if the requester doesn't want to handle
Barry> the full data set at the moment.  It also probably is the place to put
Barry> security provisions, to make sure the requester is authorized to have the
Barry> data, and to notify array operations and the proposal PI.  It is unclear 
Barry> to me whether the appropriate place for calculating u,v,w is in the 
Barry> real-time system, the distribution system, or the data processing system.

Barry> 10.  Near real-time data reduction system.  Something, probably AIPS++,
Barry> to generate a first cut map, for archiving and for sending to the user,
Barry> run by array operations.  I picture this being only moderately real-time,
Barry> with turnaround of hours to days.  If an observer needs something faster,
Barry> he may start his own data reduction system, with its data filler connected
Barry> to a distribution system port piped directly out from the archive system.

Barry> 11.  Observer's data reduction system.  We have little or no input.

All good suggestions for data reduction and distribution.  Regarding
the data reduction system that the observers use, it might be to our
advantage to provide off-line conversion tools which give the observer
data in their desired format.  For example, at the 12 Meter we have
found that by providing a class-format data file in addition to our
standard sdd-format data file we can get the data to a larger fraction
of our observers in a format that they can actually use at their home
institute.

Cheers,

Jeff