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.
Note It is also worth pointing out 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 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. Then, after After the trigger information has been simulated, the overlay mechanism can merge the simulated event data with that from the Periodic Trigger.
To accomplish this it was necessary to split TriggerAlg into two piecesThis 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 forming calculating the raw trigger primitives from just the simulated data, in the manner that was done before, 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 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 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)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.