rootana_eventNavigator_design

Event Navigator Design Document

This details design decisions and rationale for the EventNavigator and related classes. It is (currently) a living document, and is not aimed at users. Entry level documentation will hopefully be written once the classes are ready for consumption. The document is subdivided into topics, and the existence of a topic relates more to whether I needed to gather my thoughts than importance or activity.

---

1. Selection of data banks

1.1 Concepts

Data Bank: a container with several individual data items recorded. The typical case is a list of hits (pulses) on a particular channel, but it may apply to broader-scope objects (e.g. TMuonEvent). There are typically many data banks in each event.

Selection: a specification of some number of data banks that a user intends to perform some analysis on, using an algorithm (e.g. Ben's generators), which are typically run by modules.

Result: here, a collection of (handles to) data banks that meet the selection criteria.

1.2 Use cases

Unless noted, it is assumed that the user will wish to perform the same query for each event in the tree.

1. The user has an algorithm they wish to run on a particular class of data banks (e.g. all "slow" banks). They specify the selection, then request a result matching the selection.
2. The user has an algorithm that works generically on all data banks of a given type, and wish to apply it to every available bank of that type. The want a result holding everything in the event.
3. The user wants to recover one specific bank. It is a single object, so a result object is not necessary

1.3 Desiderata and assumptions

• Selections should be creatable by the user, with individual elements and wildcards specified through the Source ID mechanism.
• Selections should also be modifiable by the user
• A selection should somehow be convertible into results
• Users can provide wildcard selections, and they normally anticipate they will match match at least one bank.
  • It is not knowable what banks are available until the tree is examined. So the returned result will not have a predictable size, at least until the selection has been attempted once. Therefore:
    • The result must be able to signal that it has been exhausted.
    • A specific relationship or order between the elements of the result cannot be guaranteed. If ordered selections are allowed they will sometimes fail.
• Several modules will run on each event. Some modules may wish to operate on the output of the previous module.
• By far the most common use case is to make the same selections on each event in turn. Thus converting a selection into a result must be repeatable, and ideally quick.