# Seismological Research Letters

- © 2015 by the Seismological Society of America

## INTRODUCTION

The identification of repeating earthquakes by waveform cross correlation (multiplet analysis) has many applications in the analysis of seismic data and is increasingly being applied to volcanic‐seismic datasets. Multiplet analysis can be used to evaluate stress changes at volcanoes, to constrain the depth of explosions, or to improve locations of small‐amplitude events (Buurman and West, 2010; Thelen *et al.*, 2011; Battaglia *et al.*, 2012; West, 2013). Repeating earthquakes often occur during tectonic earthquake sequences (Nadeau *et al.*, 1995; Peng and Zhao, 2009), can occur within large regional seismic data catalogs (Schaff and Richards, 2011), and have been observed as microearthquakes on creeping faults (Waldhauser and Ellsworth, 2002; Malservisi *et al.*, 2005) and as icequakes in glaciers (Carmichael *et al.*, 2012; Thelen *et al.*, 2013). Multiplet analysis thus has the potential to be an intrinsic part of the seismologist’s toolbox; however, many studies cite computational limitations when analyzing multiplets (Petersen, 2007; Thelen *et al.*, 2010, 2011; Ketner and Power, 2013). Cross correlation is computationally expensive and large datasets can rapidly become difficult to analyze. Cross‐correlation algorithms are considered Big‐*O*(*N*^{2}) problems (in which *N* is the total number of events) in terms of the performance time of the algorithm (Black, 2004). Seismic data catalogs of hundreds of thousands of events are not uncommon at well‐monitored volcanoes (Ketner and Power, 2013), and global seismic catalogs can number many millions of events (Addair *et al.*, 2014).

Waveform cross correlation for the identification of repeating earthquakes has been carried out on seismic events for many years (Nadeau *et al.*, 1995) and initially was confined to small datasets. Cross correlation can be used to search for matches to a master event within a catalog and reduce the detection threshold of waveforms (Meng *et al.*, 2012; Bobrov *et al.*, 2014). The use of such waveform matched‐filter techniques requires *a priori* knowledge of the master event, which may not always be known. Given the Big‐*O*(*N*^{2}) nature of cross correlation, to do bruteforce correlation of large datasets, that is, with no *a priori* knowledge of the master events, often requires the use of high‐end parallel computing methods (Addair *et al.*, 2014). However, not all researchers or monitoring institutions around the world have access to such computing resources. Therefore, we sought to develop a program, peakmatch, that would allow cross correlation of large seismic datasets without the need for expensive computer resources, hence making multiplet analysis of large datasets a reality for institutions or researchers with limited computing resources. Peakmatch makes use of multithreading on computers that have multiple processing cores, but this is not an essential requirement of the method.

Once the problem of cross‐correlating large datasets has been solved, a secondary challenge is how to group events based on the cross‐correlation outputs. We therefore developed a secondary program, graphconnectivity, to identify multiplets from the potentially millions of cross‐correlation event pairs output by our peakmatch program.

We tested peakmatch against full cross correlation of an ∼16,000 event data catalog from Telica Volcano, Nicaragua, and found that peakmatch missed only 0.13% of events. We then demonstrated the potential of our program by running peakmatch on a seismic catalog of >200,000 events, which it handled easily on a standard desktop computer.

## PROGRAM DESCRIPTION

### Peakmatch Program Overview

To cross correlate two events, the sliding dot product of the two time‐series vectors is calculated. This results in an *O*(*M*^{2}) performance per event pair and *O*(*N*^{2}×*M*^{2}) performance for all event pair calculations (in which *N* is the total number of events and *M* is the number of data points per event). A significant improvement in performance can be gained by instead using fast Fourier transform (FFT) based cross correlation. In this case, the cross‐correlation calculation becomes a multiplication in the frequency domain, resulting in *O*(*M*) operations per event pair, and *O*(*M*×*N*^{2}) performance for all event pair calculations. However, this approach is still too computationally expensive for large datasets, and therefore in our code a fast‐approximation stage is utilized in the time domain to preselect events for subsequent FFT‐based cross correlation.

Our code peakmatch utilizes a fast‐approximation process to preselect candidate pairs for cross correlation (Fig. 1). One of the main assumptions behind this process is that the number of candidate pairs identified in this approximation stage is significantly smaller than the total *N*^{2}/2 pairs, in which *N* is the total number of events. This method works best for datasets that can be characterized by individual waveforms with varying amplitude peaks and troughs. Although peakmatch makes use of multithreading where available, the majority of the time saving comes from the fast‐approximation peakmatching stage of the process that uses three optimizations:

*Top peak alignment*: Two events are more likely to have a high‐cross‐correlation coefficient if their peaks and troughs occur at the same time. The largest dot products, that is, the largest cross‐correlation coefficients, occur when the largest amplitude peaks and troughs are aligned. In this fast‐approximation stage, only the dot product for the top*K*peaks/troughs is calculated, rather than calculating the dot product for every offset as is done in a conventional sliding dot product. This approximation step rapidly reduces the number of calculations per event pair, and provided*K*is set to be significantly smaller than*M*^{1/2}, can result in*O*(*M*) performance. Figure 2a shows a 4 s section of an example pair of events that have a maximum cross‐correlation coefficient of 0.86. In this example, the three largest peaks (*K*=3) are identified and cross‐correlation coefficients (Xcorr) calculated for each of the*K*^{2}possible alignments (Fig. 2b). The largest cross‐correlation coefficients occur at alignments A1:B1 and A2:B2, which in this example occur at the same offsets (Fig. 2c), however, this may not always be the case.*Subsampling*: By only calculating the dot product of the peak‐aligned events at a given number of data points (*S*), the calculation speed is improved by a factor of*S*(sampling stride).*Amplitude threshold*: The cross‐correlation coefficient is dominated by multiplication of the largest peaks and troughs, yet most of the calculation time is spent multiplying the existing low‐amplitude noise of the signal. By ignoring low‐amplitude noise values and only calculating the dot product for data points that are higher than some fraction of the maximum amplitude, considerable gains can be made in performance.

Further improvements in performance time can be achieved by cropping the waveform. We did not want to rely on picked first arrivals to crop the waveforms, as this would limit this program for use with only those data that contain picks. Instead, we chose to crop the earthquake by searching a user‐defined window for the largest peak‐to‐peak amplitude, then cropping the waveform to a user‐defined amount before and after this maximum peak.

These optimizations introduce a certain amount of error into the final cross‐correlation output list. There will be events (false candidates) that are considered as candidate pairs after the fast‐approximation stage, but that do not correlate well when full FFT cross correlation is performed. There will also be events (false negatives) that would correlate well during the full FFT cross‐correlation stage, but were not considered as candidate pairs as they do not meet the candidate pair selection criteria, and hence are discarded. Potentially waveforms that have all peaks with the same amplitude could become false negatives. False‐candidate events are discarded in subsequent FFT cross‐correlation stages, but with an increased amount of processing time. However, false negatives are lost permanently from the final output. Hence, an analysis phase is essential to tune the parameters to a specific dataset, to minimize false candidates and false negatives and to reach a balance between an acceptable loss of false‐negative events and running time. A higher false‐candidate rate will increase the postprocessing time, but a higher false‐negative rate means a loss of events that belong in the final catalog.

### Peakmatch Control Parameters

Program operation is controlled entirely by a configuration file xcorr.conf (see Appendix). The mode of operation is specified in this file, as are paths to data directories. All input files are single column text files. This format was chosen rather than any binary data format (e.g., Seismic Analysis Code [SAC], MiniSEED) to make the program versatile for any data input. Input files need to be of the same sample length, and this length is specified in this file. Cropping can be enabled or disabled; if enabled there is a user‐defined range to search for maximum peak‐to‐peak amplitudes, and a user‐defined crop window before, and after the maximum peak. The three optimization parameters (as discussed in the previous section) are then specified (i.e., top *K* peaks, sampling‐stride, and top‐amplitude threshold). Next, candidate threshold is set; this is not a true cross‐correlation threshold value, but an indicator of similarity based on the approximations, which affects the number of candidate pairs passed on for postprocessing. The final‐threshold cross‐correlation coefficient is then specified, and only events that have a cross‐correlation coefficient higher than this value will be output in the final postprocess stage. Peakmatch utilizes multiple processing cores, and the specific system settings (i.e., number of processing cores, and memory‐cache size for FFT calculations) can be input here. Events can be normalized by subtracting the mean amplitude from all readings. Next various settings for additional spectral analysis modes of operation are set, such as bandwidth of dominant frequency peaks, sample rate, filter bands, number of frequency peaks, spectral amplitude bands, and spectrogram time‐window sizes.

### Peakmatch Program Operation

#### Phase 1: Analysis Phase

A sample of 1000 events is analyzed using both peakmatch and full FFT cross correlation. The results are compared and performance statistics are output (i.e., number of false candidates, number of false negatives, and an estimation of processing time for both the peakmatch stage and the postprocess stage for the full dataset). Performance calculations in the analysis phase do not take into account multithreading, whereas peakmatch uses the number of cores defined in the configuration file, hence these time estimations may be inaccurate by this factor. Crop parameters, top *K* peaks, sampling‐stride, amplitude‐threshold, candidate‐threshold, and final‐threshold values should all be tested to find specific parameters for the target dataset that give optimal output in terms of minimal false negatives versus reasonably short processing time.

#### Phase 2: Peakmatch

The fast‐approximation stage performed using the parameters chosen from the analysis phase. Events are considered as a candidate pair if they match above the candidate threshold. A higher candidate threshold lets more candidate pairs pass to the postprocess stage, at a cost of increased postprocessing time.

#### Phase 3: FFTprecache

The final FFT cross correlation of all candidate pairs calculates the complex dot product of the Fourier transform of one event with the Fourier transform of the reverse of the second event. To speed up this process, the FFT of every event and the FFT of the time reverse of every event is calculated and stored in a large memory‐mapped file.

#### Phase 4: Postprocess

Maximum cross‐correlation values of each candidate pair output by the peakmatch stage (phase 2) are calculated. The complex dot product of the FFT of event A and the FFT of the time reverse of event B is calculated from the precached FFT values calculated in phase 3. The inverse Fourier transform is then calculated, and the highest value of the real components is the cross correlation of the two events. Event pairs are written to an output file if their cross‐correlation value is above the final‐threshold value specified in the control parameters. This final‐threshold value should be chosen based on either visual comparison of sample waveforms, or on the statistical distribution of cross‐correlation coefficients of a test dataset.

### Additional Modes of Operation

*Bruteforce*: All events within a specific directory can be cross correlated, and event pairs above the final threshold will be output. The FFT precache stage needs to be performed before the bruteforce mode. This mode should not be used on very large datasets (i.e., more than ∼10,000 events).*FFT dominant frequency*: This mode was developed to output spectral information on individual events; no cross correlation is performed in this mode. The dominant frequency of every event is calculated from the FFT of the waveform (with or without time‐domain cropping and with or without bandpass filtering). A user‐defined number of frequency peaks can be output, and a user‐defined bandwidth can be specified between each frequency peak (e.g., if the dominant frequency peak of an event was found at 1 Hz, a bandwidth of 0.5 Hz could be set such that the next highest frequency peak is returned excluding a 0.5 Hz window above and below 1 Hz). Maximum peak‐to‐peak time‐domain amplitude of each event is output after the dominant frequencies. Mean spectral amplitudes within a series of user‐defined frequency bands can then be output.*Plot 1D and 2D*: Spectral information from user‐defined spectral amplitude bands can be displayed rapidly either via a 1D power spectral density plot in either a tiny or a normal format, or via a 2D spectrogram with user‐defined time windows.

### Graphconnectivity Program

A separate program, graphconnectivity, was developed to extract information from the potentially millions of cross‐correlation event pairs output by peakmatch. There are various approaches for defining a multiplet. One approach is to identify a master event and match correlated events to the master event. A master event can be chosen as the event with the most connected events above a certain threshold (Green and Neuberg, 2006), or it can be chosen based on average cross‐correlation values from correlation with all other events (Petersen, 2007). Another method of family selection uses a hierarchical clustering technique that progressively links pairs until clusters are found at a given threshold (Rowe *et al.*, 2002; Buurman and West, 2010).

Graphconnectivity uses an undirected graph, in which the most connected node is identified (a master event), and it along with all its immediate connections are extracted. The graph is then reordered and the process repeated until all connected nodes are extracted. This method ensures that each event only belongs to one family. As with any method for finding families the problem of orphaned events occurs. These are events that do not directly connect to any of the master events, but will be connected to family members of the master events. After removal of the master event and its respective family, the orphaned event no longer has a connection within the graph and now belongs to no family at all. These orphaned events are output in the final connected output as individual events that do not belong to a multiplet.

## DATA ANALYSIS

### Analysis 1: Verification of the Peakmatch Method

To test the efficiency and accuracy of the peakmatch method we used a test dataset from the 1999 eruption of Telica Volcano, Nicaragua. Data were provided by the Instituto Nicaraguense de Estudios Territoriales from a single‐station short‐period (1 Hz) seismic station (TELN) ∼0.4 km from the active vent and consists of >16,000 events. Using a cross‐correlation threshold of 0.7, we cross correlated all events in this catalog (referred to here as the bruteforce method) and compared this to the same dataset cross correlated using the peakmatch method (Fig. 3). A threshold value of 0.7 is justified from analysis of the frequency distribution of cross‐correlation coefficients from both a random sample of events (Fig. 4a) and a sample from a period with known multiplets (Fig. 4b). For the random sample, 99.6% of event pairs have a cross‐correlation coefficient lower than 0.7, whereas for the period containing known multiplets, 77.5% of event pairs have a cross‐correlation coefficient lower than 0.7.

The final peakmatch parameters (Table 1) from the analysis phase of the program were chosen to minimize false negatives, give an acceptable false‐candidate rate and reasonable processing time estimation. From analysis of the 1000 test events, a total of 500,000 event pairs were considered. Using the peakmatch fast‐approximation stage, a total of 4433 event pairs were identified above the candidate threshold. From subsequent FFT cross correlation of the same test events, 1610 event pairs were identified above the final cross‐correlation threshold, giving a false‐candidate rate of 275% (in which false‐candidate rate is defined as the percentage of number of event pairs above candidate threshold/number of event pairs above final threshold) (Table 2). One event pair was identified as a missed event pair as it was not above the candidate threshold, but it was above the final threshold, giving a false‐negative rate of 0% (in which false‐negative rate is defined as the percentage of number of missed event pairs/number of event pairs above final threshold) (Table 2). The peakmatch fast‐approximation stage for the full >16,000 dataset then identified ∼1.7 million candidate pairs above the candidate threshold and the postprocessing stage resulted in 479,896 correlated pairs above the final threshold. Bruteforce cross correlation of the same dataset resulted in 480,522 correlated pairs above the same threshold, giving peakmatch a false‐negative rate of 0.13% when compared to the bruteforce method.

The graphconnectivity program identified 6967 connected events for the bruteforce method, and 6960 connected events for the peakmatch method. Both methods identified a dominant multiplet with the same number of events (819) and the same master event (11 September 1999 14:39). Because of the process of removing the most connected multiplets, multiplets extracted during the graphconnectivity process become progressively smaller, eventually producing orphaned events. For both the bruteforce and the peakmatch methods, 83% of the connected events belong to multiplets with two or more events, resulting in 443 multiplets for the bruteforce method and 441 multiplets for the peakmatch method. We chose to plot only those multiplets that contained two or more events, that is, to ignore the orphaned events, and we observe no significant differences in the timelines produced from both methods (Fig. 3b,c).

Previous multiplet analysis of the same data catalog was carried out (Rodgers *et al.*, 2013) using the MATLAB GISMO suite (Reyes and West, 2011), following the two‐stage method of Petersen (2007) and Thelen *et al.* (2010). In this study, multiplets were identified by cross correlating all events in each 24 hr period, compiling stacked events for each 24 hr period and then cross correlating all the stacks (291 in total) across the entire study period. As this two‐stage method is frequently used for multiplet analysis of large volcano seismology catalogs, it is worth comparing the difference in output between this method and peakmatch. The two‐stage method identified a total of 2366 connected events, of which 596 were orphaned events, leaving 37 multiplets of two or more events (Fig. 3d). As expected, there are significant differences between the two‐stage method and cross correlation of the full data catalog (either by bruteforce or by peakmatch). Our code identified significantly more connected events than the two‐stage method; we identified 6960 connected events with peakmatch, versus the 2366 identified via the two‐stage method. These differences are likely to arise from differences due to the methodology of creating and correlating daily stacks rather than correlating all pairs.

### Analysis 2: TESAND Data from 1 April 2010 to 18 March 2013

Having successfully cross correlated a relatively small (16,000 events) dataset, we applied our peakmatch and graphconnectivity method to a larger dataset. Data for this analysis come from the vertical component of a single‐station broadband (30 s) instrument (TBTN) (collocated with TELN, analysis 1) from the Telica seismic and deformation (TESAND) network (Rodgers *et al.*, 2015). This catalog runs from 1 April 2010 to 18 March 2013 and comprises 217,101 individual events. Multiplet analysis of this dataset was carried out using the parameters in Table 1. A final‐threshold value of 0.8 was initially chosen by plotting the frequency distribution of cross‐correlation coefficients of ∼1100 events from a randomly chosen 10‐day period from 1 October 2010 to 10 October 2010. The frequency distribution for this randomly selected period (Fig. 5a) shows that 99.6% of cross‐correlation coefficients are below the 0.8 threshold. After identification of multiplets, the frequency distribution of cross‐correlation coefficients from the ∼1400 events from a three‐day period (5 September 2010 to 7 September 2010) that contained known multiplets was plotted for comparison (Fig. 5b). For this period with known multiplets, 91.1% of event pairs have a cross‐correlation coefficient below the 0.8 threshold. Iteration of the analysis phase resulted in the final parameters in Table 1 and produced a false‐candidate rate of 571% and a false‐negative rate of 0% (Table 2). As in the previous analysis, this low false‐negative rate for the 1000 sample set gives us confidence that we have missed very few events in correlation of the full data catalog. Over 63 million candidate pairs were identified by the fast‐approximation phase. Full cross correlation of these 63 million pairs resulted in approximately 10.5 million event pairs that correlated above the final threshold. From the 10.5 million event pairs, 51,704 connected events were identified. Not counting orphaned events (of which there were 7286) there were 9432 multiplets (of two or more events) and the largest family contained 4877 events.

We chose to display only the 9432 multiplets with two or more events (Fig. 6), which in total contained 44,418 connected events (∼86% of the connected events). The study period for this analysis starts on 1 April 2010 and there are ∼250 multiplets that are active over the first month, many of which remain active throughout the entire study period. Some of these multiplets may have had event repetition rates slow enough that events belonging to this family could have occurred before the start of the study period, however, there are many events in this one‐month period that have repetition rates sufficiently high that they can be considered to have begun at this point.

## DISCUSSION OF CODE PERFORMANCE

We compared the results of our peakmatch method to the equivalent results from full bruteforce correlation of the same dataset. The code performed better than anticipated in terms of run time and memory usage and using a desktop computer (for computer specifications see Table 3) peakmatch was able to cross correlate the ∼16,000 events in approximately 12 min, using the parameters in Table 1. Cross correlation of the same data catalog on the same computer using bruteforce cross correlation took 14 hr. These times are given as a relative indication of the performance of peakmatch and are entirely relative, processing times for users will vary depending on the performance of the computer used and number of cores.

To perform a full cross correlation of all 217,101 events from the TESAND dataset would require 23.6 billion operations. Although high‐end parallel computing techniques (Addair *et al.*, 2014) would easily handle this task, the motivation for developing this code was to develop a program that could run on an average desktop computer without the need for parallelization. Peakmatch can handle multithreading, but the design of the program is such that this is not a requirement for peakmatch to operate. On a desktop machine (Table 3), we successfully ran peakmatch on this larger data catalog in under 5 hr.

Because the design of this program is to solve a specific large‐volume data problem, there are a few limitations. Events must already be in an event‐detected catalog, the program cannot search continuous waveform data for multiplets. This program writes output to text files for further analysis by the user; it does not display graphical representations of the output data. Again, this is due to the nature of the design; we aimed to write a program that could handle large amounts of data efficiently rather than recreate features in existing software (e.g., GISMO Reyes and West, 2011). The crucial part of the fast‐approximation stage relies on the waveforms having a dominant amplitude peak within the waveforms. Waveforms with equal‐amplitude peaks, or waveforms buried within high‐amplitude noise are likely to be missed by this fast approximation and so peakmatch may not be appropriate for detecting correlation on periods of continuous tremor, or on waveforms with very low signal‐to‐noise ratios.

## CONCLUSIONS

We developed a program peakmatch to efficiently handle the cross correlation of large seismic datasets without the use of high‐end parallel computing resources. The program uses a fast‐approximation stage to preselect potential candidate pairs for full cross correlation. We also developed a program graphconnectivity to identify connected events within the final cross‐correlation output. We tested our program against full cross correlation of a dataset of ∼16,000 volcano seismic events from Telica, Nicaragua, and found no significant difference in output from the peakmatch method versus cross correlation of all event pairs.

We find that our method performs cross correlation of large data catalogs extremely quickly on a desktop computer. Our method can easily be used for datasets of tens to hundreds of thousands of events and makes routine cross correlation of very large datasets a feasible data analysis tool for users who do not have access to dedicated high‐end computing resources. This kind of analysis is not limited to volcanic earthquakes, but can be applied to any discrete time series data that have a detectable peak, such as tectonic earthquake sequences, microearthquakes on creeping faults, and icequakes (Nadeau *et al.*, 1995; Waldhauser and Ellsworth, 2002; Thelen *et al.*, 2013). Additionally, identification of waveform families via the peakmatch method could serve as an *a priori* input waveform for matched filter techniques to search for waveforms within continuous or noisy data.

## DATA AND RESOURCES

Event detected seismic data for analysis 1 were collected by the Instituto Nicaraguense de Estudios Territoriales (INETER) and are archived by INETER. The continuous seismic data for analysis 2 are available through the Incorporated Research Institutions for Seismology Data Management Center Source code is hosted by GitHub and is available free. Source code, complete program documentation, system requirements, and usage instructions are given on these pages: https://github.com/simonrodgers/peakmatch-xcorr (last accessed May 2015) and https://github.com/simonrodgers/graphconnectivity (last accessed May 2015).

## ACKNOWLEDGMENTS

The Telica seismic and deformation (TESAND) network was deployed and maintained by Team Telica. We thank the staff at Instituto Nicaraguense de Estudios Territoriales for the 1999–2000 data and for field support for the TESAND network. We thank Pete LaFemina and Halldor Geirsson for multiple multiplet discussions. This work was funded by National Science Foundation grant EAR‐0911366 to D. Roman and EAR‐0911546 to P. LaFemina. Work undertaken at Oxford was completed while funded on NERC STREVA grant NE/J020001/1. We thank Doug Dodge, Jeremy Zechar, and an anonymous reviewer for thoughtful reviews that significantly improved this manuscript.

## APPENDIX

### CONTROL PARAMETER FILE (XCORR.CONF)

# mode ‐ ANALYSE, PEAKMATCH, FFTPRECACHE, POSTPROCESS, BRUTEFORCE, FFTDOMINANTFREQ, PLOT2D, PLOT1D

mode = ANALYSE

# more logging

verbose = false

# data directories

dataset.full = /events/full

dataset.sample = /events/sample

# expected length of files ‐ if any files are not this length, will be zero padded or truncated

expected‐file‐line‐count = 4000

# locate peak within peak‐range readings, then return a window around it

# e.g. data @50 Hz check for peaks between 5–40 seconds, calculate 4 second window before & 8 second after

crop = true

crop.min‐peak‐range = 250

crop.max‐peak‐range = 2000

crop.window‐before‐peak = 200

crop.window‐after‐peak = 400

# top K peaks (min and max), ordered by amplitude, which will be aligned together

# run‐time varies as O(top‐k‐peaks ^ 2) ‐ every event’s top K peaks are aligned against every other event’s top K peaks

top‐k‐peaks = 3

# sample events every sampling‐stride entries

# run‐time varies as O(1/sampling‐stride)

sampling‐stride = 3

# only calculate xcorr values for values where the amplitude is higher than this fraction of the peak amplitude

# the final xcorr value for a well‐matching pair is dominated by the multiplication of two peaks together (1000 * 1000≫50 * 50)

# setting this to a non‐zero value means eliminating a large amount of noise from the calculations, and drastically speeding up the calculation

# tweak this value in ANALYSE phase: too high −> false negatives. too low −> performance degradation

top‐amplitude‐threshold = 0.3

# threshold for candidates to be included

# this will be lower than the final xcorr calculated value

# tweak this value in ANALYSE phase: too high −> false negatives. too low −> too many false candidates for post‐processing

candidate‐threshold = 0.55

# threshold for the final FFT xcorr post‐process step

final‐threshold = 0.8

# number of threads to use in the PEAKMATCH and POSTPROCESS steps. set this equal to the number of processor cores for optimal performance.

# (performance calculations in the ANALYSE phase don’t use multi‐threading, so extrapolations may be inaccurate by this factor)

threads = 2

# in‐memory LRU FFT cache for FFT xcorr calculations.

# set to zero to disable this cache

fft‐memory‐cache‐size = 1000

# move the origin to zero before performing any calculations (subtract mean amplitude from all readings)

normalise‐events = true

dominantfreq.band‐width = 0.5

dominantfreq.filter‐below‐hz = 1

dominantfreq.filter‐above‐hz = 15

dominantfreq.sample‐rate = 50

dominantfreq.top‐freq‐count = 5

# space‐separated frequency (hz) bands (eg [1.3–4.5]) to calculate mean spectral amplitudes across

dominantfreq.mean‐frequency‐amplitude‐bands = [1–5] [5–10]

# plot a single‐band frequency spectrum on one line

plot.1d.tiny = true

# duration of bands to slice event into for 2d plot

plot.2d.bucket‐duration‐sec = 1

# VERTICAL, HORIZONTAL or SHADED

plot.2d.gradient = SHADED

# size of frequency bands to divide sample into for plot

frequency.band‐hz = 1