Skip to content

Sequence Model Notes

Jump to bottom
Shane Walker edited this page Dec 3, 2015 · 1 revision

Current Status

An initial version of the new Sequence Model is now available for review. It meets the following goals:

  • Stores the sequence in an unrolled, or pre-calculated state for efficient examination and flexible editing.

  • Provides distinct sequence step types with attributes appropriate for the particular step. There are step types for bias, dark, manual gcal, science and "smart" calibrations.

  • Allows generic access to collections of properties that describe the steps via typeclass implementations.

  • Represents the sequence compactly for efficient storage and transmission.

  • Replaces static instrument components and all iterators. Provides a drastically simplified Flamingos2 prototype as an example.

One potential flaw with the model as it stands is that it does not account for non-sequenceable properties. For example, it makes no sense to iterate over the Flamingos 2 "pre-imaging" flag and yet it is possible in this model. Though it adds complexity, it might be worth considering whether to separate truly static values like the pre-imaging flag from sequenceable values like filters.

In addition to the initial model ideas, some rudimentary progress has been made on the sequence table UI.

Remaining Work: Initial Release

  1. User interface. The user interface is likely the most challenging aspect remaining. We believe that the ideas in the Sequence Model Goals document can be rolled out over time though. Initially the focus will be on sequence planning, leaving the currently executing step and the observing log as is for now.

  2. Algorithm for conflict resolution. In the new model, the entire sequence (plus static instrument component and obs log) are contained in a single science program node. This information is scattered over various nodes in the existing program model. Because the granularity of conflicts is the science program node, placing so much information in a single node obligates custom conflict resolution.

    The plan is to make use of existing sequence comparison algorithms to identify what edits would be necessary to unify two versions of the sequence. Where steps differ, the user interface should present a side-by-side comparison highlighting differing values.

  3. Instrument Representation. The "static" instrument component in today's model disappears in favor of individual sequence steps. There will be an instrument case class per instrument. An open question is exactly how to handle instrument properties.

    • Do we keep all the individual parameter types (the enums in current model) or replace them with sealed traits, etc.?

    • Should we use the opportunity to try to unify the P1 and P2 representation of filters, etc.

    Other than holding a collection of properties, there are a few APIs that the instrument data objects implement that will need to be carried over in some form:

    • Planned time calculations.
    • AGS information (guide probe “provider”, vignetting areas).
    • Defines queryable parameters for the observation browser.
    • Rule enforcement — property Foo limits property Bar, setting Foo updates Bar, etc.

  4. Execution Log. The current model stores executed step information in a text record that isn't useful for anything but display. With the new sequence model, we will have an exact typed, immutable representation past steps. We'll need to store the execution log (in the sequence node?) and remove the existing text-based log.

  5. XML Externalization.

  6. Migration. Migration will be a bit more difficult than normal. It requires calculating the sequence from nested loops as we do in today's model and converting to the new sequence model. It is an unfortunate fact that some of the existing awkward sequence model code must be maintained for this purpose.

    Also, it isn't clear what to do about existing observations that are executed or partially executed since we have no real, fixed record of what happened. Smart-gcal related sequence bugs make this even more difficult. Can we simply delete the text-record execution log?

  7. Smart GCal. Smart Gcal must be updated to work with the new sequence model. The idea is that a smart step will be expanded when queued for execution and dissolve into normal calibration steps once executed.

  8. P2 Checking. Most P2 checks work with an unrolled sequence. The migration to the new sequence model is expected to be trivial but there are several rules that need to be updated. We now have the possibility to identify individual steps with P2 problems rather than vaguely associating problems with the root sequence node. We should take advantage of this to improve the UI.

  9. Planned Time Calculation. Planned time calculation works with an unrolled sequence, which lends itself to a straightforward migration to the new model.

  10. ITC. Unknown impact, presumably manageable.

  11. Seqexec. Unknown impact, presumably reasonable. All property values will be typed so conversion from String and downcasting will not required. If we still need to produce sequence XML for the old Seqexec though, there will be additional work here.

  12. Potpourri. A few additional areas requiring migration:

    • Calculating ObsClass.
    • Calculating ObservationStatus (PHASE II, READY, EXECUTED, etc.).
    • Lots of places where we check what the instrument type is, for example in LibraryAction.

Priorities

The new sequence model coexists for the moment with the existing sequence model. It is too large to replace all at once so we should continue to support both models in the codebase initially, at least until a minimal prototype is working.

The highest priority is completing the prototype editor for sequence planning in the new model. It must support a table view of sequences and import/export via XML. This will make it easier to communicate ideas and facilitate ongoing development.

With multiple developers, we could make progress on the other items in parallel. In particular decisions about the instrument representation and conversion of existing instruments should be tackled early. Next, conflict resolution and migration seem like the highest priority items.

Remaining Work: Future Releases

The Sequence Model Goals document details the ultimate vision for the new model. All the items in the previous section must be addressed before we can deliver anything to end-users, but advanced stages of the Sequence Model update can be delivered in the nebulous future.

  1. Combination Obs Log / Sequence Node UI.
  2. Multiple Sequences Per Observation.
  3. Sequence Execution Controls.
Clone this wiki locally