You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Recall that the motivation for doing the overlays in the first place is a result of the differing windows for latching trigger data as opposed to event data, and we need to be sure to provide a mechanism for not only overlaying the PT data, but also including the trigger information.

It is also worth pointing out that the Onboard Filter is a consumer of the trigger data as well as the event data, so the above impacts it as well. In particular, the Gamma Filter checks the status of the trigger word before it begins its processing, requiring that one of the trigger primitives be set. Then, for example, if the trigger is not properly simulated then it's possible to imagine a generated event that missed the LAT, with a ghost track that resulted in a trigger and might pass the Gamma Filter - when it shouldn't.

Before overlays, the trigger data was simulated differently per system, but in all cases based on the same hits that ultimately appeared in the Digis. To handle the overlays a scheme needs to be developed which calculates the raw trigger information from the simulated data only, as has been done in the past, and then "or"'s these trigger primitives with those from the input Periodic Trigger events. After the trigger information has been simulated, the overlay mechanism can merge the simulated event data with that from the Periodic Trigger.

This has been accomplished in a simple and straightforward manner. The original TriggerAlg has been split into two new algorithms: TriggerInfoAlg and TriggerAlg. In the new scheme, TriggerInfoAlg is responsible for calculating the raw trigger primitives from the simulated data, in the manner that was done before, and storing this information in the Transient Data Store. TriggerAlg now retrieves these trigger primitives from the TDS and uses the information to evaluate the trigger. When Gleam runs in "Overlay" mode, an intermediate algorithm runs which recovers the raw trigger primitives from the input Periodic Trigger event and then "or"'s this information with that stored in the TDS by TriggerInfoAlg. This allows a scheme where the trigger information is completely indpenpendent of the input Periodic Trigger event data.

  • No labels