In the NCD phase we have two data sources that come from two essentially separate DAQ systems. There can therefore be a time delay in a run between the initialization of the two systems. The run boundary cut solves this problem by tagging events from periods of time before both systems are known to be running, or after one system may have stopped.
The start of the run is identified by a point in time, not an event as has been done previously. This point in time is identified by a time later than a given event. The time period is specified in the titles file and should not be a multiple of 0.2s to avoid locking with PGT events. We use 1.1s as the default. The chosen event is the later of the first PGT event (signifying that the PMT system is running) and the first event containing NCD data. Typically the NCD event will be the later event. The event is not directly used to remove the uncertainty due to the time between the initialization of the system and the first event occurring.
The end of the run is also tagged in a similar way, looking backwards instead of forwards, with one additional complication. As the RAA cannot go backwards before the start of the current subrun the code must be told how many subruns to expect. This is done in the titles bank. If the end of the run cannot be identified in this subrun (there are many examples where the last subrun is all orphans) then the entire subrun is tagged, but the point in time that specifies the end of the run is not tagged. This may be a temporary measure, as there is the hope for the NCD system to send out and end of run record which may be found. This is however not yet implemented.
The start of run is only searched for during the first subrun. If data
of both types is not found, the cut will not tag any events. This
means there is no explicit shutdown of this cut on D
O or salt
data, but as no NCD event will be found, this cut does not do anything
to this data.