Subarrays in ALMA

["Steven T. Myers" <smyers@cv3.cv.nrao.edu>]

My apologies for the length of this.  The recent worry over the subarray
limits in the system prompted this...


            SYSTEM CONSIDERATIONS FOR SUBARRAYS IN ALMA

                        S. T. Myers (NRAO)

                         3 March 2000

  -----------------------------------------------------------

ABSTRACT:


  -----------------------------------------------------------

It is clear that the ability to transparently operate a moderate
number of simultaneous subarrays will be a fundamental mode for
ALMA observing.  In particular, these subarrays are likely to be
used for widely different things, such as engineering tests, VLBI
observing, single-dish observing, and standard interferometric 
observing.  These modes must seamlessly coexist, without interference
with the (presumably) dynamic scheduled user observations.

These requirements have a number of implications for the System
Software as well as the hardware control (eg. LO and correlator
subsystems).  After reviewing the documents describing the current
system, in particular:

   http://iram.fr/%7Elucas/almassr/report-1/report-1.html

and Mel's memo on dynamic scheduling

   http://www.mma.nrao.edu/memos/html-memos/abstracts/abs282.html

as well as Larry's memo on fringe rotation, phase switching and related issues

      http://www.mma.nrao.edu/memos/html-memos/abstracts/abs287.html

I have a number of comments and ideas to float.

SYSTEM SOFTWARE AND SUBARRAYS
-----------------------------

Barry's strawperson scripting appendix to the SSR interim report
brings up a number of issues that impact how subarrays are
implemented.  In particular, in a large array such as ALMA, or even
the VLA, it does not make sense for the user to specify antennas by
name, number or even location.  This is especially true for
dynamically scheduled observations where the observer has no idea at
scheduling time of what particular antennas are located where.  For
example, Barry's example

       TRANSFER (<subarray name>, <list of antennas>)

would only make sense to an interactive observer.  Still, the user
will likely need to have a mechanism to accomplish this in the absence
of real-time array status information, eg.

       TRANSFER (<subarray name>, <antenna descriptor>)

where the <antenna descriptor> object gives the number of antennas and
any restrictions (eg. location in array, receivers needed, etc.).
A concrete example is given below.

Furthermore, antennas may come into and go out of a particular
subarray in a manner not controlled by the observer schedule, for
example when an antenna or antennas are pulled out for VLBI (as is the
current case for the VLA) or out for servicing and moving (also as per
the current VLA).  When an antenna enters a subarray, it must inherit
the state of that subarray, with the LO, receiver, correlator and
everything else updated to the necessary state, as well as be
integrated into the event list for the observing.

I have adopted the terminology "state" to refer to the instantaneous 
operational mode of the subarray and all its constituent parts, and
the "event list" to be the schedule broken down into its atomic steps
(eg. each timing interval of 50msec).  Note that a change of state is
an event itself, and thus a state can be reconstructed by executing
the state-change events.  See Memo 287 on LO phase control for an
example of how this works for deterministic LO phase setting on source
changes.  Events can have different flavors, such as the
above-mentioned state-changing events (like setting parameters or
variables), or observing events (which cause data to be taken and sent
to the correlator), or informational events (which output status etc.).

AN OBJECT-ORIENTED SYSTEM?
--------------------------

It might be useful to explore whether an Object-Oriented system design
might be a better description for ALMA than the traditional Command -
Macro - Script paradigm.  At this point I feel ambivalent on this
matter, but feel its worth thinking about.  For example, one could
envision a "subarray" object, to which are attached "antenna" objects
and which connect to a "correlator" object.  I would guess that the
different subarray objects would execute asynchronously, though the
underlying event transmission (eg. from the subarrays to the antennas
and the correlator) would be synchronous with the array timing.

In this model, the subarray is the fundamental observing object.
Observations are carried out by invoking methods of the subarray.

Barry's example

$OBSERVE
    {
    &setup1
    source = nrao530 / UNTIL (15:30:00)
        {
        source = sgra* / UNTIL (.+1:20)
        source = 1749-28 / UNTIL (.+40)
        } REPEAT (60) 
    }

becomes an observe method of the subarray

 obsobj := subarray(id=1,spec=<subarray spec>)

which starts when obsobj.open() is invoked, and completes when
obsobj.done() is invoked. For example

obsobj.open()
obsobj.setrx(band=1mm,lo=loset1)
obsobj.setcor(mode=cross,bb=2pol,lta=16)
obsobj.setdata(integ='1000ms')
obsobj.setsource(src=nrao530)
obsobj.obswhile(start=now,stop='15:30:00lst')
for ( iter in 1:60 ) {
  obsobj.setsource(src='sgra*'); obsobj.obswhile(start=now,duration='1:20lst')
  obsobj.setsource(src='1749-28'); obsobj.obswhile(start=now,duration='40lst')
} 
obsobj.done()

The looping and timing is done here either in a script-level "for" loop
(or a "while" or even "if" control structures), or in the provided
obswhile method.  In addition to Barry's controls

    REPEAT(<integer number of repeats>)
    UNTIL(<time (either constant or relative)>)

I would add the wait control

    AT(<time (either constant or relative)>) 

which could also be followed by REPEAT or UNTIL. In my scheme

    obsobj.obswhile(start=start_time,reps=1)

would be the equivalent of an AT.

(I apologize for the aips++isms, such as := for assignment, this is
the object oriented package I am most familar with.  Also, a more
generic notation could be used to describe this, rather than the above
which looks too much like a language spec!  The mysterious dm.xxx
thing that appear is meant to be a "measures" object.)

Note that the source nrao530 is actually an object itself, of type
"source", for example Barry's

$SOURCE <source name>
    {
    type = STAR
    ra = <J2000 right ascension>
    dec = <J2000 declination>
    calibratortype = <NON | PHASE | AUXILIARY | FLUX | BANDPASS | POINTING>
    [label = <text to be passed to processing programs>]
    [processing = <list of $MESSAGE blocks>]
    }

translates to

nrao530 := source()
nrao530.setsource(type='QUASAR',direction=<direction object>,
   calibratortype='PHASE')

note that in aips++ the direction object could be constructed 
direc := dm.eqtodir(ra='17h30m13.55',dec="-13d02'45.8",eq=J2000)

Sources could also be done as a simple record construct

nrao530.name := 'NRAO530'
nrao530.type := 'quasar'
nrao530.direction := <direction object>
nrao530.calibratortype := 'phase'

rather than methods of an object.  The full object approach would have
the advantage that it could have methods to precess or do other
things.  Also, in the case of mosiacs, the record approach would be

m31mosaic.name := 'M31 Mosaic'
m31mosaic.type := 'mosaic'
m31mosaic.direction := [< list of pointing centers>]
m31mosaic.calibratortype := 'none'

or as an object

m31mosaic := source()
mosaicobj := dm.raster(nrows=10,ncols=10,rowvar='dec',colvar='ra',
   rowinc='+15arcsec',colinc='+15arcsec',start=<direction>)
m31mosaic.setsource(type='mosaic',direction=mosaicobj,
   calibratortype='none')

or something similar.  This allows us to hide the dirty details of the
mosiac in the methods to make a mosiac (direction) object such as 
dm.raster, dm.circle, etc.

The tricky part is how to specify a subarray, which I have swept into
<subarray spec> on instantiation of the object.  This could be a list
of antennas [1,2,3,4,5,8,24,33,41,45,63] (most useful for interactive
work), or possibly by number and antennas and radial location
[number=8,radius='<1km'] or just the number if it doesnt matter where
in the array they are as long as they have the proper band working
[number=1,band=3mm] and so on.  In addition to specifying the subarray
on instantiation, there would be a function to transfer antennas out
(or into) the subarray, such as

obsobj.transfer(what=[antlist=[1,2]],action='deallocate')

to remove antennas 1 and 2 from the subarray (freeing up to the
general pool), or 

obsobj.transfer(what=[antlist=[1,2]],action='transfer',where=otherobsobj)

to transfer to another (presumably concurrent) subarray object.  Of
course, nested subarrays are possible.  It might be useful to have a
way to subordinate sub-subarrays 

obsobj.spawn(name=subobsobj,desc=<sub-subarray descriptor>,
   inputtype='function',inputobj=subobjfunc)

function subobsfunc () {
   subobsobj.open()
   <set of commands for this subarray>
   subobsobj.done()
}

where this descriptor is an explicit subset of those currently part of
obsobj. I would envision that antennas deallocated from this subarray
would rejoin the parent subarray.  The child subarray would be its own
asynchronous process (with methods subobsobj.*) and would execute the
commands in the function or file until completion.  At the end after
.done(), the antennas are returned to the parent subarray.

As the operator may be moving antennas in and out of the subarray
manually, there would also be  

obsobj.transfer(what=[antlist[50]],action='add')

to bring antenna 50 in from the general pool of unallocated antennas
(presumably after it has been freed up).  These antennas would then
inherit the state of the antennas already in the subarray and
seamlessly join in.  I suppose this would be done by executing the
state-changing events (but not the previous observing or informational
events) and joining in the current observing command.

I guess by necessity the execution of commands will be consecutive in
general, with the system waiting for the previous command to complete
before the next is executed.  This could be controlled through a
global variable (eg. dowait:=T as in aips++). There might have to be
a tag to indicate which commands (particularly those activated outside
scripts manually) have priority

obsobj.transfer(what=[antlist[50]],action='add',priority='interrupt')

which would take effect instantly (on the next timing cycle) without
waiting for the current command to complete.  There would be levels
of priority (interrupt,current,queue) which would let the current
command finish or add the command to the end of the subarray queue.
Note that this supposes some virtual queue where the parsed commands
are located for execution.

There are a number of commands which would be informational without
changing the system state or performing an action.  These would be
defaulted to interrupt priority (except within a script where they
would inherit a dowait)

obsobj.showcor(what=all)	! show correlator state
obsobj.showsub(what=all)	! show subarray state (like current ants)
obsobj.showqueue(what=all)	! show current queue

FINAL THOUGHTS
--------------

My impression from reading the documents, especially the draft SSR
interim report, is that having significant subarray capability and
the coexistence of interactive and scheduled operations, plus dynamic
scheduling, will have a profound impact on the design of the array
operating system.

An object oriented control system would provide unlimited flexibility
at the cost of user complexity.  This is potentially the most elegant
way to design the operation interface with the same look for
interactive and scripted operation.  It would also look like the
analysis pipeline (assuming some object-oriented package like aips++)
and thus allow fairly seamless integration of the analysis (these
could be attached as methods of a subarray, or the data could be
transferred in real-time from the subarray to a pipeline process.

The (or one) downside to this is that such a rich control language may
overwhelm the operators.  However, this is remedied in aips++ by a
GUI overlay.  This would be fairly easy to implement with any object
oriented system (the methods easily attacth to GUIs).  On the other
hand, operators with reasonable computer skills should be able to 
handle this system, especially if they have taken courses recently!

I thought it might be interesting to float this possibility at this
early time in the SSR development, in order to stimulate discussion
and thinking...

    -Steve Myers

-------------------------------------------------------------------------
|:| Steven T. Myers                      |:|  Associate Scientist      |:|
|:| National Radio Astronomy Observatory |:|                           |:|
|:| P.O. Box O                           |:|  1003 Lopezville Rd.      |:|
|:| Socorro, NM 87801                    |:|  Ph:  (505) 835-7294      |:|
|:| smyers@nrao.edu                      |:|  FAX: (505) 835-7027      |:|
|:| http://www.aoc.nrao.edu/~smyers      |:|                           |:|
-------------------------------------------------------------------------