iris-edu / irisws-syngine Goto Github PK
View Code? Open in Web Editor NEWProject components for the IRIS Synthetics Engine (irisws-syngine) web service
License: GNU General Public License v2.0
Project components for the IRIS Synthetics Engine (irisws-syngine) web service
License: GNU General Public License v2.0
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.
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
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.
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
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
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.
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:
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.
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:
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...
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
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:
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
Valid request:
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.
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.
@sstaehler Can you help us with simple text files of the reference models used for the current model catalog? thx
e.g. http://service.iris.edu/irisws/syngine/1/info?model=ak135f
application/vnd.sac+zip
inline; filename=irisws-syngine_2015-10-01T14:56:25.saczip
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.
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.
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()
This option requires plumbing to backend Instaseis servers.
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?
Just to keep you updated:
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.
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
I could only find the list here: http://ds.iris.edu/ds/products/syngine/#models
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:
I think a tutorial on the syngine page should be as correct as possible as many people will probably assume just that.
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
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
Advanced configuration of the Instaseis backends required.
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?
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.
As agreed at AGU, @tnissen will track the development of the models.
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
@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.
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
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:
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.
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:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.