Refactor line-specific persistence control flow
Today, the birds-eye view of the Moore control flow is:
moore (LAZY_AND, ordered)
├── lines (NONLAZY_OR, unordered)
│ ├── LineA (LAZY_AND, ordered)
│ │ └── MakeD0s
│ └── LineB (LAZY_AND, ordered)
│ └── MakeB0s
└── persistence (LAZY_AND, ordered)
├── LineSpecificAlgs
├── Cloners
└── ...
The persistence has to do stuff which depends on the CF results of the lines. For example, it moves LHCb::Particle
outputs to well-defined locations for downstream applications, and it runs PersistReco stuff if a PersistReco line fires.
I'd like to move the line-specific persistence logic in to the CF of the line itself:
moore (LAZY_AND, ordered)
├── lines (NONLAZY_OR, unordered)
│ ├── LineA (LAZY_AND, ordered)
│ │ ├── LineADecision (LAZY_AND, ordered)
│ │ │ └── MakeD0s
│ │ └── LineAPersistence
│ │ ├── MoveLineAParticles
| | └── ...
│ └── LineB (LAZY_AND, ordered)
│ ├── LineBDecision (LAZY_AND, ordered)
│ │ └── MakeB0s
│ └── LineBPersistence
│ ├── MoveLineBParticles
| └── ...
└── persistence (LAZY_AND, ordered)
├── Cloners
└── ...
The semantics of "a line" now include the persistence logic, i.e. a line is now responsible for preparing all objects it would like to be persisted. This is in contrast to how things are today, where a line effectively requests what it would like, and then the persistence logic in Moore must ensure these objects exist and in the correct places.
The actual details of all of this will be hidden behind the HltLine
API. The HLT line implementation won't change, but HltLine
will construct a more complex control flow and expose more information about what should be persisted, which will be picked up by the cloners.
This should more naturally fit in to the barrier logic available in the scheduler: the cloners will be barrier algorithms which consume the output of the line-specific persistence algorithms, which may or may not have run depending on the line decision.