Error while invoking rfpy_calc in terminal

[dip16gphy]

I have this error while calculating RF in terminal. Please help.

Thanks.

[wasjabloch]

This looks like an obspy problem. Can you please open, in the same conda environment, a python console and post the output of:

import obspy
obspy.__version__

[wasjabloch]

@paudetseis Or might this have to do with MMPY.pkl being platform dependent? I have some commits for stdb to read .csv instead, which would likely solve the problem and would also be more transparent. I'll open a pull request for stdb and ask @schaefferaj if he can include it.

[dip16gphy]

This looks like an obspy problem. Can you please open, in the same conda environment, a python console and post the output of:

import obspy
obspy.__version__

obspy version is 1.3.0.

But when i check in rfpy environment using conda list, it shows obspy version as 1.2.2

[paudetseis]

hmm, the exception is raised by the client package, and not obspy. I have never seen this exception before, so I'm not sure how to fix it.

Can you type, in a terminal: conda activate rfpy conda list --explicit > spec-file.txt

and share the file here?

[dip16gphy]

hmm, the exception is raised by the client package, and not obspy. I have never seen this exception before, so I'm not sure how to fix it.

Can you type, in a terminal: conda activate rfpy conda list --explicit > spec-file.txt

and share the file here?

Yes.. spec-file.txt

[dip16gphy]

hmm, the exception is raised by the client package, and not obspy. I have never seen this exception before, so I'm not sure how to fix it.

Can you type, in a terminal: conda activate rfpy conda list --explicit > spec-file.txt

and share the file here?

Do we have any solution to this error now? I want to know if the command runs in your terminal too? Please help.

[paudetseis]

Please note that we are not always able to address these issues quickly, especially if they are platform dependent. I will try to look into it as soon as I can.

[wasjabloch]

The script is running for me. I also tested the obspy call in question with the obspy version you are using (1.3.0):

event_client.get_events(starttime='2013-07-01', endtime='2599-12-31', minmagnitude=6)

and it worked for me. I suggest you try updating obspy once more. You tested it literally on the day obspy1.3.0 was released and perhaps you caught a tiny glitch that has not been fixed before.

[wasjabloch]

@dip16gphy Can you check if, in a python console, the following code is returning a list of 8 events?

from obspy.clients.fdsn import Client
client = Client()
client.get_events(starttime='2013-07-01', endtime='2599-12-31', minmagnitude=8)

If you continue to see the Error above, the obspy community is for sure grateful for a bug report, that you could file here.

If this is working, please re-run rfpy_calc. It should be working just fine.

[dip16gphy]

@dip16gphy Can you check if, in a python console, the following code is returning a list of 8 events?

from obspy.clients.fdsn import Client
client = Client()
client.get_events(starttime='2013-07-01', endtime='2599-12-31', minmagnitude=8)

If you continue to see the Error above, the obspy community is for sure grateful for a bug report, that you could file here.

If this is working, please re-run rfpy_calc. It should be working just fine.

Sorry for late reply!

The above codes run without any error. Yes, I got 8 events.

[wasjabloch]

I have to admit that I am pretty clueless here, because it is this very call that causes the error in the script. In the same conda environment, rfpy_calc should just run. Just to triple check, see if this line throws an error.

client.get_events(starttime='2013-07-01', endtime='2599-12-31', minmagnitude=6, maxmagnitude=9)

It is the exact same call that gave you the original error.

[dip16gphy]

client.get_events(starttime='2013-07-01', endtime='2599-12-31', minmagnitude=6, maxmagnitude=9)

Yes, it gives the same error while using the rfpy_calc in terminal. I checked and found that whenever min magnitude is less than 7, it throws error.

[wasjabloch]

Okay, I suspect that there is an ill-formated event in the database that your specific version of obspy cannot handle. I suggest you file a bug report at the obspy site, with the code that produces the error, i.e.:

from obspy.clients.fdsn import Client
client = Client()
client.get_events(starttime='2013-07-01', endtime='2599-12-31', minmagnitude=6, minmagnitude=8)

To continue testing rfpy, you can run rfpy_calc with the option --minmag 7

[dip16gphy]

Okay, I suspect that there is an ill-formated event in the database that your specific version of obspy cannot handle. I suggest you file a bug report at the obspy site, with the code that produces the error, i.e.:

from obspy.clients.fdsn import Client
client = Client()
client.get_events(starttime='2013-07-01', endtime='2599-12-31', minmagnitude=6, minmagnitude=8)

To continue testing rfpy, you can run rfpy_calc with the option --minmag 7

Unfortunately, I am stuck in other error now. While attempting to open Jupyter Notebook via conda terminal, I am getting this error: ImportError: DLL load failed while importing error: %1 is not a valid Win32 application.

Also, query_fdsn_stdb -N NY -S MMPY MMPY > logfile gives following error: ImportError: DLL load failed while importing QtWidgets: %1 is not a valid Win32 application.

I tried reinstallation of pywin32 too, but didn't work.

[wasjabloch]

On Windows 10, there is the possibility to install an Ubuntu-Linux under the hood. Maybe this could be a way around the issue, as much scientific software is developed and maintained on Linux systems. This tutorial might be helpful:

https://www.howtogeek.com/249966/how-to-install-and-use-the-linux-bash-shell-on-windows-10/

[dip16gphy]

Apart from issue of minmag, all the scripts are running well.

Thanks for help.

[dip16gphy]

Okay, I suspect that there is an ill-formated event in the database that your specific version of obspy cannot handle. I suggest you file a bug report at the obspy site, with the code that produces the error, i.e.:

from obspy.clients.fdsn import Client
client = Client()
client.get_events(starttime='2013-07-01', endtime='2599-12-31', minmagnitude=6, minmagnitude=8)

To continue testing rfpy, you can run rfpy_calc with the option --minmag 7

I raised this issue of minmagnitude here https://github.com/obspy/obspy/issues/3028#issuecomment-1078235521 . They gave a solution using 'chunk_length'. I tried & it runs well in python console. Now, I want to use this in 'rfpy_calc' script. I am trying the following edits in that but it is still not working. Could you please check & modify the edits? Thank you!

`# Get catalogue using deployment start and end

    cat = Catalog()
    chunk_length = 365 * 86400  # Query length in seconds

    while tstart <= tend:
                cat += event_client.get_events(tstart=tstart, tend=tstart + chunk_length, minmagnitude=args.minmag, 
                            maxmagnitude=args.maxmag)
                tstart += chunk_length

[wasjabloch]

Thanks for raising the issue at obspy. The discussion there is quite insightful.

I have implemented the patch in the master branch. Can you update your installation and try if it solves the issue for you?

[dip16gphy]

Thanks for raising the issue at obspy. The discussion there is quite insightful.

I have implemented the patch in the master branch. Can you update your installation and try if it solves the issue for you?

Unfortunately it's still not working, throwing the same error. :(

I have one more issue. When rfpy_calc script runs, it shows error retrieving waveforms. What could be the reason? Is it either because of poor net speed or something else?

[wasjabloch]

it shows error retrieving waveforms.

This is because some waveforms are actually not on the server. This often happens, as the meta-data of the station (with a single start and end time) often does not account for data gaps. This is not the issue here.

I have added a new commit to master. Please try this one. If the error message persits, please copy it again to this thread for inspection. It is a little easier for me, if you could copy the text directly, instead of taking a screenshot.

Thanks for letting us know and helping making RfPy better!

[dip16gphy]

it shows error retrieving waveforms.

This is because some waveforms are actually not on the server. This often happens, as the meta-data of the station (with a single start and end time) often does not account for data gaps. This is not the issue here.

I have added a new commit to master. Please try this one. If the error message persits, please copy it again to this thread for inspection. It is a little easier for me, if you could copy the text directly, instead of taking a screenshot.

Thanks for letting us know and helping making RfPy better!

Thanks for quick help.

I have one more query. For some stations,while using query_fdsn_stdb -N AM -S RF6E7 RF6E7 I get this :

`Output Files: RF6E7.csv and RF6E7.pkl'

'Initializing Client (IRIS)...Done'

'Querying client...Exception: Cannot complete query or no data in query...`

Is there no recording over these stations or something else?

[wasjabloch]

I understand that the recent version of master resolved your issue? I am therefore closing this bug.

Unfortunaley, stdb hides the true exception behind the exception you are seeing. I tried:

from obspy.clients.fdsn import Client
client = Client()
inv = client.get_stations(network='AM', station='RF6E7')

and indeed get:

FDSNNoDataException: No data available for request

which is sad.

However, the FDSN site of the network http://www.fdsn.org/networks/detail/AM/

shows that the data is also hosted by the Raspberry Shake project and I was able to retrieve waveforms here https://fdsnws.raspberryshakedata.com/fdsnws/dataselect/1/builder

I also could get the station information directly via obspy:

from obspy.clients.fdsn import Client
client = Client('RASPISHAKE')
inv = client.get_stations(network='AM', station='RF6E7', level='CHANNEL')

This indicates that the Channels are name unconvenionally 'EHE", 'EHN' and 'EHZ'. I could at least trigger a call to get some station information via

query_fdsn_stdb -N AM -S RF6E7 -C EH* --Server=RASPISHAKE RF6E7

But the resulting files are empty, because the location code is somehow not treated correctly. I do not know what's going wrong there, sorry. You may ask at https://github.com/schaefferaj/StDb. You can reference this issue and I hope Andrew knows a way around this.

As a last resort, you could try using another station nearby, e.g. one from:

from obspy.clients.fdsn import Client
client = Client()
inv = client.get_stations(latitude=18.2, longitude=-73.7, maxradius=1, level='channel')
print(inv)

I hope that gives you some ideas on how to move on with your project.

P.S.: Please comment below if the issue persists and I can reopen the issue.