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