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

[Ken Sowinski]

My turn now.  I assume all the comments by others as read.
While agreeing that we don't wnat to create throw-away code
unnecessarily I want to point out that the context here is
the interim DCAF which packages data from the old correlator
into facsimiles of the classic VLA archive record.  And that
observing is specified by scripts derived by simple
transformations of traditional .obs files.

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 take no sides here, but note that we have a long history
of observers getting this wrong, or malformed, or both.
Eventually the observing prep SW can enforce this stringently,
but that will not be the case in the near term.

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

This is a member of the VlaCorrelatorSetup class so confusion
with observing mode is unlikely.  Identical method names in
different classes is a style question you can argue about.

> 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

We are dealing here with the old VLA correlator.  It is sufficient
to specify the integration time here in seconds.  Deep down
integrations are measured in heartbeats and somewhere deep down
that relation is defined.  The current algorithm is anything
greater than a second is adjusted to the nearest multiple of
1-2/3 seconds.  Anything less than a second is adjusted to the
nearest multiple of eight heartbeats.  This requirement is a
result of the way continuum processing is done and carries
over to line observations by laziness.


>From the long hierarchy that Bryan supplied it appears that
'intent' seems to be a shorthand for 'why am I observing
this calibrator?'.  Barry is using it with a more sweeping
intent.  My memory of our discussions in the past is more
in keeping with Barry's usage here.  It seems to be about time
to add a few more terms to the long neglected EVLA glossary.

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

This was sort of recognized long ago.  If you leave the calcode
blank and require pointing a calcode of 'P' is supplied; 'V' if
a phased array pbservation is required.  I not also that there
are many calibrators in the DB with a calcode that indicates the
provenance of the calibrator position measurement rather than the 
positional accuracy.  This issue is ripe for rationalization.

> 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 think it is important to keep submode and qualifier separate.

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

In spite of the arguments I've read I don't think it makes
a lot of difference as long as the implemtation allows, as
Walter noted, for multiple intents.  If asked to choose it
seems to me that this is more a property of an observation
(scan in our parlance) than the source.