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.

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

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

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