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

[Bryan Butler]

On 8/17/06 16:22, 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 believe that this should be explicitly set in the script rather than relying 
on something an operator types in.

from OBSERVE files we can always get it from the first line, and obs2script 
already parses it out.  it could easily be passed on from there.


> public class VlaCorrelatorSetup
> No surprises here.
> public void setMode(String x)		// things like "2AC", etc.

i might suggest calling this setCorrelatorMode rather than setMode, since there 
is also an "observing mode" (e.g., columns 58-60 of the source card, and we have 
a similar construct in the new overall architecture).

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

before commenting on any details, let me say that we (dave & brian on the 
programming side, myself, claire, and michael on the science side) have been 
working *very* hard on the definition of scan modes and intents for the past 
weeks.  it would be a shame to duplicate that effort.  we should get together 
soon to see how we can merge the efforts - i.e., incorporate the more general 
classes that dave has been implementing into the executor so that you don't have 
to re-invent all of this.

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

we have been calling these "modes" in the overall design.  if it affects the way 
that things are observed, it is a "mode".  if it is information that is needed 
for processing down-the-line, it is an "intent".

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

i would rather not overload this with more than one purpose.  if it carries 
submode, call it such.  define something else to carry the numeric qualifier.

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

i don't like mixing the Source definition with the Intent.  they are two 
distinct things, and mixing them will lead to confusion, IMHO.  let the Scan 
contain both the Source and the Intent separately, then push the Scan into the 
subarray.  this is the concept we are working toward with the overall design.

we clearly need to sit down and discuss some of this.  dave will be out 
tomorrow, but i'll set up something next week.

	-bryan