Central Trigger Overview

 The CentralTriggerSimulatorXb simulates the central trigger used in CDAS. The central trigger is done in two major steps: First a search for T2 clusters and then the stations are requested to send the traces they have within a time window. This module is thus split in two functions: FindT2Clusters and BuildEvent respectively. The two functions could, in principle, be split in two modules: CentralTriggerSimulatorXb and CentralTriggerEventBuilder. The rationale for splitting the procedure in two modules would be that:

1. CentralTriggerSimulatorXb doesn't need to know anything about FD
2. CentralTriggerSimulatorXb can (potentially) return more than one T3, meaning that for each time CentralTriggerSimulatorXb is run, CentralTriggerEventBuilder might have to run more than once.

 In order to do this, the event interface needs to be changed, to add a list of T3 that can be accessed from both modules. The way it is implemented right now is within one module and the list of T3 is stored privately within the module.

FindT2Clusters

 FindT2Clusters is where the central trigger, properly speaking, is simulated.
 The CentralTriggerSimulatorXb module assumes that for each LS trigger there will be an sevt::StationGPSData and an sevt::StationTriggerData stored inside sevt::StationSimData, indexed by the time stamp of local trigger. The results of this module are stored as CentralTriggerSimulatorXb::T3 objects.

 CentralTriggerSimulatorXb uses the set of classes that are used in CDAS to find T2 clusters. The only thing the module does is to collect all local T2 information from the event interface, pass them to these classes and use the result to create the T3 objects. This is done by grouping all T2s that belong in the same second and passing them to the Xb classes sequencially. 

 The Xb classes provide the list of stations from which we should request data, along with time window and offset. This is also included in the corresponding T3.

BuildEvent

BuildEvent is where the process of requesting data from the stations is simulated. First we check if there were FD or SD T3s. It compiles a list of TimeStamps, one for each FD and SD T3 and decides the time of the event. This time will then be used as the reference. Based on the reference time stamp, we will then check which stations have T2 triggers falling in a time window around the corresponding station time (event time +- offset). It will then take the earliest local trigger within that window and set the error code for these stations to eNoError. All stations that are checked for data but have no trigger within the time window ar set as IsPartOfCentralTrigger and its error code is set to eT3NotFound. Finally, all the trigger/trace information from StationSimData and PMTSimData to Station and PMT respectively.

This algorithm can potentially deal with a sequence of triggers, iterating over all the triggers in consecutive calls. It can also check if there are consecutive SD T3s that need to be merged into one T3 although that is not done at the moment. e.g: In this function one can check if the trigger is complete or if there is another T3 at the beginning of the following second that includes all the local triggers.

Requirements

This module assumes that there are local triggers with traces:

• StationSimData::HasTriggerData(utl::TimeStamp)
• StationSimData::HasGPSData(utl::TimeStamp)
• PMTSimData::HasFADCTrace(utl::TimeStamp)

It will set:

• sevt::EventTrigger methods: SetId, SetSender, SetAlgorithm, SetTime, SetPreviousId, SetSDPAngle, SetNumberOfErrorZeroStations, SetNumberOfStations
• StationData::HasTriggerData
• StationData::HasGPSData
• PMTData::HasFADCTrace

The central trigger algorithm in CDAS

 Since the trigger algorithm of the Pierre Auger observatory is not documented in detail in any conspicuous place, we include here our understanding at the moment. Maybe some people will not like that we want to let our oral traditions die. Nevertheless, writing down these simple ideas might prove useful and save some work in the future. Also it is important to make sure we are doing (or claim to do!) the right thing.

The local stations (LS) are constantly taking data. Whenever there is a T2 in a station, the station sends CDAS the station ID, the time at which the trigger happened and the triggering algorithm. At CDAS, the T2s from all stations are received and sorted according to the GPS second of the local trigger time. The system can handle up to six batches of local triggers at a time so, after six seconds, the list of T2s is passed to the central trigger to try to find a cluster in time that also fulfills the T3 compacity criterion. If there is such a cluster, the central trigger sets the reference time for the trigger equal to the earliest local trigger in the cluster. It also provides a list of stations which are asked to send traces acquired within a time window centered at the reference time. In the case of the stations that are in the T2 cluster, they are requested to send the traces that were recorded at that time so, for these stations, the window size is zero and the window is not centered at the reference time but centered at the time when the T2 occured.

Meanwhile, the station has been storing the traces and keeping them for some time (on the order of 15 seconds). Upon receiving the request from CDAS, the local station sends back the earliest trace within the specified time window, if it finds any. It will also send back to CDAS a code that summarizes the result:

• eT3Lost: The oldest stored trace is from a time later than the requested time.
• eT3NotFound: The most common code. Stations that simply didn't have anything.
• eT3TooYoung: This is in case the request happens in the future (the latest stored trace is from a time before the request?)
• eT3Already: When a request is made twice for the same interval of time, the second time it returns this (how is this done in the LS?)
• eT1Stopped:
• eBadCompress:
• eDataLost: this is set by CDAS, meaning that the station had a trigger but it was never received.

 The central trigger keeps the triggers from the previous second just in case an event is split by the second boundary, in which case there might be two triggers, one at the end of the first second and another at the beggining of the last. In any case, if there is any trigger at all there will be a trigger at the beginning of the last second.