source width parameter?

[alexhutko]

Hi, I'm just inquiring the status of a source width parameter. I think it may have died a silent death in one of our insanely long email threads. Should we resurrect that, how would that be done:

-by deconvolving the source used for a particular model database and then convolving with a gaussian source of width N seconds? Or simply using the "greens_function" option?

-linear summation of X synthetics (model database source dependent) at a fixed time step that approximates an N sec wide source?

Thanks, Alex

[krischer]

That is related to this ticket here: krischer/instaseis#21

Can you please comment if/how that would work for you? Especially since the POST variant is already taken by the bulk requests.

I can implement this once it is deemed useful. A source_width parameter can then just be implemented by using that new functionality.

[krischer]

The functionality is also already in instaseis. See the reconvolve_stf argument: http://instaseis.net/instaseis.html#instaseis.base_instaseis_db.BaseInstaseisDB.get_seismograms

Now its just a matter of providing a nice interface and making sure all the little things like time shifts and what not are correct which unfortunately get tricky pretty fast.

[alexhutko]

Is there a way we can do this without using POST, which we don't currently have support for? I guess I'm confused why a simple source_width parameter isn't ideal. Syngine will likely have many low-level users who won't bother to supply anything beyond a source duration.

[alexhutko]

From instaseis page: reconvolve_stf (bool, optional) – Deconvolve the source time function used in the AxiSEM run and convolve with the STF attached to the source. For this to be stable, the new STF needs to bandlimited

Is it not trivial to simply reconvolve with the same AxiSEM stf, just a wider (parameterized) version, or a version that just adds a string of ones to the center of the guassian function to make it look like a smoothed trapezoid? Maybe I'm missing something, but I think that would naturally fit within instaseis. We've had many email threads on a sourcewidth parameter, but I've lost track of the arguments against it. The reconvolve_stf would still be useful for when we (eventually) get around to supporting the higher functionality of user supplied STFs.

thanks

[krischer]

Ah sorry..I missed your previous comment.

Is it not trivial to simply reconvolve with the same AxiSEM stf, just a wider (parameterized) version

It's not trivial but fairly simple. The main problem is making sure there are no boundary effects and the times are correct which is really nasty to get working for all the cases (absolute and relative times, phase relative times, ...). When doing this in Instaseis the user has to make sure everything is correct - for the server routes we have to be more careful.

From the side of Instaseis there is almost no additional effort to support the general version with arbitrary STF's - that is why I proposed it.

I'll implement krischer/instaseis#21 that next Thursday - I don't have time to do it before that. Once that is in place adding a simple parameterized STF is very easy to do.

It would still be great if you can figure out a way to have an arbitrary STF on the syngine service. The half duration parameter is widely used but I assume that is due to the popularity of the GCMT catalog. Other catalogs have other source time functions so people will want to use others. A possibility would be to have POST requests like the following:

model=prem_iso
sourcelatitude=-31.570
sourcelongitude=-71.654
sourcedepthinmeters=25000
sourcemomenttensor=1.95e28,-0.049e28,-1.9e28,0.531e28,-2.04e28,0.079e28
stf_units=moment_rate
stf_relative_origin_time_in_sec=15.23
stf_sample_spacing=0.1
stf_number_of_samples=1500
stf_data=0.2, 4, 25, 5, 2, 5, ...
IU COLA
II KURK
43.07 -89.38
47.6616 -122.3127 STACODE=DMC

[CTrabant]

Supporting arbitrary STF submission is still the plan. What you suggest here:

stf_units=moment_rate stf_relative_origin_time_in_sec=15.23 stf_sample_spacing=0.1 stf_number_of_samples=1500 stf_data=0.2, 4, 25, 5, 2, 5, ...

is exactly what I had in mind. Your suggested JSON is fine with me, but if we are going to let the user do the above to Syngine why not have Instaseis accept that also? Not too important, I can create whatever is needed for Instaseis.

I think the half duration is popular due to GCMTs but also because it is a simple, first-order summary of rupture duration. I'm not sure at what duration it becomes important and such a first-order summary would have value.

[sstaehler]

I think the half duration is popular due to GCMTs but also because it is a 
simple, first-order summary of rupture duration. I'm not sure at what 
duration it becomes important and such a first-order summary would have value.

In my experience, when looking at bodywaves, it becomes necessary very quickly, at durations of 5s or more (if we're looking at a 2s database), so for most events >5.8. Which means that it would be extremely helpful to have the half-duration implemented as a parameter.

[alexhutko]

If possible, can we please resurrect a simple sourcewidth parameter to remove and reconvolve with a same source shape but parameterized width within instaseis? Ideally this would be separate from the more-involved custom STF.

[krischer]

Will do. Internally it will just create a special STF and use the functionality of the custom STF but the user does not have to see this.

[manoch-iris]

The functionality was rolled in by installation of Instaseis 1.1.0 Custom Source Time Function (CSTF) — seismograms are convolved with a custom source time function