# ObsPy at AGU 2019

**URL:** <https://discourse.obspy.org/t/obspy-at-agu-2019/859>\
**Category:** Users Mailing List Archive\
**Tags:** archive\
**Created:** [December 3, 2019, 1:28pm UTC](https://discourse.obspy.org/t/obspy-at-agu-2019/859 "2019-12-03T13:28:38Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![megies](https://discourse.obspy.org/user_avatar/discourse.obspy.org/megies/32/9_2.png) [@megies](https://discourse.obspy.org/u/megies)\
**Post date:** [December 3, 2019, 1:28pm UTC](https://discourse.obspy.org/t/obspy-at-agu-2019/859/1 "2019-12-03T13:28:38Z")

</div>

Hi all,

I'll be at AGU and there will be a lightning talk in an Open Source  
software session (NS21A) on Tuesday morning:

> **[ObsPy -- A Python Library for Seismology](https://agu.confex.com/agu/fm19/meetingapp.cgi/Paper/577013)**
>
> Recent years established Python and its (data)scientific ecosystem as one of th...

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:

> **[A Tour of Open-Source Software Packages for the Geosciences II Posters](https://agu.confex.com/agu/fm19/meetingapp.cgi/Session/78079)**
>
> This session will be a rapid-fire tour (5 min) of open source tools freely available for researchers in the geosciences. The fast-growing open source software ecosystem is creating new tools and changing paradigms for how computers and collaborations...

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](https://twitter.com/obspy)

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

cheers,  
Tobias

---

<div class="post-metadata">

**Author:** ![megies](https://discourse.obspy.org/user_avatar/discourse.obspy.org/megies/32/9_2.png) [@megies](https://discourse.obspy.org/u/megies)\
**Post date:** [December 10, 2019, 2:30pm UTC](https://discourse.obspy.org/t/obspy-at-agu-2019/859/2 "2019-12-10T14:30:06Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![kafka](https://discourse.obspy.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kafka](https://discourse.obspy.org/u/kafka)\
**Post date:** [June 9, 2020, 7:20pm UTC](https://discourse.obspy.org/t/obspy-at-agu-2019/859/3 "2020-06-09T19:20:43Z")

</div>

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](https://discourse.obspy.org/uploads/short-url/hG8qBr8WoulSiIgc0Q21sbgwJwH.ipynb) (166 KB)

---

<div class="post-metadata">

**Author:** ![megies](https://discourse.obspy.org/user_avatar/discourse.obspy.org/megies/32/9_2.png) [@megies](https://discourse.obspy.org/u/megies)\
**Post date:** [June 10, 2020, 8:03am UTC](https://discourse.obspy.org/t/obspy-at-agu-2019/859/4 "2020-06-10T08:03:42Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![kafka](https://discourse.obspy.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kafka](https://discourse.obspy.org/u/kafka)\
**Post date:** [June 11, 2020, 4:44am UTC](https://discourse.obspy.org/t/obspy-at-agu-2019/859/5 "2020-06-11T04:44:28Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![kafka](https://discourse.obspy.org/letter_avatar_proxy/v4/letter/k/3d9bf3/32.png) [@kafka](https://discourse.obspy.org/u/kafka)\
**Post date:** [June 24, 2020, 1:02pm UTC](https://discourse.obspy.org/t/obspy-at-agu-2019/859/6 "2020-06-24T13:02:12Z")

</div>

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.  
&nbsp;&nbsp;cb.set\_clim(\*fig.ppsd.color\_limits)

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

Any suggestions?

Thanks,

~ Alan Kafka

---

<div class="post-metadata">

**Author:** ![megies](https://discourse.obspy.org/user_avatar/discourse.obspy.org/megies/32/9_2.png) [@megies](https://discourse.obspy.org/u/megies)\
**Post date:** [June 25, 2020, 9:55am UTC](https://discourse.obspy.org/t/obspy-at-agu-2019/859/7 "2020-06-25T09:55:18Z")

</div>

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/pull/2652>
>
> We need to adjust some PPSD plotting internals to a matplotlib API change:
> 
> \`\`…\`
> \[...\]\\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)
> \`\`\`
> 
> @millipedes this is something pretty simple and confined, if you wanna give it a shot? It might need an if/else depending on matplotlib version, but actually my guess is that the mentioned \`ScalarMappable.set\_clim\` should be in all old matplotlibs as well, but needs to be checked. This should be worked on branching off of \`maintenance\_1.2.x\`

cheers,  
Tobias