ObsPy at AGU 2019

Hi all,

I'll be at AGU and there will be a lightning talk in an Open Source
software session (NS21A) on Tuesday morning:
https://agu.confex.com/agu/fm19/meetingapp.cgi/Paper/577013

Also following this oral session there are a few posters from this
session (NS21B) so we'll be gathering there and you can get in touch
with me there on Tuesday around 10am to noon:
https://agu.confex.com/agu/fm19/meetingapp.cgi/Session/78079

We'll also organize an informal gathering for food/drinks in the evening
on one day. It's not yet fixed when, but it'll be posted on our Twitter
and (hopefully I'll remember) also here.

https://twitter.com/obspy

Also you can send a direct message on Twitter if you wanna get in touch
during AGU.

cheers,
Tobias

Hi all,

just a reminder/follow-up: You can meet me at the end of the oral
session NS21A today at around 10am, or after that at the accompanying
poster session NS21B around 10-12am.

In the evening you can join us for drinks/dinner, let's meet at 6:15pm
at the poster pickup booth in Moscone South (when you walk in from the
street at the left side of the entrance hall).
If you wanna, please drop me a private email so that we know whom to
wait for and maybe I can plan ahead and reserve some table.

best,
Tobias

I think this is a simple question, but just want to make sure I am correctly applying instrument response, and correctly understanding how traces work in ObsPy, in the attached code.

The code has two traces, from two different networks (AM and NE), and for each I used "attach_response=True”.

My question is:

Am I right that the instrument response will be applied to the individual traces correctly, in the sense that it will know which response is associated with which trace, even though it’s all done on one line of code:

tr.remove_response(output=‘VEL’, pre_filt=pre_filt)

It seems like the answer is “yes”, in principle, and the results are the same as when I tried it for just one trace at a time, but just wanted to make sure I have this right.

Thanks,

Plot_2_Traces.ipynb (166 KB)

Without looking at your code, yes, ObsPy is selecting the appropriate
response information for each Trace in a Stream.

In general, nowadays we discourage using "attach_response" helper kwargs
and methods. They do properly look up the correct response for each
trace, but there can be some (rather unlikely) scenarios in which a
lingering attached response might not be appropriate for a trace anymore
at later times. So, in general, we encourage fetching the station
metadata into an Inventory object and using that whenever station
metadata is needed, right on the spot, e.g.

st = client.get_waveforms(...)
inv = client.get_stations(..., level=response)
# lots of other code potentially, merging traces, rotating to ZNE, etc
st.remove_response(inventory=inv, ...)

best,
Tobias

Thanks, Tobias. This is very helpful.

I experimented with doing it both ways, and got the same result. But, for now on I will do it using the "inv = client.get_stations(…, level=response)” method.

~ Alan

Hi,

I’m running SeismoSocialDistancing.ipynb, and I’m getting this warning message:

C:\Users\Observatory\anaconda3\envs\obspy\lib\site-packages\obspy\signal\spectral_estimation.py:2096: MatplotlibDeprecationWarning:
The set_clim function was deprecated in Matplotlib 3.1 and will be removed in 3.3. Use ScalarMappable.set_clim instead.
  cb.set_clim(*fig.ppsd.color_limits)

(The program still runs fine, and the output looks right to me.)

Any suggestions?

Thanks,

~ Alan Kafka

Hi Alan,

thanks for letting us know, we'll have to adapt obspy code to this API
change, I made a ticket:
https://github.com/obspy/obspy/issues/2652

cheers,
Tobias