barsch on master
add venv to .gitignore Merge pull request #2826 from H… (compare)
obspy-mopad plot -- '-2,1,1,0,0,1'
@numbadecorators and see a good perf gain ?
numbawould not do anything for PPSD computation.
numbais a just in time compiler for functions that use numpy. So it can really only fully speed up functions that take numpy arrays and spit out numpy arrays and also does not call any other library inside the function. But it is pretty great for that.
matplotlib.mlab.psd()for the actual spectral estimations. pyfftw can monkey patch the numpy ffts: https://pyfftw.readthedocs.io/en/latest/source/tutorial.html#integration-with-3rd-party-libraries - make sure to turn on the cache here as I think it should help a lot. Thus no change to ObsPy is needed. A great solution might also be to replace
scipy.signal.welch()which uses scipy's fft which is faster and has better way to change the backend - but that would be a more involved change.
Hello everyone, I hope this is the right place for questions considering the obspy codes.
My question is about the remove_response code in obspy:
I'd like to remove the instrument response from the recordings of a hydrophone. The raw units are counts which are proportional to Pascal. With remove_response, I can choose between ACC, VEL and DISP output. Now I wonder which output unit to choose for the hydrophone....from velocity one needs to integrate or differentiate to ACC and DISP. Is the code recognizing the unit of the input. Would it recognize, that the counts of the hydrophone are proportional to Pascal and if I tell to restitute to ACC, it is not additionally integrating? Or is the code treating the Hydophone traces like 'normal' seismometer traces where the counts are proportional to Velocity and I should restitute the data to 'VEL', since then the hydrophone data still keeps proportional to Pascal and thus somehow the ACC.
I have seen the special handling hydrophone, but I don't know how to use it and also, if the output can be ACC, since there it's written: Do not differentiate when `special_handling="hydrophone"
I'd appreciate any help! Thanks a lot!
output=VEL, which does not introduce additional differentiation or integration. This is not really intuitive and I’m about to propose a new option
output=DEF(default) which hopefully will be part of ObsPy 2.0 :wink:
Hello ! Our team made some progress in generating PPSD graphs with obspy. I'd like the comments of the community (scientists and obspy devs).
Method 3 is about 3 time faster to produce the NPZ stat file than method 2.
Jérôme Touvier (our developper who produced this result) is not connected in the chat yet but will certainly join us.
Hello everyone, I am getting a warning message when using the
UserWarning: AutoDateLocator was unable to pick an appropriate interval for this date range. It may be necessary to add an interval value to the AutoDateLocator's intervald dictionary. Defaulting to 30. plt.setp(ax.get_xticklabels(), fontsize='small')
The warning appears when I try to plot the graph. So far, I don't see any major shift in my date range. Can anyone advise me on this?
My implementation is as follows:
st.trim(starttime=stat.starttime + trim_time, endtime=stat.endtime)
@ThomasLecocq @joschaeffer_gitlab - yea this is pretty much the reason. If the full inventory is present evalresp will evaluate all stages of the response which just takes a lot longer. If there are only PAZ, the response will be fully computed from it. If the PAZ alone are good enough is situation dependent: In most cases it will likely work just fine in the passband of the instrument. A colleague of mine once estimated that like 10% of stations have responses that are not sufficiently approximated by PAZ. If you are familiar with the stations you are using you can probably make decision based on that. Otherwise you could also just test if the reponse with PAZ vs full response is similar enough once for each station epoch and then decide case by case.
If someone really wants to dig down: I suspect the whole thing could be made quite a bit faster by doing some smart caching of the response. Right now the response is computed for each data segment but it really only would need to be computed for each station epoch. Some work would be required to figure out when to use the cached value and when not but it should not be too hard to do: https://github.com/obspy/obspy/blob/master/obspy/signal/spectral_estimation.py#L1252