Minutes from SSS Mtg 2008-Apr-15
 
Attendees: B.Butler, M.Claussen, D.Harland, B. Hesman,    G.v.Moorsel,
           F.Owen,   J.Rochford, M.Rupen,   L.Sjouwerman, B.Truitt, S.Witz

In the first part of the meeting we referenced the document that was sent
with the meeting notice (a link to that document will be provided at the
end of this one).  Section numbers are from the referenced document.

Section A - Work Flow

  + The assumption that the OPT creates a Jython script that is then fed
    to the executor is valid.

  + Yes, there will be a "submit" process initiated by the observer.

  + What happens to the script depends on whether we're doing a dynamically
    scheduled project or a fixed time project.

    - Claire needs to be consulted to see if we must use dynamic scheduling
      for Ka.

    - For fixed date scheduling, things will be easier.  The OPT would do
      something like place the script at a known location using a prescribed
      directory and file naming scheme.

    - For dynamic scheduling we'll need to work with Barry to see how to get
      data to the scheduler that is not present in the script.  One possibility:
      a partial observe file that has things like wind and API constraints,
      among other things, in it.

       * NB: The OPT is not currently capturing scheduling constraints.
  
  A.1: Yes, there s/b a "submit" button.

  A.2: Probably need to send emails to operators and observers.

  A.3: Observer can "resubmit".  This places new script in the known
       location with a slightly altered name.  The previously
       submitted script(s) is left in place.

  A.4: No, the script itself does not have enough information for
       the automated scheduler to do its thing.  As mentioned above,
       we could create a stubbed observe file.  Alternatively, we
       could put this info into the script (as comments?).  We'll
       need to discuss w/ Barry.

Section D - Clarification of Requirements

  D.1: Keep bracketed loops, but do not make them the default.
  
  D.2: The only modes we need to support initially are
       Standard Observing and Interferrometric Pointing.
       There was discussion about Fast Switching.  The conclusion
       was that the help text should mention that scan loops can
       be used to accomplish the same goals that fast switching had
       done previously.  The ability to do Tipping scans can be
       delayed until later.

  D.3: Yes, we need to capture scheduling constraints.

  D.4: No, for this Ka project, we do not need to improve
       calibrator searches.

  D.5  No, we do not yet need to rework the groupings within the
   &   standard calibrator catalogs.  There was talk about putting
  D.6: together a group of calibrators that would be useful for
       high frequency observations, but having this in place is
       a low priority.

  D.7: Yes, NRAO will create a catalog of standard instrument
       setups.  Lorant will be in charge of this.


At this point we gave a demonstration of the setup of the VLA
correlator.  In a previous meeting changes had been suggested
and many of these were incorporated in time for this
presentation.  Changes that were suggested in this meeting:

  + The default integration time should be 3.3 seconds.

  + In the selection box for receiver bands, only Ka should be
    selectable at this time.

  + The number of lags shown in the bandwidth code table is wrong.

  + Add a column for the bandwidth code in the BW code table.

  + In addition to showing central frequencies, show the
    resulting frequency ranges (using the selected bandwidths).

  + Change the wording for the channel zero yes/no option.

  + Move the yes/no buttons further from the selection of
    the spectral processing mode.

  (There may have been other little changes that Brian
   has noted and will make.)

  NOTE: the demonstration was run from Dave's PC and is not
        yet available on webtest.  When we update webtest
        we'll send a notice to the regular meeting attendees.