Sequence Model Goals

This document contains initial thoughts about changes to the sequence model and the impact they could have on the UI. The ideas are still pretty rough but the hope is that this will provide a starting point for discussing and refining our goals. WARNING: this writing is pretty much stream of consciousness.

Overview

• Flatten the entire sequence hierarchy into a single node.

• Combine instrument, obslog, sequence, and at least part of the seqexec UI into a "Sequence" node.

• Allow multiple sequence nodes per observation.

• Internally each sequence becomes a simple list of steps, so there is no need to generate it every time it is needed. The UI will be a challenge.

• And/or logic between Sequence nodes eventually? Then not needed between observations?

• Need a way of identifying sequences in order to queue them. What is the impact on the QPT? How is planned time computed? What about observation status if some sequences are complete and others not? Many issues to work out.

• There is benefit to switching to this model even before allowing multiple sequences. In other words, I think the work can be split into major phases starting with a single sequence per observation.

  • Flat sequence model and basic sequence editing.
  • Combine obslog and sequence node.
  • Multiple sequences per observation.
  • And/or logic.
  • Seqexec controls.

Sequence Node UI

• Roughly, a "Sequence" node could be divided into 3 areas:

  • Sequence Log - today's "Observing Log"
  • Sequence Execution - current dataset being observed (if any)
  • Sequence Planning - where remaining steps are configured

• The Sequence Log appears once you first slew to the target or in general whenever an event from the seqexec is received for that sequence.

  • For each dataset it shows the label that is assigned, the FITS file name, the QA state, GSA state, comment (if any) and then the config below.

  • It seems like we should allow downloading datasets directly from the new GSA. Perhaps they should even automatically download while observing (if requested)?

  • As datasets are executed, they are pulled up from the planning area below to become immutable entries (as far as the config is concerned) in the log.

• Sequence Execution shows the currently executing dataset configuration and provides basic controls to pause and resume, stop, abort. Others? Probably a one-click way to duplicate the dataset into the top of the planning area, etc.

• The Sequence Planning area is where the remaining sequence is put together.

  • This can always be mutable, even while ongoing and after executed.

  • If there are entries here though, the sequence won't be considered executed by default.

  • Truly static values (like the MOS pre-imaging flag) should be presented differently somehow and not be editable once the sequence has started.

  • Perform complete Phase 2 checks on all steps. Show warning directly in the steps that have issues. (Today some phase 2 checks are only performed on the static instrument node.)

  • Here "breakpoints" can be configured to automatically pause the sequence when reached.

Sequence Node UI Alternative

• Here's an alternative that puts the log, execution, and planning into a single table-like view.

  • I think I like this better because it emphasizes that it is a single sequence with steps in different stages of execution. Past (Log) / Present (Execution)/ Future (Planning).

  • Only one step is selected at a time which seems straightforward.

  • Past and present (log and execution) show the configuration in grey to indicate that it cannot be edited.

  • Only steps in the planning section at the bottom could be rearranged or edited.

  • The "QA State" and "Comment" options would appear when you select an executed step.

  • This view also provides a place for viewing the entire configuration for executed and executing steps.

Sequence Planning

• Sequence Planning would have two views / editors. A sequence table somewhat like the one we enjoy today and a loop hierarchy editor as well. I believe we can go back and forth between the two.

Sequence Table

• The sequence table shows a row per dataset. Columns appear for every parameter that differs across the sequence. Parameters that never change are not shown in the table.

• Select a row and you can edit the configuration for that step arbitrarily. Hopefully just a simple property sheet look for all instruments.

• Insert and delete rows at-will anywhere. Duplicate a row or rows. Drag/drop to rearrange.

• Multi-select rows and the editor shows you values common across all selected steps and lets you change the value for all steps at once.

• Phase 2 checking can be performed at all steps. Pinpoint the steps with problems.

Sequence Loops

• Initially creating a sequence or doing major edits may be easier to do with a nested-loop view like we have today.

• It should be possible to map back and forth, though there will sometimes be multiple ways to arrange loops that generate the same sequence.

• For partially executed sequences, the loop structure might get a bit convoluted since the already executed steps would not be included.

• This is not stored anywhere and doesn't appear in the science program tree view. Rather, you switch between the table view and the nested loop view.

Smart GCAL

• The UI doodles above deptict a "Night Baseline GCAL" row and show how that expands to two steps.

• The expansion will change as the GCAL node is moved around in the table (or in general as changes are made to the row that preceed it.)

• Once part of a multi-step GCAL is started, the notion of "smart" goes away and the current state of the expansion is kept as normal sequence steps.

• Similarly, if the user should edit a smart GCAL expansion (multi-step or not) it also loses its intelligence and becomes an ordinary manual calibration step.

Implementation Notes

Storage and Sync

• Just like today's obslog node, the new Sequence node will feature a mix of values that are user-editable and values that should only be assigned in the server while executing the sequence.

• I think the solution to keeping this reasonable will be to maintain two program nodes per Sequence (though the OT will show them as one node). This is exactly the same thing we do for today's Observing Log node.

  • One node contains items edited only on the server. This would be the seqexec events and data manager attributes (File State for example).

  • The other node contains the user-editable sequence, QA State, comments, etc. In the UI itself, steps will move from the planning area up to the log area but this need not imply that the sequence itself be modified. The UI will know which steps to show in the log because we'll have events for those and dataset filename etc. information.

• Special-case sync logic is a must.

  • Changes to the configuration of datasets that have already been executed or started will be ignored (?) in the sync. The UI of course will not present the user with the option of editing observed step configuration but the sync should enforce this anyway. For one thing, a user can edit a sequence offline and later find that it has already been executed.

  • I believe we should track a vector-clock for each dataset, but kept within the user-editable sequence node itself to keep the program version map from getting out of hand.

  • A vector-clock for the sequence as a whole is needed as well.

  • We'll need a UI for resolving sync conflicts on a dataset-by-dataset basis.

• Just as for today's obslog node, we will have to poll for updates to the server-only sequence node. Using the planned time information, we know how long each dataset is expected to take so that gives us a good clue about when we should be especially eager for an update from the server vs when we should be able to wait a bit longer.