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