Why is there 'spike detection' and how are spikes defined?

[mewest]

Spike detection appears in multiple LTS classes. I can't sleuth out how the term spike is being defined algorithmically? Is this a common issue in infrasound data? I don't see it discussed in Jordan's paper.

Cade and I are feeding pretty clean seismic waveforms into ltsva and getting a large percentage of nan's out the other end. Spike detection may or may be the cause, but it caught my attention. The waveforms produce fine results out of obspy/array_processing, but we are interested in trying a least squares solver.

https://github.com/uafgeotools/lts_array/blob/5a52703a628e5c12d3945daf88dcad1b3b9f87f8/lts_array/classes/lts_classes.py#L910C1-L913C25

[davidfee5]

I think this was related to situations where "spikes" in the data occurring at the exact same time across multiple channels would produce a time delay of zero. I'd be surprised if this was your issue and imagine you could easily check by just commenting it out and trying again. I'd be happy to look at some example waveforms/etc to help you diagnose why are you getting nans.

[caquigley]

Attached is a summary document of the issues we've been having and the temporary fix we've been using for our data. The fix is related to removing some information in the spike detection part of the code. Below is the user inputs for the example.py for our dataset of interest. Let us know what you think.

Issues with lts_array spike detection.pdf
`# User Inputs

Filter limits [Hz]

FREQ_MIN = 2
FREQ_MAX = 4.0

Window length [sec]

WINDOW_LENGTH = 2

Window overlap decimal [0.0, 1.0)

WINDOW_OVERLAP = 0.5

LTS alpha parameter - subset size

ALPHA = 1 #Look at least squares example

Plot array coordinates

PLOT_ARRAY_COORDINATES = True

#####################################################

End User inputs

#####################################################

NET = '9C' #Arrays in the Aleutian islands, deployed in 2015-2016
STA = '2A*' #Look at single array
CHAN = 'SHZ'
LOC = '*'
START = UTCDateTime('2016-01-22T01:02:48')-60 #time of a M3.9 to SW of array
END = START + 120`

[davidfee5]

Sorry for the delay on this. I was able to reproduce your result and agree there is a problem here. My hunch is that the spike removal is being flagged since the time delays between relatively closely spaced seismic array elements is much less than we typically have for slower moving infrasound waves between infrasound array elements. Either way I think we should probably remove the spike detection as it was designed to remove a fairly rare problem in array elements that were all effected by an asynchronous data issue. @jwbishop do you agree? In the interim I think you can get reasonable results just by removing or commenting out those lines.

[mewest]

Thanks. That jibes with our hunch, at least. We have simply been using this with the spike detection commented out.

FYI - Our current investigation has been working to nail down some pretty basic array tunings for offshore subduction zone earthquakes. We have tested a few different approaches and are probably going to run with your LS/TLS code for our subsequent applications. It has been working nicely!