use obspy input/ouput and signal processing tools where appropriate
Closed this issue · 10 comments
Status update: preprocess.base now has obspy as a dependency; preprocess.legacy does not. Since obspy adoption is a major change, additional testing is underway, beyond the usual integration tests and readthedocs example.
Are there any plans to make readers format exclusive? For example having a singular reader for SU formats or will they remain a combination of solver + format? Also are the processing routines be migrated exclusively to Obspy stream objects? I'd like to make sure any future code follows the current direction.
Are there any plans to make readers format exclusive? For example having a singular reader for SU formats or will they remain a combination of solver + format?
Great question. I think an ideal solution would be to have say, seisflows.solver.data specify the path to the data, and seisflows.preprocess.reader be an all purpose reader that simply reads from that path. Unfortunately though, this might create a circular import.
For now, probably we will stick to the current way of doing things in preprocess.base, because that module is currently pretty clean, and for a number of other reasons including idiosyncratic SPECFEM filename conventions.
Feel free to either add your own readers to seisflows.seistools.readers, or to add your own completely new seisflows.preprocess class and build your SU reader (probably just a thin wrapper over obspy.segy.core.readSU ?) directly into to it.
Also are the processing routines be migrated exclusively to Obspy stream objects?
Yes, the plan is to transistion to a new data processing class in which all signal processing operations are handled by obspy calls on stream objects. All new development will make use of obspy stream objects. Because things are set up in a modular way, the old way of doing things preprocess.legacy should continue to work indefinitely.
P.S. I would add that, if you haven't looked at seisflows.preprocess.base recently, it might be worth a short glance. It has been cleaned up considerably this month.
Is it fair to assume that the reader/writer routines will adjusted to the format in preprocess.base? The current reader/writers include various positional/keyword arguments not used in the processing class.
The extra arguments are provided to support use cases like noise tomography, which are not currently part of the seisflows main repository, but which users might want to pursue through their own subclasses and possibly contribute to the main repository in the future.
Gian--if you have ideas for making the code cleaner/more flexible I'm interested to know. If so, and if you want to discuss through skype at some point, let me know.
Bug in preprocess/base.py: Positional arguments inconsistency
get_time_scheme returns dt, nt, t0 whereas functions in the base class call nt, dt, _. dt and nt are swapped.
Current Obspy read/write for SU files is in a deprecated format.
Update: I made some of the changes Gian suggested in my own fork, in particular, doing away with complicated readers and writers in favor of simple wrappers over obspy calls. In the next or month or two, hope to roll out these changes as part of the upcoming tagged release (issue #29 ).