[evla-sw-discuss] Illegal frequency setups

[Barry Clark]

When the entire system is controlled by the Executor, there is the 
usual LoIfSetup class which describes how to configure the LO and IF
systems of the EVLA antennas.  In addition, there is a VLALoIfSetup
class which describes how to set up VLA antennas.

The EVLA LoIfSetup does not include the bandwidth setting of the 
baseband filter, located in the T5, because that is a strictly transition
item, and I was trying to preserve the LoIfSetup class to deal with
EVLA antennas over the long haul.  Instead of adding filter bandwidths
to the LoIfSetup class, I decided to use the VLALoIfSetup object to
set these filters, even for EVLA antennas.  This means a VLOLoIfSetup
object is necessary for all observations, even for a EVLA only subarray.
So I caused a VLALoIfSetup object to be created for each observation, 
if one had not been specified in the script, making it set up for the
same frequencies specified in the LoIfSetup object.

This has caused problems, because when frequencies are used that the 
EVLA can tune to, but the VLA cannot, the VLALoIfSetup throws an exception
on creation, saying "I can't do that."  This causes script execution to
be aborted.

The proposed resolution to this is to set the frequencies to the default 
frequency for the band whenever an illegal frequency is requested.  This 
would be noted in the Executor log (which nobody ever looks at, but never 
mind).  Not quite as clear what to do with a LoIfSetup for S band or KA 
band, but I can think of something.

If just this is done, it may have amusing side effects.  If the Modcomps
are controlling the correlator and VLA antennas, if you tune a subarray
containing both VLA and EVLA antenna to a frequency illegal for the former,
you will get no fringes on the VLA antennas, and good fringes on the EVLA
antennas.  However, if you do this with the Executor controlling the 
correlator and VLA antennas, you will get nice stable fringes among both 
the EVLA antennas and the VLA antennas, but no fringes between the sets, 
because the VLA antennas will be observing at quite a different frequency.  
(The frequency in the archive record will be that of the EVLA antennas.)

With a modest amount of extra work, I can either stop fringe rotation for
the VLA antennas, which will make things pretty clear what works and what
doesn't, or generate an Alert which can be used for flagging the VLA antennas,
which would leave their data there but flagged.

It impresses me that an early useful application for script-controlled
subarraying would be to have all antennas looking at the same sources, 
but the VLA antennas using a different frequency than the EVLA antennas
when they cannot tune to the frequency or band used by the EVLA antennas.

In case somebody wants to use odd frequencies before I get around to fixing
the problem in the real time part of the system, the workaround is:

Where the script calls 
subarray.setLoIfSetup(...)
instead call
subarray.setEvlaLoIfSetup(...)
And somewhere, near the beginning of the script, insert
subarray.setVLALoIfSetup(VLALoIfSetup("10GHz"))

For the record, the Exception based approach to these things was 
suggested by the thought that in an era of dynamic scheduling, an observer
would prefer to have his script kicked off, rather than to have his allocated
time used to produce garbage data.

Comments accepted.