(This page is now superseded by DMTN-055: Github | LTD)
(from a discussion between Jim Bosch and Gregory Dubois-Felsmann )
- Overview
- Task/Config context and assumptions
- Functional design / usage pattern
- Covers the concept that SuperTasks define their own data-grouping rules
- Specification of inputs and outputs
- SuperTask class interface
- Pipeline class interface
- DataID-mapping model
- Pre-flight environment (in particular, the design and behavior that's common across all the implementations)
- “Science DAG” definition
- using the DataID-mapping tool to implement
defineQuanta
- logic to produce the “Science DAG” from calls to
defineQuanta
- Quantum-execution environment (in particular, the design and behavior that's common across all the implementations)
- Notes on specific expected implementations of the Pre-flight and Quantum-execution environments
- CmdLineActivator
- DRP production
- SUIT / Firefly / Science Platform Portal Aspect use of SuperTask
- (open to adding others)
- Consequential requirements on Butler to support SuperTask (and description of how Butler is expected to be used in the SuperTask framework)
- Worked examples
- ISR
- Coaddition
Things to remember to include somewhere (may get their own section):
- Points of extensibility vs. things that are constrained by the design
- What is actually provided in the core SuperTask/Pipeline/Activator* framework, and who is responsible, vs. what is an abstraction/template to be filled in by developers of SuperTasks and platform-specific Activator code
* "Activator" here is taken to mean all the centrally-provided tooling for building the Pre-flight and Quantum-execution environments