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

[Walter Brisken]

Some comments...

On Thu, 17 Aug 2006, Barry Clark wrote:

> 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.

I still think the job ID should be internal to the script, even if there 
is a sound filename convention.  It might be convenient to allow the job 
ID to change within a scritp, for example in a single large startup 
script.  Maybe that's not practical, but I'd hate to loose the 
flexibility.

> 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

Currently integration times are in integer seconds (though get converted 
to the actual multiples of 0.41666 seconds somewher).  Do you expect this 
converted value or the original integer seconds?  How will it handle 0.4 
and 0.8 second integration times if this is the case?

>
>
> 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.

I completely agree!

> 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?

Whatever system that is used should allow more than one "intention flag" 
to be set at once.  For example, one could imagine one source (in one 
scan) being the Bandpass, Flux, and Polarization calibrator for a project. 
Another intention flag that could be added is "check source" as is often 
used in VLBI.  Pipelines may like to know, as well as the PI a decade 
after observation.

As for the implementation, I favor attaching intention to the source 
rather than using subarray configuration as it will likely simplify evla 
scripts.