time shift related issues

[aakash10gupta]

It seems that recsec reads the time shift from CMTSOLUTION files and automatically applies that on synthetics.

• For synthetic synthetic comparisons, this time shift does not seem to be applied. Consistency can be useful here.

• If the CMSOLUTION is for a finite fault, there will be time shift values corresponding to each of the point source descriptions within the CMTSOLUTION file. Just wondering which value recsec takes as the time shift in this case. Probably best to not apply any automatic time shift based on the CMTSOLUTION file in this case.

[bch0w]

Adding to this, using the test data, synsyn introduces a time shift that is not seen when plotting data syn. Potential bug for determining what start time is.

Syn-Syn plotting

recsec --pysep_path ./test_synthetics --syn_path ./test_synthetics --source test_CMTSOLUTION_2014p715167 --stations test_STATIONS --synsyn --scale_by normalize

Obs-Syn

recsec --pysep_path ./test_SAC --syn_path ./test_synthetics --source test_CMTSOLUTION_2014p715167 --stations test_STATIONS --scale_by normalize

[bch0w]

@aakash10gupta

If the CMSOLUTION is for a finite fault, there will be time shift values corresponding to each of the point source descriptions within the CMTSOLUTION file. Just wondering which value recsec takes as the time shift in this case. Probably best to not apply any automatic time shift based on the CMTSOLUTION file in this case.

Time shift is not considered from the CMTSOLUTION file, only the origin time which is built from the first line of the file. https://github.com/adjtomo/pysep/blob/devel/pysep/utils/io.py#L208-L212

Time shift is also taken from the first timestamp in the ASCII file, if USER_T0 was specified for the simulation https://github.com/adjtomo/pysep/blob/devel/pysep/utils/io.py#L122-L123

Do you foresee an issue with timing if the user has used the time_shift parameter in the CMTSOLUTION? I have not used that before so I'm not immediately aware how that might shift things relative to the origin time.

[bch0w]

For synthetic synthetic comparisons, this time shift does not seem to be applied. Consistency can be useful here.

Not sure if I'm understanding the issue correctly but this seems to be intended behavior based on the trim function (#157). As in once you plot data-synthetics, the data do not have the same time shift (USER_T0) applied so RecSec trims to the origin time. When two synthetics are plotted, they both have the same time shift and so that will be shown on the record section.

Let me know if I got that wrong, at the moment what I showed above looks like expected behavior to me.

[aakash10gupta]

@thurinj, @carltape, do you have an example finite fault CMTSOLUTION file that you can share here for testing purposes?

[bch0w]

@aakash10gupta

I realized what was going wrong with the first point. When reading a CMTSOLUTION file, PySEP uses the ObsPy read_events function (https://github.com/adjtomo/pysep/blob/devel/pysep/utils/io.py#L181-L184) which automatically applies the CMTSOLUTION's time_shift parameter to the origin time of the event, so the Stream's origin time does not match the one listed at the top of the CMTSOLUTION anymore.

e.g., below I put in a time_shift of 20s and it shows up in the origin time.

In [4]: cat = read_events("test_CMTSOLUTION_2014p715167_timeshifted")

In [5]: cat
Out[5]:
1 Event(s) in Catalog:
2014-09-22T14:41:42.940000Z | -40.541, +175.932 | 5.43 mw

In [6]: cat2 = read_events("test_CMTSOLUTION_2014p715167")

In [7]: cat2
Out[7]:
1 Event(s) in Catalog:
2014-09-22T14:41:22.940000Z | -40.541, +175.932 | 5.43 mw

This is present in data-synthetic comparisons because the two traces now have different origin times. But, it does not show up in the synthetic-synthetic comparison because they both experience the same time shift.

From our conversation, this seems like intended behavior? Because the time shifted origin time now represents the centroid time. Let me know if I got that wrong.

[aakash10gupta]

That is the intended behavior for data-synthetic comparisons, but for synthetic-synthetic comparisons when both sets have different origin times this does not seem to be the case. I'm guessing Pysep presently assumes the same event and event files for both synthetics and that is a reasonable assumption to have. I came across this because I want to shift a set of synthetics with respect to the other and didn't find a parameter to do that. So I was using the origin times in the two CMTSOLUTION files to do that not realizing that Pysep probably reads only one of them for synthetic-synthetic comparisons. I think the feature request #159 will solve the issue.

[aakash10gupta]

Attached is a test CMTSOLUTION file for a finite fault. Remove the .txt extension before using it.

CMTSOLUTION.txt