Overview
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 the resulting overlay scheme needs to provide for not only overlaying the PT dataevent data from the Periodic Trigger events, but also including the trigger information.properly handling the event's raw trigger data.
It is also worth pointing out Note that the Onboard Filter is a consumer of both the trigger data as well as the event data, so the above impacts it as well. For example . 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. If Then, for example, if the trigger is not properly simulated then you could 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 Onboard 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 Digissimulated event data. 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 trigger data from the input Periodic Trigger events. ThenIdeally, after the trigger information has been simulated, the overlay mechanism can merge the simulated event data with that from the Periodic Trigger.simulation should be independent of the event data merge, since there are a number of issues in the event data merge that make it difficult to do the trigger simulation before this merge (primarily related to calibrations).
This has been accomplished in a simple and straightforward manner. The original TriggerAlg has been split into two new algorithmsTo accomplish this it was necessary to split TriggerAlg into two pieces: TriggerInfoAlg and TriggerAlg. In the new scheme, TriggerInfoAlg is responsible for forming calculating the raw trigger primitives from just the simulated data, TriggerAlg then takes these primitives and simulates the trigger decision. This new scheme then allows for the inclusion of a new algorithm which reads in the raw trigger data from the Periodic Trigger event and "or"'s it onto the results of TriggerInfoAlg. In principle, the ghost tracks are now "invisible" to the trigger but are a part of the data (including being seen by the Onboard Filter). similarly to what was done before but with the ability to -not- include any merged event data from the input Periodic Trigger event, 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.
This scheme for including the trigger information was included in the overlays with GlastRelease v15r50p7 and later.