Re: subarrays

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

On Mon, 6 Mar 2000, Robert Lucas wrote:

> Dear Steve:
> 
> Thanks for your comments !
> 
> For this phase of definition of science requirements for ALMA
>  Software, we have tried as much as possible to include science
>  motivated requirements and avoid software motivated ones, leaving
>  those for the design phase. There is no doubt however that object
>  oriented technology will be used when designing the software (there
>  is a consensus for this in the joint software group, I believe); but
>  at the level of requirements this kind of language should be avoided,
>  so that at least this first report can be understood by astronomers
>  and engineers, not only software-oriented people. I would say you're
>  one step ahead already.

Probably true.  But OOP terminology is starting to make its way into the
general scientist population (at least in the post-Fortran 66
generation :-)...

However, I am probably jumping the gun in worrying about the detailed
implementation (I prefer to think of a concrete example).

> Furthermore, I'd personnally like objects to be only software objects.
>  At the interactive level the operator/astronomer does not need to
>  know much of the underlying detail. 

True, but sometimes I fear we are dumbing-down the "astronomer" too much.
It may be appropriate for a complete novice to only see a limited set
of commands, but eventually they will want more power.  I would be curious
as to the fraction of VLA users that need or use more complex features...

> As for sub-subarrays, my question would be: for which use ? 

The easy example is the one Barry presented of detaching one or a few
telescopes now and then to do tip-curves.  You want those to come back
into the main subarray and it would be silly to have to submit a separate
schedule.  Another example would be where only some of the telescopes
have a particular frequency band available (as was the case for the VLA
until recently at 43GHz), where one subarray would detach to observe at
this frequency (eg. 850 GHz) and the remainder would observe at another
frequency (eg. 650 GHz).  Again this might most economically be done
as a "sub-subarray".

> Also I tend to put more emphasis than you do on the readability of
>  scripts for human beings. For instance instead of
> 
> obsobj.transfer(what=[antlist=[1,2]],action='transfer',where=otherobsobj)
> 
> I think most would like to type, say:
> 
> transfer antennas 1 2 to subarray B

At least in the case where the antennas are refereed to by number, which
is not likely to be the dynamically scheduled ALMA scenario we would
prefer.  Perhaps,

   transfer 2 antennas in 0.5km - 1.5km to subarray B 

would be reasonable.  However, it is likely to be difficult to take care
of the more general cases with the style and still have a robust grammar
(though not impossible).

On the other hand, the other operations described in my note could be
written as

   transfer all antennas from subarray B
   remove antennas 1 2 from subarray A
   add antennas 1 2 to subarray A

or 

   allocate 3 antennas within 1.5km to subarray B
   <bunch of commands for subarray B>
   deallocate subarray B

I'm still not sure what sort of descriptors we will need to
specify antenna subsets for subarray control.  It depends upon
the configurations to some extent, such as whether we have
distinctive "arms" and "rings", or just pseudo-random locations.
But you could envision things like

    any

    inner ring
    outer ring
    E,W,S arm (or whatever)

    within distance X
    outside distance X
    in X - Y

    innermost
    outermost

of course with a prefix N for the number chosen.

> 
> which would save me the typing of 4='s, one () pair, two [] pairs, not
>  to mention ''. Which I think improves human readability.

Sniff, programmers are humans too :-) 

Actually, all those extra pairs are for readability.  Most
implementations would allow the terse version

obsobj.transfer([1,2],transfer,mysubarray)

if that helps.  But I prefer the longer version.

However, this may be mostly a matter
of what layer rides above the real control software.  For example, we
already envision a GUI to drive interactive operations.  Some have
suggested a GUI schedule wizard to prepare user schedules.  It might make
sense to have a more human-friendy parser layer also.

   cheers, Steve

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