iris-edu / irisws-syngine Goto Github PK

View Code? Open in Web Editor NEW

2.0 12.0 0.0 124 KB

Project components for the IRIS Synthetics Engine (irisws-syngine) web service

License: GNU General Public License v2.0

irisws-syngine's People

Stargazers

Watchers

irisws-syngine's Issues

Multi-Segment FFMs do not work

This is for the beta service. Multi-segment FFMs to not work. The following simplified payload reproduces the problem. Note that removing the second segment causes it to work.

IU ANMO
dt=0.1
origintime=1970-01-01T00:00:00.000000Z
components=Z
format=miniseed
model=ak135f_5s
units=velocity
STARTUSGSFFM
#Total number of fault_segments=     2
#Fault_segment =   1 nx(Along-strike)=  2 Dx= 12.00km ny(downdip)=   2 Dy= 10.00km
#Boundary of Fault_segment     1. EQ in cell 12,4. Lon: -70.8634   Lat: -19.6298
#Lon.  Lat.  Depth
      -70.87280      -20.88790       17.21850
      -71.38010      -18.81860       17.21850
      -71.04820      -18.74640       25.77820
      -70.54090      -20.81580       25.77820
      -70.87280      -20.88790       17.21850
#Lat. Lon. depth slip rake strike dip t_rup t_ris t_fal mo
     -20.887900     -70.872800      17.218500      14.849220      79.422050     347.000000      13.500000      94.000000      25.200000       3.600000   1.203394e+25
     -20.782700     -70.898600      17.218500      14.312710      93.683830     347.000000      13.500000      91.600000      10.800000      14.400000   1.159915e+25
     -20.677500     -70.924400      17.218500     124.392900     135.544100     347.000000      13.500000      94.400000      10.800000       7.200000   1.008091e+26
     -20.572300     -70.950200      17.218500     164.064610     133.572910     347.000000      13.500000      95.800000      10.800000       3.600000   1.329595e+26
#Fault_segment =   2 nx(Along-strike)=  2 Dx= 12.00km ny(downdip)=   2 Dy= 10.00km
#Boundary of Fault_segment     1. EQ in cell 12,4. Lon: -70.8634   Lat: -19.6298
#Lon.  Lat.  Depth
      -70.87280      -20.88790       17.21850
      -71.38010      -18.81860       17.21850
      -71.04820      -18.74640       25.77820
      -70.54090      -20.81580       25.77820
      -70.87280      -20.88790       17.21850
#Lat. Lon. depth slip rake strike dip t_rup t_ris t_fal mo
     -20.887900     -70.872800      17.218500      14.849220      79.422050     347.000000      13.500000      94.000000      25.200000       3.600000   1.203394e+25
     -20.782700     -70.898600      17.218500      14.312710      93.683830     347.000000      13.500000      91.600000      10.800000      14.400000   1.159915e+25
     -20.677500     -70.924400      17.218500     124.392900     135.544100     347.000000      13.500000      94.400000      10.800000       7.200000   1.008091e+26
     -20.572300     -70.950200      17.218500     164.064610     133.572910     347.000000      13.500000      95.800000      10.800000       3.600000   1.329595e+26
ENDUSGSFFM

Less accurate error message

Something changed server side and the error message when requesting invalid components changed from a specific and helpful one to a generic and less useful one.

Example request:

http://service.iris.edu/irisws/syngine/1/query?eventid=GCMT%3AC201002270634A&network=IU&format=miniseed&station=ANMO&components=ABC&model=ak135f_5s

Now returns:

Error 400:   handler exited, no error message from handler

More Details:
handler exited, code: 3  reason: Bad Request

Request:
http://service.iris.edu/irisws/syngine/1/query?eventid=GCMT%3AC201002270634A&network=IU&format=miniseed&station=ANMO&components=ABC&model=ak135f_5s

Request Submitted:
2016/05/24 17:26:58 UTC

Service version:
Service: irisws-syngine  version: 1.0.1

It used to have an error message containing the words "Unrecognized component" which IMHO is much more useful especially for routes that have a ton of parameters.

I just know this because ObsPy has a now failing test for this.

Content-Disposition HTTP Header

In the case of zipped SAC files I think it is better to name it *.zip instead of *.saczip. Then double clicking on it should automatically unzip it on most platforms.

Relative start and/or end times stopped working

Dear all,

its seems relative start and/or end times stopped working.

This is an example from the syngine page and it returns a code of 204:

http://service.iris.edu/irisws/syngine/1/query?network=_GSN&components=Z&eventid=GCMT:M110302J&starttime=P-10&endtime=ScS%2B60&format=saczip

networkcode argument

What is the motivation for offering a stationcode parameter but not a networkcode parameter? I guess you want to make clear that one is downloading synthetics?

In practice station codes are not unique so one also needs to set the network codes. The workflows of some people (and me) I've seen store the synthetics in a separate folder but give full ids which makes it easier to match it with actual data. Thus giving the option to also set the network code makes sense from my point of view.

syngine feature freeze

Hi all,
We'd like to have a feature freeze by the end of htis week. Are there any features being developed/modified at this point?

thanks,
Alex

Use model-specific travel times for phase-relative start and end times

Currently the travel times used for calculating phase-relative start and end times are all using an iasp91 model. This should be model specific. @krischer will work out the changes needed in Instaseis to have the internal use of the callback for travel times be model-specific.

Convolution issue in the SAC tutorial

The SAC tutorial (http://ds.iris.edu/ds/products/syngine) convolves with a triangular source time function. There are two(three) issue with the current approach:

A triangle is not bandlimited and will thus introduce frequencies into the seismogram that have not been simulated. The effect is likely not that big in many cases but as this is the tutorial on the official syngine page it should be correct as many people will just copy-paste. Better to use some gaussian that approximates a triangle.
You will also have to deconvolve the existing source time function of the database otherwise you end up with both being convolved at the same time. As this is not a stable operation you will have to "reconvolve", e.g. deconvolve with the database STF and convolve with a new one at the same time.
I am not fully sure how the convolution is implemented in SAC but their documentation seems to say that convolution does not correct for any time shift. In that case it will introduce a time shift on the synthetics of half the length of the triangle. You would have to correct for that if my interpretation of SAC's doc is correct.

I think a tutorial on the syngine page should be as correct as possible as many people will probably assume just that.

Include models with ocean layer

As agreed at AGU, @tnissen will track the development of the models.

bug of attenuation in 1D models

In the 1D PREM model (http://ds.iris.edu/media/product/emc-syngine/files/1dmodel_PREMiso.txt) given by syngine, the Qp from the surface to the ICB has a constant value 57827.0, which is quite different from the 1D model given by TauP.

Parameters from syngine:

# Input file for AXISEM created from prem_iso model on 08/12/2015, at 12h 11min
NAME         prem_iso
ANELASTIC       T
ANISOTROPIC     F
UNITS        m
COLUMNS       radius      rho      vpv      vsv      qka      qmu
            6371000.  2600.00  5800.00  3200.00    57827.0      600.0
            6356000.  2600.00  5800.00  3200.00    57827.0      600.0
#          Discontinuity   1, depth:      15.00 km
            6356000.  2900.00  6800.00  3900.00    57827.0      600.0
            6346600.  2900.00  6800.00  3900.00    57827.0      600.0
#          Discontinuity   2, depth:      24.40 km
            6346600.  3380.75  8110.62  4491.01    57827.0      600.0
            6341600.  3380.20  8107.53  4489.16    57827.0      600.0
            6336600.  3379.66  8104.44  4487.32    57827.0      600.0
            6331600.  3379.12  8101.35  4485.48    57827.0      600.0
            6326600.  3378.57  8098.25  4483.64    57827.0      600.0
            6321600.  3378.03  8095.16  4481.79    57827.0      600.0
            6316600.  3377.49  8092.07  4479.95    57827.0      600.0
            6311600.  3376.94  8088.98  4478.11    57827.0      600.0
            6306600.  3376.40  8085.89  4476.26    57827.0      600.0
            6301600.  3375.86  8082.80  4474.42    57827.0      600.0
            6296600.  3375.31  8079.71  4472.58    57827.0      600.0
            6291600.  3374.77  8076.62  4470.74    57827.0      600.0
            6291000.  3374.71  8076.25  4470.52    57827.0      600.0

Parameters from TauP:

    0.00     5.80000   3.20000   2.60000    1456.0     600.0
   15.00     5.80000   3.20000   2.60000    1456.0     600.0
   15.00     6.80000   3.90000   2.90000    1350.0     600.0
   24.40     6.80000   3.90000   2.90000    1350.0     600.0
mantle
   24.40     8.11061   4.49094   3.38076    1446.0     600.0
   40.00     8.10119   4.48486   3.37906    1446.0     600.0
   60.00     8.08907   4.47715   3.37688    1447.0     600.0
   80.00     8.07688   4.46953   3.37471     195.0      80.0
  115.00     8.05540   4.45643   3.37091     195.0      80.0
  150.00     8.03370   4.44361   3.36710     195.0      80.0
  185.00     8.01180   4.43108   3.36330     195.0      80.0
  220.00     7.98970   4.41885   3.35950     195.0      80.0
  220.00     8.55896   4.64391   3.43578     362.0     143.0
  265.00     8.64552   4.67540   3.46264     365.0     143.0
  310.00     8.73209   4.70690   3.48951     367.0     143.0
  355.00     8.81867   4.73840   3.51639     370.0     143.0

The same thing happens to all other models 1dmodel_PREMani.txt, 1dmodel_PREM_ocean.txt, 1dmodel_iasp91.txt except the ak135f model 1dmodel_ak135f.txt.

Headers of /info route are off

e.g. http://service.iris.edu/irisws/syngine/1/info?model=ak135f

Content type is application/vnd.sac+zip
Content-Disposition is inline; filename=irisws-syngine_2015-10-01T14:56:25.saczip

Wrong unit for the eventid queries

The eventid queries don't convert the moment tensor components from dyne*cm to Nm. Thus the amplitudes are way off when using the eventid parameter. Just multiply with 1E-7 to fix that issue.

# Query.
obspy.read("http://service.iris.edu/irisws/syngine/1/query?"
           "network=IU&station=ANMO&components=Z&format=miniseed"
           "&eventid=GCMT:C201511181831A").plot()

# Reconstruction.
obspy.read("http://service.iris.edu/irisws/syngine/1/query?"
           "network=IU&station=ANMO&components=Z&format=miniseed&"
           "sourcelatitude=-9.1&sourcelongitude=158.490&sourcedepthinmeters=19000&"
           "sourcemomenttensor=1.360e26,-0.439e26,-0.923e26,0.142e26,-1.670e26,1.040e26").plot()

# What it should be.
obspy.read("http://service.iris.edu/irisws/syngine/1/query?"
           "network=IU&station=ANMO&components=Z&format=miniseed&"
           "sourcelatitude=-9.1&sourcelongitude=158.490&sourcedepthinmeters=19000&"
           "sourcemomenttensor=1.360e19,-0.439e19,-0.923e19,0.142e19,-1.670e19,1.040e19").plot()

Make 'greensfunctions' parameter functional

This option requires plumbing to backend Instaseis servers.

source width parameter?

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

Enable phase-relative start and end times

Advanced configuration of the Instaseis backends required.

Bug report: wrong head parameter in sac file

if url is http://service.iris.edu/irisws/syngine/1/query?origintime=2017-04-15T06:30:00.000\&sourcelatitude=0\&sourcelongitude=100\&sourcedepthinmeters=20000\&sourcemomenttensor=1.04e22,-0.039e22,-1e22,0.304e22,-1.52,-0.119e22\&receiverlatitude=0\&components=ZRT\&format=saczip\&model=prem_i_2s\&units=velocity\&receiverlongitude=105
, the head parameter of dist should be about 556.599. But, the fact is 20004.3

Set a smaller default dt

We mentioned this before but I think this is really important so I'll bring it up once again here.

Please consider setting the default dt to a smaller value to avoid errors that will likely not get noticed by users.

The current version of the syngine service by default returns seismograms with the sampling rate of the database. That sampling rate is naturally as low as possible to save disc space. If people request velocity seismograms everything is good. When people request either displacement or acceleration we have to either numerically integrate or differentiate. These operations are not accurate and perform at their worst for frequencies close to Nyquist.

Thus significant errors are introduced if people just requests seismograms (in displacement/acceleration) without manually specifying a smaller dt. For small dt values Instaseis internally will resample before it performs the differentiation/integration thus avoiding this problem.

Only very few people will be aware of that and to avoid people requesting bad seismograms I propose to set the default dt to a tenth of the database sampling interval. The data is then effectively oversampled by a factor of 10 which puts more load on IRIS's connection but the error is no longer an issue.

In the following plot the green and dashed black line should be identical but they are not. The reason for the difference is that the differentiation acts as a strong lowpass filter.

See here for a more detailed explanation: http://nbviewer.ipython.org/gist/krischer/a0260437b675ba2c1993

Some invalid lines in POST request are silently ignored

The following POST payload return synthetics from three stations:

model=test
format=saczip
eventid=GCMT:C201002270634A
IU ANMO
14 15
IU ASDF LOCCODE=00
12 13

The third station line (which I realize is not valid) is silently ignored. I think it should at least show up in the produced log file. The current log file is:

RECEIVER lat:13.909930, lon:15, netcode:XX, stacode:S0001, STATUS OK
RECEIVER lat:11.921974, lon:13, netcode:XX, stacode:S0002, STATUS OK
RECEIVER lat:34.765424, lon:-106.4572, netcode:IU, stacode:ANMO, STATUS OK

remove_source_shift in finite_source route?

Hi Lion,

Is remove_source_shift not defaulted to true in the finite_source route? These are AU.KMBL FFM synthetics for the Nepal event.

Thanks.

Code 204 returned for invalid dt settings

Valid request:

http://service.iris.edu/irisws/syngine/1/query?model=prem_i_2s&sourcelatitude=26.039501154301607&sourcelongitude=-117.77516820835515&sourcedepthinmeters=376814.17904499&receiverlatitude=-34.483622476558644&receiverlongitude=152.0504668589753&components=ZNE&format=miniseed&dt=0.1

The following two should return with an error code and a descriptive message.

dt too high (returns 204):

dt too low (returns 204):

You could just forward the errors from the Instaseis Server:

HTTP 400: Cannot downsample. The sampling interval of the database is 4.99736 seconds. Make sure to choose a smaller or equal one.

and

HTTP 400: The smallest possible dt is 0.01. Please choose a smaller value and resample locally if needed.

Forwarding Custom Header Field?

Hi guys,

would you consider forwarding a custom header field from the instaseis server? It is only about the Instaseis-Mu header - it is currently not set by the /seismograms route but only by the /seisomograms_raw route. If you agree to forward it I will add it to the /seismograms route for requests where it makes sense.

This might be useful for people who want to use syngine for their own finite sources (not the USGS param files). This is a very niche use case but something to maybe think about.

CMPINC and CMPAZ?

Can you add CMPINC and CMPAZ to the SAC headers of synthetics? They'd be extremely useful for (at least my) subsequent processing; at the moment I'm adding manually, but it seems like it should be fairly easy to add them on the front end...

phase relative times sometimes returns an error and sometimes fails silently

Just observed this behavior for phase relative queries with phase that don't match the distance. Should this always return an error? It seems the silent one returns an invalid file, at least obspy refuses to read it.

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import obspy

from obspy.clients.syngine import Client

c = Client()

# Fails silently for second receiver:
bulk = [[0.0, 20.0], [0.0, 110.0]]

st = c.get_waveforms_bulk(
        model="ak135f_2s", bulk=bulk, sourcelatitude=0.0,
        sourcelongitude=0.0, sourcedepthinmeters=600000,
        starttime="P-50",
        endtime="S+100",
        components="Z")

print st

# Fails with an error for first receiver:
bulk = [[0.0, 10.0], [0.0, 20.0]]

st = c.get_waveforms_bulk(
        model="ak135f_2s", bulk=bulk, sourcelatitude=0.0,
        sourcelongitude=0.0, sourcedepthinmeters=600000,
        starttime="P-50",
        endtime="S+100",
        components="Z")

print st

Error for first query:
python2.7/site-packages/obspy/io/mseed/core.py:384: InternalMSEEDReadingWarning: readMSEEDBuffer(): Record starting at offset 16384 is not valid SEED. The rest of the file will not be read.

Error for second query:
Error 400: RECEIVER lat:0.000000, lon:10.0, netcode:XX, stacode:S0001, STATUS: Instaseis Error [400]: No seismograms found for the given phase relative offsets. This could either be due to the chosen phase not existing for the specific source-receiver geometry or arriving too late/with too large offsets if the database is not long enough.

Receiver station code required when specified as coordinates

There has been a change in your middleware that makes the station code required when passing receiver coordinates. This makes it more cumbersome to use when just wanting to request seismograms for various epicentral distances for example to gain a visual understanding of something.

I think the default SYN code is a good enough hint for users. Even the source mechanism has a default value so I think the station code should definitely have one. What is the motivation behind this change?

Example query:

http://service.iris.edu/irisws/syngine/1/query?starttime=1969-12-31T23%3A57%3A06.926082Z&dt=24.724845445855724&sourcelongitude=3.0&format=miniseed&receiverlatitude=10.066021190034876&origintime=1970-01-01T00%3A00%3A00.000000Z&components=ZNERT&model=test&sourcelatitude=4.026869595871933&sourcemomenttensor=4.71e%2B17%2C3.81e%2B17%2C-4.74e%2B17%2C3.99e%2B17%2C-8.05e%2B17%2C-1.23e%2B17&receiverlongitude=20.0&sourcedepthinmeters=0.0&units=displacement

Status of database computations

Just to keep you updated:

AK135f 1s period, 1800 s duration, vertical only
AK135f 2s period, 3600 s duration
prem_iso 2s period, 3600 s duration
PREM continential crust 2s period, 3600 s duration
PREM oceanic crust 2s period, 3600 s duration
PREM 5s, 3600 s duration for the FFM service
PREM 10 s resolution, 18000 s duration for large earthquake coda studies

Internal Server Error with fuzzed POST request

The following POST payload causes an internal server error with HTTP status code 500. I realize its not a valid request but that should raise another error.

model=test
format=saczip
eventid=GCMT:C201002270634A
IU ANMO LOCCODE=00
random things
help

Final Set of 1D Models

Current Set:

prem_ani    20-100  4.87    1797    vertical and horizontal     20s_PREM_ANI_FORCES for testing only    0.6 GB  (link)
ak135f      2-100   0.487   3700    vertical and horizontal         1.0 TB  (link)
iasp91      2-100   0.483   3700    vertical and horizontal         1.3 TB  (link)
prem_iso    2-100   0.488   3700    vertical and horizontal     isotropic   1.1 TB  (link)

prem_iso and ak135f are buggy and need to be replaced.

Current wishlist as we understand:

PREM continential crust 2s period, 3600 s duration
PREM oceanic crust 2s period, 3600 s duration
PREM 5s and 10 s resolution, 3600 s duration for the FFM service
AK135 & IASP91 2s period, 3600 s duration

We kind of lost track the models you want. Can you please comment and we try to make it happen until AGU. We'll just bring along one or more hard discs.

Maximum depth of databases?

@CTrabant Testing the 5s database (for Finite-Fault solutions) against the deep Okhotsk earthquake, I noticed that its fault plane has a maximum depth of 720 km.
http://earthquake.usgs.gov/earthquakes/eventpage/usb000h4jh#scientific_finitefault

So far, I assumed that 700 km maximum depth would be enough. Shall I increase that to 750 km for all models? This event is unique with respect to depth and magnitude, but it may not be the last one.

Gzip encoding for /info route

Most of the space is needed for the zeros in the /info route. gzipping it compresses it down to almost nothing so its worth considering it here. The Instaseis server can do it so you could just forward it but I guess you have your own middleware to do that as well.

make syngine default = isotropic explosive source?

Hi,

Right now instaseis requires a source input. We think for syngine it might be good to have a default source for users who just want some wiggles and don't care about the moment tensor. Yes, real seismologists can put in a source themselves, but maybe not undergraduate students.

Thoughts? Is there something I'm not considering?

I'd propose something like a M6.5ish isotropic point-source:
Mrr=1e19
Mtt=1e19
Mpp=1e19
Mrt=Mtp=Mrp = 0

Thanks,
Alex

Is there a way to query for the available models?

I could only find the list here: http://ds.iris.edu/ds/products/syngine/#models

Silent wildcards if network or station codes are not given

I am not sure if this is intentional and from my point of view this is rather dangerous in the sense that it might result in lots of unintentional downloads. The following request for example will download the full IU network:

http://service.iris.edu/irisws/syngine/1/query?model=ak135f_5s&eventid=GCMT%3AC201002270634A&network=IU

Small error in the POST request documentation

It currently is written as

parameter=value
parameter=value
...
latitude longitude STACODE=<SYN> [NETCODE=XX] [LOCCODE=SE]
netcode stacode
...

The station code is also optional as I discovered from testing.

ObsPy Tutorial?

There is a small SAC tutorial here: http://ds.iris.edu/ds/products/syngine/

Would you consider also adding an ObsPy version of the same thing if I provide it?

Replicate the error message inte HTTP header status message

This would be useful to programmatically forward the error message. Right now one has to parse the body of the response. Or am I missing something?

Add tiny test database?

Hi guys,

would it possible to add the same test database we internally use for Instaseis to the syngine service? It could well be hidden to the normal user. It's only 4 MB large and the only purpose it serves is to internally test Instaseis. I'm writing a syngine client for Instaseis and this would make it trivial to test it. As a bonus it would test parts of the syngine service.

DB: https://github.com/krischer/instaseis/tree/master/instaseis/tests/data/100s_db_bwd_displ_only

Thanks!

Lion

1d reference models used

@sstaehler Can you help us with simple text files of the reference models used for the current model catalog? thx

http://ds.iris.edu/ds/products/syngine/#models

Long custom STFs don't seem to work

Long custom STFs do appear to have some kind of problem with the beta service. I realize that this is mostly zeros but this just originated from my workflow and would of course be possible to have actual values there. The same request works with a shorter STF so maybe it is some kind of URL length limit?

For this one syngine just closes the connection without an error message.

problem with durations?

Hi,

I found that syngine's maximum allowable duration of seismograms is = dt * (npts - (3*source_shift) + 1). This means though we advertise 17999.6 s, we can only serve up traces that are 17953 s or less using the default settings.

Are there any objections to us changing the advertised database durations to reflect the effective duration? Perhaps I should first ask if this should only be a syngine issue rather than instaseis.

Thanks,
Alex

PS: why 3xsource_shift and not 2x?

InstaseisDB reciprocal Green's function Database (v8) generated with these parameters:
components : vertical and horizontal
velocity model : prem_ani
attenuation : True
dominant period : 10.000 s
dump type : displ_only
excitation type : dipole
time step : 2.441 s
sampling rate : 0.410 Hz
number of samples : 7376
seismogram length : 17999.6 s
source time function : gauss_0
source shift : 17.084 s
spatial order : 4
min/max radius : 5671.0 - 6371.0 km
Planet radius : 6371.0 km
min/max distance : 0.0 - 180.0 deg
time stepping scheme : symplec4
compiler/user : gfortran 5.2.0 by productext on dpstage
directory/url : ../../axisem/MODELS/prem_a_10s
size of netCDF files : 69.4 GB
generated by AxiSEM version v1.2-31-g69d4-dirty at 2015-11-12T09:36:02.000000Z

iris-edu / irisws-syngine Goto Github PK

irisws-syngine's People

Stargazers

Watchers

irisws-syngine's Issues

Recommend Projects

Recommend Topics

Recommend Org