Discussion: individual channel thresholds / weighted cross-correlations

[calum-chamberlain]

This issue follows from #159. We have now sped-up find-peaks, but @yifanyin also wanted to explore the possibility of using single-channel thresholds along-side the summed-threshold. I'm not sure how best to play around with this, there are a couple of avenues we could take as I see it:

1. Return individual channel cross-correlations from eqcorrscan.utils.correlate and threshold based on those with some kind of requirement that at least n channels trigger (could use standard sta/lta type network routines).
   • Note that this will increase memory usage in some cases (in particular, this would not be able to use the optimized C-routines that return summed cross-correlations), and it would be difficult
2. Return both cross-correlation sums and the individual channels and detect based on the cross-correlation sum, but reject detentions if the individual cross-correlations do not meet some criteria.
   • Note: I think this would be better as a post-processing step, using lag-calc, which is what I do already, its more memory efficient, and allows you to have weak and strong detections.
3. Allow weighting of the cross-correlations before they are summed in a similar way to FastMatchedFilter. This is entirely possible, and weights could be contained as an element in Template objects, if we did this, templates from previous generations could just be assigned equal weights when read in.

@yifanyin - anything you want to add, or do any of those sound good to you? Point 2 can be done as is as a post-processing step - lag-calc returns events with picks, for which each pick has a correlation value. i am loath to implement point 1, it seems really hard, but could be done. Point 3 is something I am thinking about doing though...

[yifanyin]

Aha, sorry for the late reply. I feel the same way with point one. It's just too exhausted to do simultaneously within the cross-correlation. I did wire a primitive post-process to recalculate the single-channel-xcorr values. This is mainly used to demonstrate my detections and also to compare the detections with the manual picking standards. Weighted sum sounds good to me. Due to the fact that I cut P- and S-waveforms separately on Z and E+N, P naturally got down-weighted.

[calum-chamberlain]

Cool, do you want me to think about implementing weighting then?

I don't think it would be especially hard, but would involve updating the Template objects, and changing the correlation routines (both in C and Python wrappers). And I probably wouldn't get around to it until February-ish. Note to self, I don't think this would affect the lag-calc correlation checking if I enforce a maximum weight of one (so only down-weighting is allowed)...

If you want, I can share a way to wrap the FastMatchedFilter correlation routines for EQcorrscan in a gist and you can apply weights in there (maybe some automated thing for your templates so that channels N and E are given half weight and Z full weight?). However, it is worth noting that they do normalisation differently to EQcorrscan so there are some differences in correlation results. But also, if you have access to GPU's, then their routines are considerably faster than EQcorrscan's fastest correlation routines...

[calum-chamberlain]

Closing due to inactivity - adding weighting to EQcorrscan is still an option. The inner correlation functions can now (thanks to #266) return individual channel correlations, so thresholding on individual channels would also be possible.