Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ph5torec.py and ph5toevt.py should be changed to match ph5tomsAPI.py model #2

Closed
nick-falco opened this issue Nov 3, 2016 · 3 comments
Assignees
Labels
backlog enhancement GeoHDF Things to consider for GeoHDF

Comments

@nick-falco
Copy link
Collaborator

The ph5torec.py and ph5toevt.py scripts for converting PH5 to SEG-Y should be changed to match the general model used in ph5tomsAPI.py.

From what I can tell, this implies the following:

  1. ph5torec.py and ph5toevt.py should be combined into one file (e.g. ph5tosegy.py)
  2. The combined file (ph5tosegy.py) should be a module that includes a class called PH5toSEGY. e.g. https://github.com/PIC-IRIS/PH5/blob/master/webservices/ph5tomsAPI.py#L93
  3. The PH5toSEGY class would contain methods for returning SEG-Y data objects in Shot (event) and Receiver order. (e.g. def get_data_shot(), def get_data_recevier() ). These methods may be further decomposed to reuse code.
  4. The get_data_shot() and get_data_recevier() methods in the above example, would return SEG-Y data objects. These objects would have a write method that writes their contents to a file like object or standard out.

With this model, running the program from the command line is trivial:

  1. The user would supply parameters including a request type.
  2. The program will then instantiate a PH5toSEGY object instance with the supplied parameters
  3. The program will call the requested data selection method (get_data_shot() or get_data_recevier()) on that PH5toSEGY instance. This will return a SEG-Y data object.
  4. The program will call the SEG-Y data objects write method, which will in return write the SEG-Y data to a file like object or standard out.
@rsdeazevedo
Copy link
Contributor

Nick, I agree with the overview. Thanks. One of the details that may be a problem on your end? I was planning on yielding the text and reel headers and then yielding each trace header with the trace seperately until the gather is complete. Would this work instead of the entire gather?

@nick-falco
Copy link
Collaborator Author

nick-falco commented Nov 3, 2016

Hmmm. I'm not sure if I follow.

The PH5toSEGY get_data_shot() or get_data_recevier() methods should return some sort of SEG-Y data object (much like a ObsPy trace) that would contain all of the information required to read the PH5 data set and write one SEG-Y file.

Performance optimizations that you make while writing the data shouldn't make a difference as long as when the PH5toSEGY object's write method is envoked - SEG-Y data is either written to a file-like object or to standard out.

Just remember that data streams like (std-out) are not seekable, so you can't write the data first and then go back and write the headers later. All of the file contents need to be written in the order they will appear in the SEG-Y file.

Does this answer your question?

@timronan
Copy link
Collaborator

PH5toSegy is no longer supported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog enhancement GeoHDF Things to consider for GeoHDF
Projects
None yet
Development

No branches or pull requests

5 participants