[evla-sw-discuss] Extensions to script for IDCAF info

[Barry Clark]

Proposal code.
I suggest we get his by convention.  The Job ID is already present
and used.  Operators have typically been entering the file name
here, which contains the proposal code.  I suggest we ask them to
put the proposal code first - that is, for example, entering the
jobid as 'AH913.679<and maybe other stuff>' instead of the 
'679H913.OBS' they have been using.

public class VlaCorrelatorSetup
No surprises here.
public void setMode(String x)		// things like "2AC", etc.
public void setBandwidth(int w, int x, int y, int z)
					// the usual 0 to 9
public void setProcessing(String x)	// blank or "H", mostly
public void setIntegration(double x)	// in seconds


public class Intention
I favor, for the moment, something extremely simple, just adequate
for current (Modcomp emulation) purposes, but perhaps expandable to 
a somewhat more general context.
public void setIntent(String x)
    For purposes of Modcomp emulation, the intent would mostly be the 
    observing mode plus calibrator code, with the absence of an Intention 
    the equivalent of an intent of "   ".  So pointing would often be
    "IAC", and run of the mill calibrators would be "  A" or whatever.
    For nodding observations, it might be "NOD " or "NODB" or whatever.
	A digression:  It's always seemed to me that our use of calcodes
	just for positional accuracy is terribly wasteful - you almost never
	want to know about that except at script generation time, and I 
	don't see much reason to put them in the script.  The character
	in the script would be better used to designate "phase calibrator",
	"flux calibrator", "pointing calibrator", etc.
public void setState(int n)
    The state would be used for the same purposes as the Modcomp 
    submodes (though maybe not identically).  It could also be used with
    the blank observing mode to carry the source numeric qualifier, which
    I guess we need to support for historic reasons.
public List <String> getModifiers()
    The immediate use for this would be to hold a list of the names 
    of reference antennas, for holography or delay setting or the like.
One can imagine other things that would be useful in a general purpose
Intention, but they do not seem necessary for Modcomp emulation.

Another question is what to do with the Intention.  We could set it into
the subarray with a 
public void setIntention(Intention inten)
just as we do with the VlaCorrelatorSetup, just before we call
subarray.execute(start_time)
However, there is another interesting possibility - making it a part
of the Source.  Carrying the two around together makes some things 
tidier.  (In this case I'd bring the state setting routine out to the
Source surface, so one could, for instance, create a Source with a 
pointing Intention and then just have the pointing routine set the state 
appropriately for the offset.)  I've no strong feeling about which path
to take here.  Anybody?