On this page you find a first draft version of a "high level design" of the HLT selection software (HLTSSW). It is based on the software requirements documented in the note on Pesa Software requirements .
The selection chain shows in a simple form the basic structure of the HLTSelection. The starting point us the LVL-1Result containing PrimaryROIs and SecondaryROIs. These are used to Seed the LVL-2Selection. The similar role of the LVL-1Result plays the LVL-2DetailedResult for the EF. It is use to Seed the EFSelection. The EFDetailedResult and the LVL-2DetailedResult are part of the Event. The content of the results is structured according to the DataModel. A yet undefined zone is the EventFilterClassification, which also includes Calibration and Hotline (Discovery Stream) aspects.
The following two diagrams detail the EventDataFlow when running the selection software in the offline and in the online :
A Trigger Menu is the basis for the HLTSelection. No example Synatx of the Sequence is defined yet. It is clear though that a Sequence logically is a transformation of 1..* TriggerElements -> set of HLTAlgorithms -> 0..* TriggerElements. ToplogicalTriggerElements (like mass, Etmiss, delta_eta) are difficult and should be looked at, because they could break certain ways of writing Sequences.
The engine driving the HLTSelection is the HLTSteering. The HLTSelection is carried out in a series of TriggerSteps, which provides a natural way to perform a sequential selection. The TriggerSteps are executed by the StepHandler, which continues or terminates TriggerStep execution based on the outcome of the previous TriggerStep.
The Controller is the HLT Steering's steering mechanism.
It receives State changes from the RunControl, passes
ErrorMessages to the ErrorHandling, manages and interacts with
the StepHandler, and causes EventAccepts/Rejects. If one
imagines the HLTSteering running in an 'infinite loop' waiting
for events at the end of a FIFO, it is this EventAccept/Reject
from the Controller that should cause a new event to be
processed. This mechanism should be discussed and defined. The Controller
receives and forwards the EventAccept/Rejects from
the StepHandler.
The Step consists of a StepSequencer and a StepDecision. The StepSequencer is the entity that has the knowledge of which HLTAlgorithms actually need to be executed for a given (combinatiion of) TriggerElement(s). This knowledge is derived from a SequenceTable, which is obtained from the ConfigurationHandler at initialisation time and correponds to the Trigger Elements present in the MenuTable. The MenuTable is also obtained from the ConfigurationHandler.
The StepDecision makes a decision for the TriggerStep based on its knowledge of the MenuTable and on the ("active") TriggerElements available in the Event through the DataInterface. After a StepDecision is finished, the StepResult is sent to the DataInterface for incorporation into the LVL-2/EFDetailedResult. TriggerElements not used to satisfy any PhysicsSignature get "deactivated" and are not processed by the next StepSequencer. The StepDecision also sends an Accept/RejectStep to the StepHandler. If it is the last TriggerStep in the TiggerMenu, the StepDecision sends an Accept/RejectEvent to the StepHandler, which forwards it to the Controller.
The DataInterface handles all event data Requests, including TriggerElements. It also interfaces to DataCollection for receiving for example the LVL-1Result and for sending the LVL-2Result A possible 'active element' behind the interface is the FIFO mechanism described above. This needs to be discussed.
The first step in the HLTSelection chain is a privous EventAccept/Reject,
which triggers the next available LVL1Result to be send (all ROIs
are converted into correponding "active" TriggerElements) to the
StepSequencer (probably processed by a dummy or trivial Sequence).
A first StepDecision, based on "LVL-1" TriggerElements and
the MenuTable, is made and send to the StepHandler. The StepHandler
then continues this 'refinement loop' until all TriggerSteps are
done. The first StepDecision would be a good place to perform LVL1
Prescaling.
Finally, the Controller accepts the Event after all
TriggerSteps are completed and at least one PhyisicSignatures
survived after all StepDecisions.
To be discussed:
- In the offline, how is the RunControl+Error-Handling+Configuration
done ?
- Syntax of the Sequences ?
- "activation" sceme ?
- how to configure an Agorithm depending on the lable of the TriggerElement
?
In the HLTSSW the (top level) HLTAlgorithms are executed by the StepSequencer of the HLTSteering. The StepSequencer knows about the old TriggerElements and hence it provices them as Seeds. (NOTE: it is not the Region which is the Seed. The TriggerElement has history information in the DataModel, which includes a Relation to the ROI it is coming from.) The StepSequencer does not know about the lower levels in the DataModel, hence it does not provide Features as Seeds. Seeds for subHLTAlgorithms could also be any type of Feature. Example: A TrackFitter is to fit a ProtoTrack using the assoicated SpacePoints.
An HLTAlgorithm reports back suggess or an Error to the StepSequencer, which is to handle the ErrorConditions.
Each HLTAlgorithm is configured using ParameterSets which are provided by the Configuration(DataBase). Like for the MetaData, an Update of the ParameterSet should not happen event by event, it is more something which should be done at Start-Of-Run.
A part of the History in the DataModel is that the AlgorithmResult is related to the Seed used to compute it. This Relation is needed to allow efficient Caching of AlgorithmResults via the DataInterface. If appropiate, a HLTAlgorithm could request its AlgorithmResult , which corresponds to the Seed it was getting. Only if this fails, it would compute it.
It should be possible to request data via the DataInterface. An example is the ROBDataRequest which is discussed below. Also a direct access of to Features already computed by other HLTAlgorithms is an option.
The HLTAlgorithms use MetaDataInterfaces and MonitoringInterfaces to access the corresponding Services.
To be discussed:
- the seeding itself, is it done via argument ?
- Is the AlgorithmResult of the first Algorithm in a sequence the seed
of the next algorithm (only the trigger elements from the result?)
-What is a region ? What is a road ?
There are three Types of Data in the EventDataModel: the RawData, the Features and the TriggerElements. There is another Type, namely the SimulationTruth, which is not shown in the diagram. Naming conventions are:
The concept of Region is supported by the EventDataModel in that all DataEntities could be located in a Region. Especially also the LVL-1ROI.
The Entities of the FeatureDataModel serve as natural IO-Interfaces for any FEXAlgorithm. The arrows are Associations. Note that each Level of the FeatureDataModel only talks to the next Level avoiding complex Relations. Associations should be external to the DataObjects. The notion of Exclusions is introduced to flag and later resolve ambiguous Assoications leading to ambiguous Features.
In the EventDataModel one could have "active" and "deactive" entities. Example: If you run a Sequence and refine a TriggerElement, you "deactivate" the old one and lift a new "active" one. The list of "active" TriggerElements is the one to work on (Test w.r.t. the TriggerMenu).
To be discussed:
- the Region and ROI relations to TriggerElements and Features ?
-What is a Region ?
It should support the EventDataModel, especially the History aspects of it. This means it is not a simple interface to store object containers, but the DataAccess works more in the form of "Database requests" using keys like "track", "clusters", or "hits used in this track", "Feature used for this Trigger Element". This implies that the DataInterface request the information about the "Feature used for a new Trigger Element" before accepting to store a Trigger Element.
The DataInterface hides details of the DataCollection and Store from the HLTAlgorithms. Here are a few use case diagrams how that might work:
When running online it also is the interface for the LVL-1Result and for the sending the LVL-2Decision and LVL-2DetailedResult.
... details to be added...
To be discussed:
- the online and offline implementation differences (Example: detailed
benchmarking of HLTAlgorithms in the offline)
.. details to be added...
This is our Photo gallery:
Layer Diagram
Offline Data Flow
Selection Chain
Trigger Menu I
II III
IV
System Overview
more to come here soon !!!
