Project

General

Profile

How to use the GlobalTrigger: complete trigger list

User documentation
08/08/2011

Date last updated is 7/16/18, the redmine generated date above is the date this page was created!

While most users will simply interface with GT through the run control interface, those who wish to make it do different things will need to know how it works and how it is configured to do different things. This documentation is for the NovaGlobalTrigger package in the online software repository.

What is the GlobalTrigger?

The Nova GlobalTrigger ("GT") is the program which issues trigger messages to the rest of the DAQ. A brief reminder of how the Nova data flow goes. Data in Nova flows from the front end electronics to Data Concentrator Modules ("DCM"s). The DCMs timestamp and aggregate their data stream, shipping it off to the Buffer Nodes ("BN"s). The BNs form a circular buffer, with the oldest data slices being overwritten by the newest. As a result, the default fate of any given bit of Nova data is to fall on the floor and not be recorded.

That being a lousy way to run an experiment, data at interesting times must be saved. To do this, a Trigger message is sent by the GT process to the BNs and the Data Logger. When a trigger message is received, BN searches in its memory for any data slices whose timestamps fall in the trigger window. They send those data off to the Data Logger, which builds an event around that trigger message out of all the bits of data it receives then writes it out.

What sorts of triggers are there?

The trigger masks are defined in TriggerDefines.h in the DAQDataFormats package. For the end user of the data, please see the documentation for that package, which describes the format of the data headers, and has methods for extracting information from those headers to use in your analysis. When issuing a trigger message, GT creates a unique trigger number, and sends a message with the appropriate time and width (see "Configuration", below) to those processes subscribed to TRIGGER_MAILBOX (defined in NovaGlobalTrigger/Gt.h). The TRIGBIT_ID defines are the bitmasks, the TRIG_ID defines are a simple integer count which is used to index arrays of things in the GT, and to pass trigger type requests from other programs. The different types of triggers are:
  • TRIG_BIT_BEAM_NUMI =0x01
  • TRIG_ID_BEAM_NUMI = 1
    • This NuMI trigger is issued when the SpillServer (see that package for details) sees the ACNET signal for a NuMI beam spill, latches that time from the GPS clock, and sends a message to processes subscribing to the DAQ's NULL partition in the "SpillServerMailbox" RMS mailbox.
  • TRIG_BIT_BEAM_BOONE =0x02
  • TRIG_ID_BEAM_BOONE = 2
    • This BNB trigger is issued when the SpillServer (see that package for details) sees the ACNET signal for a BNB beam spill, latches that time from the GPS clock, and sends a message to processes subscribing to the DAQ's NULL partition in the "SpillServerMailbox" RMS mailbox.
  • TRIG_BIT_SOFT_CAL_PER =0x04
  • TRIG_ID_SOFT_CAL_PER = 3
    • This trigger is issued by the GT alone. It is configured with a periodic rate, so will produce triggers at (to the detector) arbitrary times, saving data which is a snapshot of the detector at that instant. Useful for minimum bias triggers, as well as cosmics -- given the huge rate of cosmic ray muons in surface detectors, any given "Calibration" trigger is likely to have a muon in it.
  • TRIG_BIT_SOFT_CAL_RND =0x08
  • TRIG_ID_SOFT_CAL_RND = 4
    • Just like the periodic calibration trigger above, but rather than being periodic, the configured rate is used to produce a Poissonian trigger time distribution with a mean rate matching the configured rate. Useful if you are worried about rate aliasing issues.
  • TRIG_BIT_SOFT_MANUAL =0x10
  • TRIG_ID_SOFT_MANUAL = 5
    • A manually issued trigger. Historically, a one-shot as configured for some time. Best used now by setting the "remote" config flag to "true" in the xml, then you can use a program like ManSender (in the NGT test bin area) to send triggers whenever you want at whatever length you want, to tickle the system when you're debugging or commissioning. A long standing goal is to have a Big Red Button GUI for this on the Run Control screens.
  • TRIG_BIT_BEAM_1PPS =0x20
  • TRIG_ID_BEAM_1PPS = 6
    • Something passed along through the SpillServer conduit just like a real trigger from NuMI or BnB, but started by the accelerator's 1Hz clock. This is used as a heartbeat.
  • TRIG_BIT_STREAM_PER =0x40
  • TRIG_ID_STREAM_PER = 7
    • Pretty much just a second instance of the CAL_PER above, but intended to be a low-rate, longer duration trigger for gathering long chunks of min-bias data, which we call "streamer" data.
  • TRIG_BIT_STREAM_RND =0x80
  • TRIG_ID_STREAM_RND = 8
    • If you configure the Streamer data to be random instead of periodic, it gets this bit.
  • TRIG_BIT_SOFT_DAQ_STATUS =0x100
  • TRIG_ID_SOFT_DAQ_STATUS = 9
    • This is a trigger which doesn't read out detector data, but which the buffer nodes use to fill a DAQ status block.
  • TRIG_BIT_DATA_SN =0x001000
  • TRIG_ID_DATA_SN = 13
    • A Data Driven Trigger for Supernovae. DDTs are what you think of when you think of a HEP experiment's trigger. That is, the data is examined quickly for interesting patterns so they can be saved. In Nova, this will involve the Buffer Nodes inspecting the data as they buffer it, communicating with a GlobalTrigger process which referees all the different buffer node inputs to decide if something interesting is happening overall. Examples include triggering on a rash of small interactions which look like a supernova, or very horizontal muon tracks which could be induced by atmospheric neutrinos.
  • TRIG_BIT_DATA_ENERGY =0x002000
  • TRIG_ID_DATA_ENERGY = 14
    • A DDT for selecting high energy events. This wiki should link to info in the DDT group's wiki describing these trigs as documentation becomes available.
  • TRIG_BIT_DATA_CALMU =0x004000
  • TRIG_ID_DATA_CALMU = 15
    • A DDT for selecting muons for calibration. This wiki should link to info in the DDT group's wiki describing these trigs as documentation becomes available.
  • TRIG_BIT_DATA_UPMU =0x008000
  • TRIG_ID_DATA_UPMU = 16
    • A DDT for selecting upward-going muons. This wiki should link to info in the DDT group's wiki describing these trigs as documentation becomes available.
  • TRIG_BIT_DATA_NUMU =0x010000
  • TRIG_ID_DATA_NUMU = 17
    • A DDT for selecting contained muon track vertices. This wiki should link to info in the DDT group's wiki describing these trigs as documentation becomes available.
  • TRIG_BIT_DATA_NUE =0x020000
  • TRIG_ID_DATA_NUE = 18
    • A DDT for selecting contained electron shower vertices. This wiki should link to info in the DDT group's wiki describing these trigs as documentation becomes available.
  • TRIG_BIT_DATA_FASTMONO =0x040000
  • TRIG_ID_DATA_FASTMONO = 19
    • A DDT for Fast Monopoles. This wiki should link to info in the DDT group's wiki describing these trigs as documentation becomes available.
  • TRIG_BIT_DATA_SLOWMONO =0x080000
  • TRIG_ID_DATA_SLOWMONO = 20
    • A DDT for Slow Monopoles. This wiki should link to info in the DDT group's wiki describing these trigs as documentation becomes available.
  • TRIG_BIT_DATA_FEBOVERFLOW =0x100000
  • TRIG_ID_DATA_FEBOVERFLOW = 21
    • A "DDT" for FEB Overflow errors.
  • TRIG_BIT_DATA_ACTIVITY_1 =0x200000
  • TRIG_ID_DATA_ACTIVITY_1 = 22
    • A "DDT" for an NDOS activity trigger.
  • TRIG_BIT_DATA_ACTIVITY_2 =0x400000
  • TRIG_ID_DATA_ACTIVITY_2 = 23
    • Another "DDT" for an NDOS activity trigger.
  • TRIG_BIT_SOFT_MONTECARLO =0x800000
  • TRIG_ID_SOFT_MONTECARLO = 24
    • A Simulation Trigger. GT can be configured to pass along wholly formed triggers from the DAQ simulation manager, for internal testing. The trigger types are whatever simulation manager has come up with - GT is simply the conduit so the whole DAQ system can be simulated.
  • TRIG_BIT_SNEWS_TRIGGER =0x00000001
  • TRIG_ID_SNEWS_TRIGGER = 25
    • A supernova trigger sent by the SNEWS system. Note that this is the first trigger bit outside the lower order trigger word's 24 bits. This extends into the next (the "mid") 32 bits of trigger mask space. Best to use the tools in the RawTriggerMask class to deal with these.
  • TRIG_BIT_SNEWS_BEAT_SLOW =0x00000002
  • TRIG_ID_SNEWS_BEAT_SLOW = 26
    • A "slow" heartbeat trigger sent by the SNEWS system. This might be once a day or week or something, and request a largish length of data, to exercise the system and produce a large minimum bias trigger dataset for other, not-SN purposes.
  • TRIG_BIT_SNEWS_BEAT_FAST =0x00000004
  • TRIG_ID_SNEWS_BEAT_FAST = 27
    • A "fast" heartbeat trigger sent by the SNEWS system. This might be once a minute and request very little data, as a test of the system and a measure of live time.
  • TRIG_BIT_DATA_CONTAINED =0x00000008
  • TRIG_ID_DATA_CONTAINED = 28
    • A contained vertex data driven neutrino trigger.
  • TRIG_BIT_DATA_MOON =0x00000010
  • TRIG_ID_DATA_MOON = 29
    • A trigger on a track coming from near the moon.
  • TRIG_BIT_DATA_SUN =0x00000020
  • TRIG_ID_DATA_SUN = 30
    • A trigger on a track coming from near the sun.
  • TRIG_BIT_DATA_MICHEL =0x00000040
  • TRIG_ID_DATA_MICHEL = 31
    • A trigger on a Michel electron
  • TRIG_BIT_DATA_SNXTRIG =0x00000080
  • TRIG_ID_DATA_SNXTRIG = 32
    • A supernova trigger issued bt the other (near or far) detector. Handled by the SNEWS message transport infrastructure.
  • TRIG_BIT_DATA_MICHEL_VAR2 =0x00000100
  • TRIG_ID_DATA_MICHEL_VAR2 = 33
    • in case there is ever a second version of the Michel trigger
  • TRIG_BIT_DATA_MICHEL_VAR3 =0x00000200
  • TRIG_ID_DATA_MICHEL_VAR3 = 34
    • in case there is ever a third version of the Michel trigger
  • TRIG_BIT_DATA_MICHEL_VAR4 =0x00000400
  • TRIG_ID_DATA_MICHEL_VAR4 = 35
    • in case there is ever a fourth version of the Michel trigger
  • TRIG_BIT_DATA_MICHEL_TEST =0x00000800
  • TRIG_ID_DATA_MICHEL_TEST = 36
    • ... or a test version, in case things get insanely complicated
  • TRIG_BIT_DATA_FASTMONO_NN =0x00001000
  • TRIG_ID_DATA_FASTMONONN = 37
    • The new, Neural-Net driven fast monopole trigger
  • TRIG_BIT_DATA_FASTMONO_NN_VAR2 =0x00002000
  • TRIG_ID_DATA_FASTMONONN_VAR2 = 38
    • in case there is ever a second version of the NN fast monopole trigger
  • TRIG_BIT_DATA_FASTMONO_NN_VAR3 =0x00004000
  • TRIG_ID_DATA_FASTMONONN_VAR3 = 39
    • ... or a third
  • TRIG_BIT_DATA_FASTMONO_NN_TEST =0x00008000
  • TRIG_ID_DATA_FASTMONONN_TEST = 40
    • ... or a need for a test trigger
  • TRIG_BIT_LIGO_TRIGGER =0x00010000
  • TRIG_ID_LIGO_TRIGGER = 41,
    • A remotely issued trigger from LIGO
  • TRIG_BIT_LIGO_BEAT_SLOW =0x00020000
  • TRIG_ID_LIGO_BEAT_SLOW = 42
    • A test trigger from ligo, issued more rarely (once per day?), with a long readout
  • TRIG_BIT_LIGO_BEAT_FAST =0x00040000
  • TRIG_ID_LIGO_BEAT_FAST = 43,
    • A test trigger from ligo, issued more rapidly (once per minute?), with a short readout
  • TRIG_BIT_TESTBEAM_SPILL =0x00080000
  • TRIG_ID_TESTBEAM_SPILL = 44
    • A trigger from ACNET on the start of the test beam slow extraction, to cover the whole spill
  • TRIG_BIT_TESTBEAM_TRIGGERED =0x00100000
  • TRIG_ID_TESTBEAM_TRIGGERED = 45
    • A trigger from the testbeam beam hardware, to trigger when it sees a particle headed to the detector
  • TRIG_BIT_DATA_NNBAR =0x00200000
  • TRIG_ID_DATA_NNBAR = 46
  • A data-driven trigger to look for neutron/anti-neutron oscillations, a proton-decay like signal
  • TRIG_BIT_DATA_H_MU =0x00400000
  • TRIG_ID_DATA_H_MU = 47
    • A data-driven trigger to capture long horizontal muons, for calibration purposes

Which processes do what?

The general GT architecture is explained here, and a detailed list of its response to state changes is here

NOTE - NGTMaster is obsolete in the current DAQ partition model, where Application Manager rules all. NGTMaster is not used.

A user-level summary: When Run Control ("RC") gets to the "Run Configured" step, one of the processes it starts is NovaGlobalTrigger, on the novadaq-ctrl-trigger machine of the DAQ cluster. It starts this process pointing at the xml appropriate partition and configuration xml file extracted from the Config Manager database. The NovaGlobalTrigger process uses the configured file on startup and listens on the established partition.

Each partition which is ready to enter a running state has a NovaGlobalTrigger process running. That process will respond to RC requests to start, pause, rollover, and end a run. Trigger configuration cannot be changed within a run - if a different GT configuration is requested to be loaded on a partition, any existing NovaGlobalTrigger will be killed and a new one started with the new configuration. While running, NovaGlobalTrigger has a different running thread for each type of trigger it is handling, as well as another thread which watches for RC commands.

Configuration

GT configuration is done via xml files. Each ready-to-run partition has a GT instance which has been passed the location of its configuration file via a RC command. If no configuration file is passed to the NovaGlobalTrigger program via the "-c <filename>" or "--config <filename>" command line parameter, it looks in your SRT context for this default file: srt://NovaGlobalTrigger/config/GTConfig.xml
The CVS version of this file also serves as an example config file that lists all the different parameters one might want to play with. Here is what those parameters are:
  • <Partition part="0"/>
    • What partition number is this instance of NovaGlobalTrigger running on? The command line parameter "-p <number>" or "--partition <number>" overrides the config file value, and is how NGTMaster sets the partition number of the NovaGlobalTrigger instance it starts.
  • <Log logLevel="3"/>
    • The logLevel parameter has been co-opted to use as a trigger log message prescale factor. So, in this case, every trigger message of a given type will send a log message only once every three times. This is a kludge, a properly written MessageService configuration file should do something similar in a more standard fashion, however, this feature was requested of GT so here it is. Note that a .fhcl message service config file is also available to control this: the author of this wiki is unsure of how that works, but it's in the DAQ setup somewhere.
  • <MilliSliceSize msSize="10000"/>
    • How large is a millislice, in 500ns ticks? (this default thus corresponds to 5ms). GT needs to know this parameter so it can deal with very long trigger windows.
  • <Offset offsetEnable="false" tv_year="2009" tv_mo="12" tv_day="31" tv_hour="23" tv_min="59" tv_sec="47" tv_usec="75260"/>
    • If enabled, triggers will be delayed by the configured time (expressed in unix timeval form, good to microseconds). Mostly used for debugging purposes, you probably never want to enable this. Few trigger threads support this anymore: if you want it, contact Alec or Adam to get it implemented.
  • <Queue depth="-1" issuewait="100" timeout="1000" holdoff="50000" debug="false"/>
    • Configure the output trigger issuing queue. Depth of -1 is no size limit. Can't change that (this parameter is here for future expansion only). issuewait is how many microseconds the queue waits before spitting out the next trigger to the RMS trigger mailbox. timeout is a parameter used to govern how many retries the sending algorithm gets (ask Andrew!). debug turns on/off debugging messages. holdoff is the number of microseconds to wait between elements of a long trigger.
  • <Throttle depth="100" maxrate="200.0" sanestats="true"/>
    • Configure an overall global trigger throttle rate. The depth is the number of entries in the rolling average buffer. maxrate is the largest rate in Hz allowed before triggers are dropped to keep the rate of issued triggers below this value. Hooks are here, but currently not implemented to ensure we get the priorities right: never want to drop beam spill triggers, for instance. "sanestats" controls the way the rate calculation is done, and governs the behavior of all the trigger throttles, not just this global one. If this is true, then no throttling will occur till the buffer depth is full, to prevent small statistics from jumping on you and introducing unwanted throttling.
  • <SNEWSPipe port="7900" host="localhost"/>
    • Where is the NOvA SNEWS spillserver xmlrpc backbone listening? This default value is suitable for testing. On the detector, set it to 7910 and novadaq-near-gateway-01.fnal.gov That's not the default, so that people testing don't start triggering the real detectors by accident.
  • <DDTThrottle depth="100" maxrate="200.0"/>
    • Configure an overall DDT trigger throttle rate. The depth is the number of entries in the rolling average buffer. maxrate is the maximum total rate of DDT triggers allowed (counting all different sorts). Each trigger has its own individual "depth" and "maxrate" pair as well, see below.
  • <Triggers>
    • a subset listing all the different trigger configurations, closed by a <\Triggers> string. Each type of trigger has its own sub-subset, started with (for example) <CalibrationSet> and ended by \<CalibrationSet>. In practice, one line is all that's used so those lines will be described individually next. Note that Calibration and Streamer trigger definitions both live under CalibrationSet
    • Note that all trigger configurations have some parameters, which can be set on a per-trigger basis, but which do the same thing, so I will describe them here:
      • enableFlag="true"
        • Is this trigger enabled ("true") or not ("false")?
      • length="100"
        • The length of the trigger window for that trigger, in 500ns ticks (so in this example, that's 50us). That is how long a block of data will be saved for that trigger. Note that DDT and Manual triggers do not use this config parameter, the length for those triggers is passed in by the program requesting the trigger.
      • prescale="1"
        • That trigger's prescale factor. If "1", every trigger will actually happen. If "2", every other, if "3", every third one, etc.
      • name="DefaultCal"
        • A name for this trigger - handy to hook into the config database, so you can store something like "Kurt and Peter's Most Excellent Trigger". This name gets spit to the message logger when it is enabled, so you can verify which named trigger was used in a run. In the case of DDTs, this name is more important, it points into the code and actually selects the trigger you're using, so don't change this name for DDTs!
      • depth="100"
        • The depth of that trigger's own throttling queue. Note that currently only the DDTs and the Manual trigger have throttling implemented.
      • maxrate="50.0"
        • The maximum rate in Hz before this trigger is throttled. Note that currently only the DDTs and the Manual trigger have throttling implemented.
      • random="false"
        • If "false", periodic triggers will be issued, if true, triggers distributed randomly according to a Poisson distribution.
      • rate="1.0"
        • Either the periodic rate in Hz, or the mean rate (also in Hz) of the Poisson distribution.
  • <Calibration enableFlag="true" random="false" rate="1.0" length="100" prescale="1" name="DefaultCal" depth="100" maxrate="50.0"/>
    • An example line for configuring the Calibration trigger.
  • <Streamer enableFlag="true" random="false" rate="0.01666667" length="10000" prescale="1" name="DefaultCal" depth="100" maxrate="50.0"/>
    • An example line for configuring the Streamer trigger. This one is set up to be periodic not random, once per minute, and 5ms long.
  • <Manual enableFlag="false" tv_year="2010" tv_mo="05" tv_day="24" tv_hour="13" tv_min="38" tv_sec="59" tv_usec="123" length="10" prescale="1" remote="false"/>
    • An example line for configuring the Manual trigger for a one-shot debugging use. This is a one-shot, so didn't implement rate throttling in this mode.
      • in unix timeval notation, at what time will a single manual trigger be issued?
  • <Manual enableFlag="false" prescale="1" remote="true" name="DefaultManual" depth="100" maxrate="50.0"/>
    • An example line for configuring the Manual trigger for using a program like ManSender to request manual triggers on the fly
  • <DaqStatus enableFlag="true" length="2000000" rate="1.0" prescale="1" name="DaqStatusBlock" depth="100" maxrate="10.0"/>
    • An example line for configuring the DaqStatusBlock trigger, to request status blocs at a rate of 1 Hz. Note that the length should correspond to all the time since the last such trigger: in this case a whole second of 500ns ticks.
  • <NumiSpill enableFlag="false" length="10" prescale="1" delay="0" name="DefaultNuMI" depth="100" maxrate="50.0"/>
    • An example line for configuring the NuMI spill trigger. delay is the time (in 500ns ticks) to add to the spill timestamp to allow for a trigger start when neutrinos hit the detector, rather than when the accelerator signal fires.
  • <MinibooneSpill enableFlag="false" length="10" prescale="1" delay="0" name="DefaultBnB" depth="100" maxrate="50.0"/>
    • An example line for configuring the BNB spill trigger. delay is the time (in 500ns ticks) to add to the spill timestamp to allow for a trigger start when neutrinos hit the detector, rather than when the accelerator signal fires.
  • <PPSSpill enableFlag="false" length="1" prescale="1" delay="0" name="DefaultPPS" depth="100" maxrate="50.0"/>
    • An example line for configuring the PPS spill trigger. delay is the time (in 500ns ticks) to add to the spill timestamp to allow for a trigger start when neutrinos hit the detector, rather than when the accelerator signal fires. You'll probably want this to have as short a length as possible, it's a heartbeat not a real data collector.
  • <Sim enableFlag="false" prescale="1" name="DefaultSim"/>
    • An example line for configuring the Simulation trigger. These triggers are fed to GT by the SimulationManager, and passed along almost untouched by GT, except GT chooses the trigger (event) number and obeys the configured prescale factor. General users are not going to be using this feature, see the SimulationManager package for the gory details. Rate throttling will ever be implemented for this trigger.
  • Note that all the DDT (and SNEWS) triggers are now (as of 11/11/13) configured differently than the rest, to better fit within the DAQConfigurationManager tools. The "DDTSet" (or "SNEWSSet") object now contains one line for each trigger, rather than having separate Sets for each one. The DDT and SNEWS code select on the "name" field, unlike the other triggers where it's just an arbitrary handle perhaps used by a DB somewhere, but nowhere in the GT itself. So, start a block with <DDTSet> and close it with </DDTSet>, containing some or all of the following lines:
    • <DDT enableFlag="false" prescale="1" name="DDSN" depth="100" maxrate="50.0"/>
      • accept DDT's of the Supernova sort
    • <DDT enableFlag="false" prescale="1" name="DDEnergy" depth="100" maxrate="50.0"/>
      • accept DDT's that are energy-based triggers sort
    • <DDT enableFlag="false" prescale="1" name="DDCalMuon" depth="100" maxrate="50.0"/>
      • accept DDT's of the muons needed for calibration sort
    • <DDT enableFlag="false" prescale="1" name="DDUpMu" depth="100" maxrate="50.0"/>
      • accept DDT's of the upward-going sort
    • <DDT enableFlag="false" prescale="1" name="DDNuMu" depth="100" maxrate="50.0"/>
      • accept DDT's of the contained-vertex muon sort
    • <DDT enableFlag="false" prescale="1" name="DDNuE" depth="100" maxrate="50.0"/>
      • accept DDT's of the contained-vertex electron shower sort
    • <DDT enableFlag="false" prescale="1" name="DDFastMono" depth="100" maxrate="50.0"/>
      • accept DDT's of the Fast Monopole sort
    • <DDT enableFlag="false" prescale="1" name="DDSlowMono" depth="100" maxrate="50.0"/>
      • accept DDT's of the Slow Monopole sort
    • <DDT enableFlag="false" prescale="1" name="FEBOverflow" depth="100" maxrate="50.0"/>
      • accept FEB Overflow triggers
    • <DDT enableFlag="false" prescale="1" name="DDActivity1" depth="100" maxrate="50.0"/>
      • accept ND activity triggers of the first sort
    • <DDT enableFlag="false" prescale="1" name="DDActivity2" depth="100" maxrate="50.0"/>
      • accept ND activity triggers of the second sort
    • <SNEWS enableFlag="false" prescale="1" name="SNEWSTrig" depth="100" maxrate="50.0"/>
      • accept external SNEWS SNe triggers
    • <SNEWS enableFlag="false" prescale="1" name="SNEWSBeatSlow" depth="100" maxrate="50.0"/>
      • accept external SNEWS slow heartbeat triggers
    • <SNEWS enableFlag="false" prescale="1" name="SNEWSBeatFast" depth="100" maxrate="50.0"/>
      • accept external SNEWS fast heartbeat triggers
    • <SNEWS enableFlag="false" prescale="1" name="LIGOTrig" depth="100" maxrate="50.0"/>
      • accept external LIGO triggers. Uses the existing NOvA SNEWS trigger infrastructure
    • <SNEWS enableFlag="false" prescale="1" name="LIGOBeatSlow" depth="100" maxrate="50.0"/>
      • accept external LIGO slow heartbeat triggers
    • <SNEWS enableFlag="false" prescale="1" name="LIGOBeatFast" depth="100" maxrate="50.0"/>
      • accept external LIGO fast heartbeat triggers
    • <SNEWS enableFlag="false" prescale="1" name="SNXTrig" depth="100" maxrate="50.0"/>
      • accept (and issue!) supernova triggers from one detector to the other
    • <DDT enableFlag="false" prescale="1" name="DDContained" depth="100" maxrate="50.0"/>
      • accept contained vertex triggers
    • <DDT enableFlag="false" prescale="1" name="DDMoon" depth="100" maxrate="50.0"/>
      • accept moon track triggers
    • <DDT enableFlag="false" prescale="1" name="DDSun" depth="100" maxrate="50.0"/>
      • accept sun track triggers
    • <DDT enableFlag="false" prescale="1" name="DDMichel" depth="100" maxrate="50.0"/>
      • accept Michel electron triggers
    • <DDT enableFlag="true" prescale="1" name= "DDMichelV2" depth="100" maxrate="50.0"/>
      • ... and if there ever exists another version of the Michel DDT
    • <DDT enableFlag="true" prescale="1" name= "DDMichelV3" depth="100" maxrate="50.0"/>
      • ... or another
    • <DDT enableFlag="true" prescale="1" name= "DDMichelV4" depth="100" maxrate="50.0"/>
      • ... and another. Andrew likes plenty of spare trigger bits. I'm happy using the existing versioning in the trigger headers.
    • <DDT enableFlag="true" prescale="1" name= "DDMichelTest" depth="100" maxrate="50.0"/>
      • ... and for testing.
    • <DDT enableFlag="true" prescale="1" name= "DDFastMonoNN" depth="100" maxrate="50.0"/>
      • Enhao's new Neural Network based fast monopole trigger
    • <DDT enableFlag="true" prescale="1" name= "DDFastMonoNNV2" depth="100" maxrate="50.0"/>
      • ... and if there ever exists another version of the NN monopole trigger
    • <DDT enableFlag="true" prescale="1" name= "DDFastMonoNNV3" depth="100" maxrate="50.0"/>
      • ... or another.
    • <DDT enableFlag="true" prescale="1" name= "DDFastMonoNNTest" depth="100" maxrate="50.0"/>
      • ... and a test version.
    • <DDT enableFlag="true" prescale="1" name= "DDNNBar" depth="100" maxrate="50.0"/>
      • A trigger looking for the signal of neutron/anti-neutron annihilation, a baryon number violating search like proton decay.
    • <DDT enableFlag="true" prescale="1" name= "DDHmu" depth="100" maxrate="50.0"/>
      • A trigger looking for long, horiztonal muons, for calibration purposes.

Files