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 the resulting overlay scheme needs to provide for not only overlaying event data from the Periodic Trigger events, but also properly handling the event's raw trigger data.
It is also worth pointing out that the Onboard Filter is a consumer of the trigger data as well as the event data. 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 simulated 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 trigger data from the input Periodic Trigger events. Ideally, the 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 algorithms: TriggerInfoAlg and TriggerAlg. In the new scheme, TriggerInfoAlg is responsible for calculating the raw trigger primitives from the simulated data, 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.