[evla-sw-discuss] Notes from Scripting Walk-through Meeting

[Barry Clark]

> P.S.  I am not advocating 'dumbing' down operation of the system
> to the point that it is useless.  Expert users should still be
> able to tweek the smallest, most hidden control parameter.  It's
> just that those who don't want to tweek it should not have to.

The document as I wrote it is the description of *how* "expert users
would still be able to tweek the smallest, most hidden control parameter."
For how it appears to users, see the examples at the end.  They are 
no more complex than they have to be.

I could pretty easily translate the document into a specification on 
the things that could be supplied in an XML format.  There is pretty
well a one-to-one correspondence, except possibly for the subarray
description - I can't come up a way to describe subarrays in XML that
I am very happy with.

XML and python differ in several respects.  I think the one that attracts
Kevin and Rich is that the conversion from text string to java object can 
occur at different points in the system, and that the parser can be located 
with the code that actually operates the hardware.  This has advantages, but
it also has disadvantages.  For an example of the latter, consider the
azimuth and elevation offsets.  For some purposes (for instance pointing
scans), the Antenna wants to inherit them from those specified for the
whole subarray; for others (for instance holography) they need to be 
specified on an antenna-by-antenna basis.  This can, of course, be sorted
out in an XML based system, but it's messier and less natural than in 
the Python based system, which can invoke methods to distribute the 
information.

Another difference, is that, in the conversion from XML to java objects,
the whole script is read, and the objects are simultaneously available.
The real time system then looks at the set of objects containing times 
and operates according o the time label.  In the python approach, objects 
are created as needed, but may be modified as the script goes along.  I
can't think of any advantage/disadvantage of either way of doing things.

A third difference is that in the python approach, the java program 
specifies what the strucure of the created object is, and if the script 
does not specify a property, it defaults as specified in the java class.  
In the XML case, if the script does not mention a property, the created
object does not, in the first instance, have that property at all.  So
the java programs in the bowels of the system that are interested in that
property have to examine the object, determine if the property is present,
and do some default action if it is not.  Both schemes are workable, of
course, but I like the python approach better (strictly an aesthetic 
judgement.

To some extent, Jobserve has trained our astronomers to think in objects,
though they may not know it.  It does the equivalent of invoking an
LoIfSetup object and letting the user fill in the blanks, and then letting
this object be invoked from other places in the program.


> The Array contains both antennas and correlators (and other things
> like weather stations) so that is the logical place to broker
> information and control between those things, I think.

The Array contains a correlator, but it doesn't know what to do with it.
The information about what to do with it comes from the Subarray (which
gets the information from the astronomer) and from the Antenna (which 
has the information to do the geometry to tell the correlator how to 
set its delays).  So the Array just exposes methods of running the 
correlator to objects that know what needs to be done with it.

The station board in the correlator belongs to the Antenna, in the same 
way that other hardware entities that occur once per antenna do.  I see
no reason that the software should treat station boards differently than
L302 modules.

The correlator backend is another matter.  Yes, in some sense it is a
global thing.  But in that sense it needs little control information from
M&C.  Where it needs control information is in its output stage, when it 
has to tell tell the archive what data belongs to what subarray.  With 
the desideratum of astronomer-controlled subarraying it seems to me the 
natural place to store the information is the subarray, rather than 
having to broker it through the Array.