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