original template pick time and time after lag_calc is not same

[roshan-koirala]

The original pick time of a template is 2017-09-19T14:01:53.3703Z, and the pick time after lag_calc is 2017-09-19T14:01:53.008Z. I have prepick = 0.5. Ideally, my new pick should be 2017-09-19T14:01:53.008Z + 0.5 sec if I am not wrong. But this will not be the same as my original template time. What is causing this? Is this due to the shift_len in lag_calc ? I have shift_lenof 0.5. Thanks.

[calum-chamberlain]

This may be related to #500, although it is hard to know without knowing whether you are using the object oriented (e.g. using Party.lag_calc or Family.lag_calc methods) or the lag_calc function directly.

[roshan-koirala]

Thanks.

I first created event catalog, then constructed tribe, detected events using tribe.detect and finally did party.lag_calc as below.

event = Event(    origins=[Origin(
        latitude = origin.latitude, longitude=origin.longitude, depth=origin.depth,
        time = UTCDateTime(origin.time))], magnitudes=[Magnitude(mag= 1)],
        picks=[Pick(time= UTCDateTime(2017, 9, 19, 14, 1, 53, 4118), phase_hint = "P",
        waveform_id=WaveformStreamID( network_code="", station_code="BM09", channel_code="EHZ")), + 5 more picks ])

catalog = Catalog([event])

tribe = Tribe().construct(
    method="from_meta_file", meta_file=catalog, st=st.copy(), lowcut=10.0, highcut=100.0,
    samp_rate = 250, length=2, filt_order=4, prepick=0.5, swin='all',
    process_len=process_len, parallel=True, ignore_bad_data=True, clip=True)

party = tribe.detect(stream=st, threshold=7, daylong=True, threshold_type="MAD", 
                     trig_int=5.0, plot=False, return_stream=False, 
                     parallel_process=True, export_cccsums=True)

repicked_catalog = party.lag_calc(stm, pre_processed=False, shift_len=0.5, 
                                  min_cc=0.7, plot=True, plotdir=plt_dir)

I would highly appreciate further comments.

[calum-chamberlain]

Thanks for that. This is possibly related to #500 - In the interim while I get that bug fix out you can either edit your source code directly to match the change here, or use a longer shift-len of ~1s to see if that helps you get the same pick time.

I assume that the pick you mentioned in your initial comment is not the pick you provided in the code block given that they are at different times?

Another short comment - using a template of 2s and a prepick of 0.5s will only give you 1.5s of signal. At 250 Hz this is still a robust length of samples, but you might consider using a shorter prepick to reduce the noise in your templates that will affect your correlations.

[roshan-koirala]

Thanks a lot. Yes, this is a different trace here. Do you think 0.2 sec is a good prepick ? I will try the solutions you recommended. Best,

[calum-chamberlain]

I haven't done extensive testing of varying prepick, but I would usually go with a prepick that is at least twice your pick uncertainty. 0.2s might be a good value. You might want to test a few different prepicks and see what gives you the best results for your dataset.

You might also want to reduce the trig_int in detect - with such short templates you should be able to robustly redetect more frequently (at least every 2s).

[calum-chamberlain]

Closed by #500