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

[Bryan Butler]

On 8/17/06 17:39, Walter Brisken wrote:
> 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?

i would guess that we want the converted value here.  so it is the job of 
obs2script (or the OPT) to make that conversion.


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

these are all supported (well, except the "check source" one - we should talk 
about that, walter) within the definition of Scan Intents in the overall design. 
  these and many more.

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

as i just said, i dislike this - an intent is not a property of a source - it is 
what you want to *do* with the source.  let's keep them separate, since they are 
logically two distinct things.  let me describe what we have in a nutshell:

Project has:
    one or more Program Blocks (PBs)
    (other stuff)

PB has:
    one or more Scheduling Blocks (SBs)

Scheduling Block has:
    one or more Scans
    (other stuff)

Scan has:
    one or more Subscans
    (other stuff)

Subscan has:
    Mode
    Modifier
    Intent
    Source
    Resource (this is hardware setup, including antenna & correlator)
    Timing

Mode is one of:
    STANDARD
    INTERFEROMETRIC_POINTING
    SINGLE_DISH_POINTING
    TIPPING
    AMPLITUDE_DELAY_CALIBRATION
    FOCUS_CALIBRATION
    etc. (dave can send the full list to those interested, and i've
          probably gotten the names wrong, but you get the idea)

Modifier is one or more of:
    APPLY_POINTING_OFFSET
    APPLY_AUTOPHASE
    etc. (dave can send the full list to those interested, and i've
          probably gotten the names wrong, but you get the idea)

Intent is one or more of:
    TARGET_SOURCE
    PHASE_CALIBRATOR
    FLUX_DENSITY_SCALE_CALIBRATOR
    BANDPASS_CALIBRATOR
    etc. (dave can send the full list to those interested, and i've
          probably gotten the names wrong, but you get the idea)

Source has:
    one or more Subsources
    (other stuff)

Subsource has:
    Position
    Velocity
    Brightness distribution

etc...

please let's try to start using this stuff across the development.  again, we 
need to sit down and discuss this.

	-bryan