class suspensionMon : public DatEnv, MonServer A glitch monitor using absolute thresholds
This monitor triggers on glitches in filtered data based on absolute thresholds. The any data values (thresholds, RMS) are given in counts, and times are recorded in GPS and UTC for each event. A log file is also available which gives a regular update on the frequency of the glitches in each channel.Using the suspensionMon monitor
According to the help info:
Usage: suspensionMon [-conf <file>] [-osc <osc_file>] [-infile <frame_file>] [+toc | -toc] [-h | --help]suspensionMon looks for glitches with absolute thresholds (in counts). Options include:
-conf <file> -- The configuration file to use as input -osc <osc_file> -- Use an Operating State Condition configuration file -infile <frame_file> -- Used when running offline. Frame files can include a wildcard character, which must be escaped, as in: -infile <frame_path>/H-R-\*.gwf +toc or -toc -- access frames using TOC (faster) or not -h or --help -- Generates this help text and exits -debug [<debug_level>] -- To be used only for debugging purposes Operating State Conditions- Currently only one Operating State Condition (OSC) can be used each time the monitor is run. It is not necessary to set or use an OSC to run the monitor, but if one is desired, both the above command-line parameter and a parameter in the Configuration file (discussed below) must be set, as well as identifying the channels which will be using the OSC.
Applications of suspensionMon- The goal of suspensionMon is to be a monitor which provides timestamps for which the gravity-wave data cannot be trusted. These times are singled out as possible correlations with glitches in environmental or other diagnostic channels.
The Configuration File
A configuration file consists of two sections: run-time parameters and channel-specific parameters. The `#' character signifies the start of a comment, and is not used as part of the configuration file. One self-documented example might look like the following:
#==================================== # file path to the text output data file Data_File_Prefix : /home/bstubbs/suspensionMon/test_data # file path to the log file Log_File_Prefix : /home/bstubbs/suspensionMon/test_log # length of data to process in seconds (0 for infinity) Total_Runtime : 0 # of bins which composes each histogram Number_Bins : 20 # Overall allows/disallows triggers to be sent Trigger_ON/OFF : 1 ##### This first one-liner corresponds to a 100Hz HighPass Filter #Channel H2:LSC-MICH_CTRL H2:Both_arms_locked "-7.9577 13.7832 -7.9577 -13.7832 -15.9155 0" "0 0 0 0 0 0" H2:LSC-MICH_CTRL_HP100Hz Channel H2:LSC-MICH_CTRL 0 ### filter: Name Poles Zeroes Gain ### -------------------------------------------------------------------------------------------------------- Filter H2:LSC-MICH_CTRL_HP100Hz "-7.9577 13.7832 -7.9577 -13.7832 -15.9155 0" "0 0 0 0 0 0" ### glitch: Name Threshold(counts) Time_constant ### ------------------------------------------------------- Glitch suspensionMon 1.0 2.0 ### stats: Name Type Cumulative? Refresh Initial_Val ### -------------------------------------------------------------------- Statistic MICH_CTRL-Mean Mean 0 ### results: Name Type Cumulative? Refresh Output_mask ### --------------------------------------------------------------------- Result MICH_CTRL-updates Log 0 20 4 Result MICH_CTRL-events Events 1 2Some notes:
- Using a Wait Time of `0' will cause suspensionMon to make a histogram of the filtered data. This is useful when determining how many datapts actually fall within the defined thresholds. No data file will be produced when Wait Time is set to `0'.
- The log file from a previous run of the monitor will create a valid configuration file for easy reference and re-running over off-line data.
- Please note that the filtering scheme has changed since 5/5/2002. The simple `LowPass', `HighPass', `BandPass' scheme has been replaced by a poles, zeroes, gain scheme.
- A channel may receive no filtering by replacing the poles and zeroes fields with `0'.
- The Trigger Comment parameter will show up in either/both the data file or the trigger as it is sent out to the `GDS Triggers' table in the database. In the latter case, it appears in the `data' field.
Output from suspensionMon
Log File Output- suspensionMon will always write out a log file (which can then be re-used as a configuration file, see above). The log file currently contains the configuration parameters which were used to produce the output, followd by a series of snapshots of the monitor's progress. These snapshots contain multiple lines per channel, as seen in the following example:
###==================================== ### Monitor Start = 693644209 ###------------------------------------ ### Log_Interval: 0 GPS_start: 693644209 Interval_Duration: 1000 ### Channel Statistics ### Channel | Filtered | Threshold | # Triggers | # Triggers | Current | Dead Time | Dead Time | Filtered | # Single- ### Name | RMS | | in Interval | Total | Run Time | in Interval | Total | Kurtosis | Bin Trigs #0 H2:IOO-MC_F 1435.06 Totals 3163 3163 1000 140.333 140.333 0.0220399 136 #0 H2:IOO-MC_F 1435.06 18529.7 0 0 1000 0 0 0.0220399 0 #0 H2:IOO-MC_F 1435.06 17724.1 0 0 1000 0 0 0.0220399 0 #0 H2:IOO-MC_F 1435.06 16918.4 0 0 1000 0 0 0.0220399 0 ...The section of lines for each channel describe a histogram of trigger threholds and the number of triggers fitting between that threshold and the next one. The first line for each channel gives the totals for each histogram. The columns are described below.
Each line is "commented out" so that the log file can be re-used as a configuration file. The lines are preceded by the current log interval to be distinguishable, say, by an `awk' or `grep' script.
Description of columns:
Filtered RMS RMS of filtered data for the interval Filtered Kurtosis Kurtosis of filtered data for the interval Threshold Threshold level (in filtered ADC counts) # Triggers ... Number of triggers with max amplitudes falling above the threshold (but not above the next highest threshold) Dead Time ... Accumulated time of glitch durations (in seconds) # Single-Bin Trigs Number of triggers with durations less than or equal to (sample rate * order of filter) for the interval Current Run Time Number of seconds which the monitor has processed Data File Output/Trigger Generation- Depending on the Trigger_ON/OFF parameter in the configuration file, suspensionMon may produce individual triggers. These triggers may be sent to a datafile or to the meta-database, but in either case will include the same information. Below is a snippet from a sample data file, followed by a description of the columns.
### Trigger Statistics: ### Event Start | Channel | Event Start | Duration | Max Glitch Size | RMS during | Trigger ### (UTC) | Name | (GPS) | (seconds) | (in counts) | Glitch | Comment 01.12.29 6:56:36 H0:PEM-EX_TILTT 693644209.1054688 0.00390625 10.7039 10.7039 H0:PEM-EX_TILTT_HP1Hz 01.12.29 7:08:30 H0:PEM-HAM7_ACCY 693644923.8007812 0.000488281 774.843 774.843 H0:PEM-HAM7_ACCY_HP1Hz 01.12.29 7:08:32 H0:PEM-BSC8_ACCX 693644925.0883789 0.000488281 788.026 788.026 H0:PEM-BSC8_ACCX_HP1Hz
Event Start ... Start of trigger (Either in UTC or GPS times) Channel Name Name of the channel triggered Duration (seconds) Duration for which filtered data was in a "triggered state", as defined by the Wait Time parameter -- not necessarily all filtered datapts were outside the thresholds Max Glitch Size Size of the largest deviation from the mean (in filtered ADC counts) RMS during Glitch RMS deviation of all datapts within the trigger; also used as `significance' for meta-database trigger Trigger Comment Also used as `subtype' for meta-database trigger
void OutputLog(bool check)
std::vector <channel::chInterface> fChannels
suspensionMon(int, const char**)
~suspensionMon(void)
void ProcessData(void)
void Attention(void)
alphabetic index hierarchy of classes
generated by doc++