Minutes from SSS Mtg 2009-Mar-17

Attendees: D.Harland,  B.Hesman, G.v.Moorsel,  F.Owen,
           J.Rochford, M.Rupen,  L.Sjouwerman, B.Truitt

Summary

This meeting focused solely on improvements to the OPT. The features discussed are given below.

Organization of Scan Tabs

  1. Scan intents will be moved out of its own tab and placed on the "Overview" tab. We will try to fit them to the right of the "scan timing" column.

  2. The "Details" tab for tipping scans will also be merged into the "Overview" tab.

  3. In the future, when systems downstream of the OPT are capable of handling it, we will allow users to do a tip a the azimuth of the prior scan. In the meantime, we will change the default azimuth from 0 degrees to 165 degrees.

Meaning of Start / End in Schedule Summary Report

This report is the third, or bottom, table on the "Scheduling Block Summary" tab of a scheduling block. Let me define here that a scan includes the time to slew from wherever the telescope is currently pointing to the source of interest plus the time spent observing the source of interest. At issue was the values for concepts such as the azimuth and elevation in the columns whose names include "Start". Currently the values in these columns are not those of the start of the scan, but the values when the slewing portion of the scan is complete and observation of the source begins. It was proposed that the display show values as of the start of the scan. This proposal was rejected and the body of the table will stay as is.

The main concern was that for the first scan you cannot see what the assumed telescope position was. A compromise was suggested wherein we display the starting position in the header of the table. We will make this change.

Reconciling How Long a Scheduling Block Takes to Run

We recently added a user-friendly feature to the scheduling block nodes of the navigation tree -- we appended the amount of time the SB will take to execute. For dynamically scheduled SBs with scan(s) specified with on-source timings, this cannot be known with certainty because we do not know when the SB will actually start and we do not know where the telescope will be when it does start. The code responsible for calculating this value is using a hard-coded assumed telescope position and wall clock time. The wall clock was used just to get this feature started; we intended to find out what time we should actually use. One suggestion was the starting value of the "LST Start Range" in the scheduling block details. The main issues here are that the time shown in the tree is not the same time shown in the "Scheduling Block Summary" tab and that the time in the tree changes as the user initiates activity, even if that activity has nothing to do w/ scan timings. The former is because the summary tab uses the "Scheduled Start" values on that page to perform the schedule calculations, and those assumed start values exist only on that page and are not available anywhere else. The latter is because the activity caused an update of the time displayed in the tree and the wall clock time has changed.

The suggestion was to save the "Scheduled Start" values with the rest of the project model (including the assumed starting position of the telescope). Once these have become part of the model, we will use them to calculate the time in the tree.

"Generate Script" Tab of Scheduling Block

As currently constructed this tab causes a lot of confusion. For a fixed-date schedule the script shown will be the one actually executed on the telescope. For dynamic schedules the displayed script is based on the assumed starting time and the assumed telescope position at the assumed starting time. When actually executed on the telescope it is nearly certain that these two assumptions will not be simultaneously met and, therefore, the script run is not the one displayed. We reiterated that the "real" script is generated just-in-time by the scheduler when the exact starting time is known.

Some conclusions we reached:

  1. Normal users don't need to see the script at all. We will use the user-group concept to give only those people who want to see the script that ability. We expect this to be the group who normally attends the SSS meetings, but members of this group could opt out and others could opt in.

  2. This tab will be renamed to "Validate & Submit".

  3. This tab will have 2 buttons that all users will see. The first is "Validate", the other is "Submit". "Submit" will not be an active button until after "Validate" has been used to demonstrate that the scheduling block is capable of being scheduled. The "Submit" button will provide feedback along the lines of "your SB has been successfully submitted". [After the meeting Brigette talked to Dave about how the JCMT observing tool does this -- a way that she really likes. Brigette and Brian should meet to discuss this.]

  4. The fact that the validation button had been pressed would not be permanently stored in the database.

The programmers need to review for themselves, and for the astronomers, just which kinds of errors make the SB unsuitable for submission. These might be things like no-time-on-source or source-too-low-in-sky. After we have that knowledge, we need to reopen the discussion on whether or not we exempt the first scan from some of these checks. Ie, should the OPT always think of the first scan of a dynamically scheduled block as being a dummy, and therefore less important than other scans?

Changing Scan Timing from On-Source to (Total) Duration

We spent some time talking about initial dummy scans. A couple reasons were presented for having dummy scans: errors that have occurred in execution on the first scan and absorbing the initial amount of slew time from the unknown starting position of the telescope. The group decided we should not base anything we do on errors that may or may not be present downstream. Observers do, though, need to worry about this initial slew. Also entering the conversation was the artificial requirement that scheduling blocks be increments of one-half hour. We discussed using on-source times for scans and which scan was most acceptable to put at risk of receiving insufficient time: the first or the last. Different observers have different opinions, and perhaps the same obsever has different opinions for different observations.

Frazer then mentioned a feature which JObserve has -- the ability to change all of one's scans from time-on-source to total-duration. It was suggested that an observer might initially set their scans up as time-on-source and then play around with assumed start times. After looking at slew times for various assumed start times the observer would then like to "lock in" these durations by taking some action (pressing a button) and converting all scans in that scheduling block that are currently defined as time-on-source to total-duration. The programmers asked if this decision could be irreversible and the scientists allowed that it could be.

Calculating Worst-Case Scenario for SB's Length of Time

We talked about approximating the longest expected length of time it would take a scheduling block to run. The suggestion was to use the LST start range entered by the user and calculate the length of time based on those start LSTs, using, say, every 1/2 hour within that range. If we're to implement this, we'll need to flesh it out a little more.

  1. Can we use the assumed telescope position in these calcs, or do we also need to consider a software derived worst starting position?

  2. Would this worst-case time be used only in the tree display, leaving the summary page to continue to use the assumed start time entered by the user? If the answer here is "yes" then we must be content to again have two different times.