User login

PH5 Usage and Wish List Survey

Purpose of this questionnaire:
EPIC has developed PH5, an archival data format based upon the HDF5 data model, for the archiving of active source data sets. We have also developed an extensive software suite for use with PH5 data sets, allowing users to: 1) load data, 2) load, review and manipulate raw meta-data and 3) produce SEG-Y gathers and EPIC SEG-Y trace files. We are in the midst of improving the software suite, in particular, the tools for meta-data entry and SEG-Y data request tools, and are taking this opportunity to solicit input from members of the active source community on subjects which have been raised by users since the introduction of the PH5 archival data format.

Instructions: Please take a moment to complete this questionnaire by May 30^th. We will review the results of the questionnaire and use the conclusions drawn from the review to best direct future software development and ensure adherence to SEG-Y format.

1. Have you been exposed to PH5? If so, please describe where (e.g. in-field, recipient of PH5-generated gathers, as a request tool at the DMC) and give your assessment:

2. Our software produces SEG-Y Revision 1 data files. Can a strong case be made to write Revision 0 SEG-Y files? If so, please explain:

3. SEG-Y Revision 1 documents IBM and IEEE floating point numbers as acceptable. Should we only write IBM floating points? If so, please explain:

4. Geometric offsets (source-to-receiver distances) calculated from geographic coordinates are calculated as great circle distances in meters. Is there another preferred means to calculate offsets? If so, please describe the procedure for doing so:

5.We accept definitive location information as geographic coordinates in decimal degrees based upon the WGS84 datum. (Note we are working towards the integration of user-provided azimuth and offset/spacing as location information to follow the SEG-Y standard.) If we were to accept other systems to define locations then we must document the acceptable systems/coordinates and then write the code to make the appropriate conversions so the locations may be available to a data requester in commonly used coordinate system and datum. With that in mind, can a strong case be made to accept locations utilizing another coordinate system, datum or ellipsoid as the definitive source of location information? If so, please explain:

6. Unused space (perhaps in the textual header and/or trace header) within the SEG-Y Rev. 1 standard could be used to define alternative or custom coordinate system locations, in addition to the geographic coordinates as described earlier. We would likely define variables for the coordinate system and datum (in the textual header) and X, Y and Z (in the trace header). Would the means to store a location in an alternate coordinate system be useful (these would be in addition to the aforementioned WGS84-referenced geographic coordinates)?:

7. We are presently working on a friendly, intuitive, GUI to allow users to enter the required meta-data (e.g. station IDs, locations, shot times, etc) for a data set. We would require PIs to use the GUI to supply meta-data to the data set. Should we also accept text files in a known, agreed-upon format (e.g. das, shot, geometry files) as an alternative to the GUI to supply meta-data? If so, please explain and provide an example:

8. We define logical groups of stations as arrays or lines and, when possible, give the left-most digit of the station ID the array number in which it resides. Organizing the stations into arrays or lines allows for those requesting shot or receiver gathers to easily request the data. With some planning, this method of identifying stations should be sufficient for most experiments, including those with a roll-along line or array. Are there other means by which stations should be grouped which would facilitate a more logical or efficient organization or provide for more straight-forward data requests? If so, please elaborate (also refer to question 10 regarding data request methods and options we are considering):

9. There typically are instances where a given datalogger did not record data when planned. In these cases we could supply a trace in a gather, which is zero-padded, as a place holder in the gather. Would you find useful an option during data requests to either include zero-padded traces or exclude any stations that do not contain data from the data request? Explain:

10. Desirability of various SEG-Y Request Types and Options

We are improving the DMC web page providing for SEG-Y data requests from data sets stored in the PH5 format. This data request web page would be tailored for the experiment (e.g. a land based project with few shot would offer shot-gathers, a offshore project, receiver gathers, or mixed project utilizing both types of gathers). Please note the following request types and options as those you would find desirable or not.

SEG-Y Gathers/Record-sections as Shot Gathers:

	Desired	Not Desired
All arrays
Individual arrays (single or multiple)
User-defined station or serial number list
User-upload-able text file defining stations to include in the list
Trace start time offset (in seconds)
Duration or length of traces (in seconds or samples)
Components (where applicable): vertical only, horizontals only, or all 3 components

SEG-Y Gathers/Record-sections as receiver-gathers:

	Desired	Not Desired
All shots
A user-defined list of shots
Data for a given receiver
Components (where applicable): Z, N or E
Duration or length of traces (in seconds or samples)

PASSCAL SEG-Y shot-based requests (one trace per file with essentially no limit regarding the length of the trace):

	Desired	Not Desired
All arrays
Individual arrays (single or multiple)
User-defined station or serial number list
User-upload-able text file defining stations to include in the list
Trace start time offset (in seconds)
Duration or length of traces (in seconds or samples)
Components (where applicable): vertical only, horizontals only, or all 3 components

PASSCAL SEG-Y receiver-based requests (one trace per file with essentially no limit regarding the length of the trace):

Other possibilities:

	Desired	Not Desired
Gathers or individual traces files from an array within a user-specified offset range
A reduction velocity applied to the requested data
Multiple receiver gather requests (e.g. receiver gather requests iterating over a range of station IDs)

11. Any specific points we may have missed in this questionnaire which you would like to see addressed?:

Who are you?:

Please tell us who you are. (Optional)

EarthScope Primary Instrument Center
New Mexico Tech
100 East Road, Socorro, NM 87801

User login

PH5 Usage and Wish List Survey

Also See

Quick Links