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

[Tim Cornwell]

Wish I'd been there............ 

Some comments based purely on the notes.

>>> -----Original Message-----
>>> From: evla-sw-discuss-admin at donar.cv.nrao.edu [mailto:evla-sw-discuss-
>>> admin at donar.cv.nrao.edu] On Behalf Of Kevin Ryan
>>> Sent: Thursday, February 13, 2003 08:41 PM
>>> To: evla-sw-discuss at bclark.aoc.NRAO.EDU
>>> Cc: Kevin Ryan
>>> Subject: Re: [evla-sw-discuss] Notes from Scripting Walk-through Meeting
>>> 
>>> Some notes from Kevin.
>>> 
>>> 1)
>>> > The Antenna object sets up ... stuff in the correlator front-end - the
>>> > station board.
>>> 
>>> Antennas do not know about correlators, they are antennas.  If they
>>> contained correlators then they would know about them, but they don't.
>>> Likewise, correlators do not contain antennas.
>>> 
>>> 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.

I agree with this general point and the specific conclusion. The station
board is associated with an antenna but it's also associated with a
correlator! An antenna can be an antenna without a station board but the
correlator is lesss successful as a correlator without a station board. If
the station board is an association between an antenna and a correlator,
then it's probably worthwhile to model it as an association instead of
forcing it into one or the other.

>>> 
>>> 2) I believe that much of what is contained in Barry's control
>>> scripts should actually reside in the control systems themselves
>>> (i.e. the correlator controller, antenna controller, array
>>> controller, etc.).  Here is why:
>>> 
>>> I do not like the notion of the observing scripts having to know
>>> about such things as software objects and how hardware control is
>>> implemented.
>>> 
>>> These should be observing scripts not 'control' scripts.  They should
>>> contain *what* the system should do and *when* it should be done.
>>> Nothing more.  The control systems (which know more about the thing
>>> they are controlling then anyone else) will take care of carrying out
>>> the orders.

That's a good point but it doesn't mean that python can't be used for both -
it just means that the observing scripts should be layered on top of the
control scripts.

>>> 
>>> If the observe script contains only what/when data, it can be used by
>>> any system.  This is the idea behind Brent's Virtual Correlator and
>>> our RadioTelescopeInterface which will supply the list of available
>>> 'whats'.  Our Antenna Class implements this interface and from it
>>> will extend the VlaAntenna, EvlaAntenna, VlbaAntenna and NmaAntenna
>>> for now and maybe more types later.
>>> 
>>> An Observing system that can talk to a RadioTelescopeInterface will
>>> be compatible with any of these antennas.
>>> 
>>> In summary - keep hardware and software details out of the observe
>>> layer, that is what the control systems are for.
>>> 
>>> 3)  A while back Jim U. spoke about Fred Lo's desire to make our
>>> systems easier to use so that more people will use them.  The
>>> scripts are the user's interface to our systems.  As such, this
>>> first cut of scripts are too complex.

I doubt that few observers will ever get this far into the system. It's the
job of the e2e layer to keep people mostly away from scripting the control
system.

>>> 
>>> I agree with Rich that the observe scripts should be data only and
>>> in a standardized markup language format such as XML - simplifying
>>> things for the user.

I don't agree with this - once you have loops and conditionals, XML starts
to look very unwieldy and poorly matched to the task at hand. Even the ALMA
team, who are very keen on XML, use a scripting language for control. The
ALMA folks have thought about the issue of the scripting layer in detail -
particularly Ralph Marson. Perhaps he can explain what they did. 

Tim