seisglitch detect

The detect function allows detect the “glitches” in the raw data of the VBB and SP seismometers. Remember that glitches - in our model outlined in Scholz et al, (2020) - are steps in acceleration convolved with the sensor’s instrument response. Glitch detection is the necessary step if you want remove glitches (and spikes), as the removal function takes the output of the glitch detection as input. The glitch detector is also responsible for the calculation of the glitch azimuths and incidence angles needed for certain plots in the plot function. For the detection, the input waveform data are internally always decimated to 2 SPS (or 2.5 SPS), which leads to a typical run time of around 2 minutes per 24 hours of 3-D seismic data.

To use the glitch detector, activate your correct Python environment, fill the detect options in the config.yml, then run from terminal:

seisglitch detect path/to/config.yml

The glitch detector is now running according to your specifications. The general working principle of the glitch detector is described in Scholz et al, (2020), Section Glitch Detection (‘MPS’ method).

In the following, the glitch detector’s parameters - that you find in the config.yml - are detailed:

• taper_length_per_side: in %, i.e., 0.05 means 5% for each side. On tapered data bits no glitch detection is done.

• pre_filt: filter used on the raw data prior to deconvolution of the instrument response to convert to acceleration.

• water_level: water level used for the deconvolution of the instrument response to convert to acceleration. If both are specified (pre_filt as well), both options are applied.

• ACCfilter: dictionary specifying the type of filter used for the acceleration data. There is no obvious reason to change the default (bandpass: 0.001 - 0.1 Hz).

• threshold: threshold amplitude to trigger glitches on the derivative of the filtered acceleration data (filtered jerk). Unit is therefore ms ^-3. The negative threshold applies to negative amplitudes.

• plot_triggering: If True, interactive plots are shown during the detection that illustrate all glitch triggers that passed the threshold condition. These candidates are not yet checked against their polarization and thus do not necessarily represent glitches.

• glitch_min_length: In seconds. Defines the minimum length in which a new glitch candidate cannot be declared with respect to the previous candidate. This parameter allows to detect “poly-glitches”, i.e., glitches occurring on glitches before the first one has sufficiently decayed. 5 seconds is fine.

• glitch_length: Fixed, in seconds. Glitch detections deliver glitch start times, this parameter thus fixes the end times only. For VBB 25 seconds is fine, for SP 50 seconds is fine.

• glitch_min_polarization: Glitches have a high linear polarization (circular=0 .. 1=linear). Therefore, this condition throws out glitch candidates that have too little linear polarization. The polarization analysis is performed on the glitch window, i.e., detected glitch start plus glitch_length.

---

There are only two parameters that really affect the sensitivity of the glitch detection: threshold and glitch_min_polarization.

• threshold: the lower you choose it, the more often it triggers on the filtered jerk. As glitches are steps in acceleration convolved with the sensor’s instrument response, their derivative should be delta-like impulses whilst all other signals should not be delta-like. Obviously, at some stage, these triggers do not represent glitches anymore but signal / seismic noise. The threshold therefore should be chosen high enough to avoid triggering noise but low enough to detect small glitches, too (there are hundreds of smaller glitches per Martian day in the VBB data, but less on SP data). Furthermore, seismic amplitudes vary significantly during a Martian day due to weather influences. Seismic amplitudes may therefore vary by a factor of 100 and more, which complicates glitch detections. To circumvent, each glitch candidate is checked for its linear polarization that should be high for glitches. That is, the following parameter also has influence:

• glitch_min_polarization: polarization can be between 0 and 1, where 1 is full linear polarization and 0 circular polarization. Glitches - given they represent acceleration steps seen by the sensors - have a high, linear polarization. The higher you choose this parameter (e.g. 0.95) the less glitch candidates will pass and be declared as glitch. In combination with threshold this should minimize potential false-positives, however, some certainly remain. The more lax the settings are chosen, the more false-positive detections occur. Note the polarization analysis is performed on the original, gain corrected raw data rotated into the ZNE-system, i.e., no downsampling of the input data is done for this analysis. Table 1 summarizes sensible ranges for the two parameters threshold and glitch_min_polarization.

Table 1: Sensible ranges for the two most important parameters influencing the performance of glitch detection; ‘strict’ results in less glitch detections however with little false-positives, ‘lax’ results in more detections however with more false-positives especially when glitch amplitudes approach the noise level. Stricter settings result in slightly faster run times as e.g. polarizations are calculated for less glitch candidates.

		threshold	glitch_min_polarization
VBB	strict	2.0 x 10 -9 ms -3	0.98
	lax	0.5 x 10 -9 ms -3	0.85
SP	strict	15.0 x 10 -9 ms -3	0.99
	lax	5.0 x 10 -9 ms -3	0.95