[evla-sw-discuss] pulsar data

[David Harland]

Bryan Butler wrote:

>BTW, after discussion with walter today, we are now thinking that PULSAR is not 
>a mode, but rather an intent, in our current model.  can we attach extra 
>information to the scan that is dependent on intent?
>  
>
Walter Brisken wrote:

>As an addendum to my original message I would like to put up for 
>consideration that "pulsar mode" is not actually an observing mode.  In 
>the current lingo modes are excusive (ie cannot do mosaicing and other 
>mode simultaneously).  Rather I think the pulsar capability can be applied 
>to any existing mode.  It is in Bryan's words "an intent".  If so I'd like 
>to have finer-grained intents : "pulsar timing" and "pulsar imaging". 
>This is mainly for the benefit of downstream software.
>
Michael Rupen wrote (in response to above):

>I don't think that's right.  Intents are labels which are irrelevant except
>for the downstream software.  Gating and binning actually affect the setup of 
>the backend (the correlator), and/or which data are stored, so you need to
>know them at the time you observe.   On the other hand it doesn't seem like
>a "mode" like mosaicing, fast switching, tipping, etc.  I think it's more
>nearly a scan attribute (apologies to Dave for getting the term wrong),
>like the integration time, which in Dave's scheme I would think would just
>go in with the overall Resource settings (like the number of spectral
>channels, recirculation factor, and so forth).
>  
>
I agree that it sounds like we do not have a ScanMode of "pulsar", but 
instead have new ScanIntent entries for "pulsar timing" and "pulsar 
observing".

For those not familiar with the SSS model for scans, i'll summarize a 
portion of the model below.

A given Scan can have one or more "intents" -- the reason(s) for which a 
scan is being peformed. Typical intents are "observe target", "determine 
RFI", and "calibrate complex gain". Up to the point of observation 
preparation, we don't do anything useful with the ScanIntents, other 
than providing a way for the observer to specify them. Presumably, 
downstream software will respond differently for different intents.

Each Scan has one, and only one, ScanMode. Some examples are: "standard 
observing", "mosaicing", "tipping", and "reference focusing". During obs 
prep, the observer first picks a mode, and based on that mode different 
parameters are presented to the observer for data entry. For example, if 
the observer picks "reference focusing", the obs prep tool (OPT) will 
ask the observer to submit a list of focus offsets. Choosing a ScanMode 
causes the system to construct a specific variety (subclass) of a Scan, 
and this dictates the data collected.

A Scan has various other attributes that are common to scans created for 
all modes, such as: whether or not to apply the last reference focus, 
...the last phase offsets, ...the last reference pointing, in what 
direction the antenna should "wrap", etc.

So far the ScanModes have dealt with physically moving the antenna(s), 
or some part thereof. They have not helped determine how the front-end, 
correlator, or back-end are set up. From the various emails on this 
topic last week, it looks like we're dealing here w/ correlator setup. 
This kind of information is slated to be held in the "Resource" portion 
of the object model.

So:

    * No new ScanMode
    * A couple new ScanIntents
    * Possible influence on Resource setup by ScanIntents

David