Loading SEG Y files

From SubSurfWiki
Jump to navigation Jump to search

Twice in the last year, I've heard from people experiencing lots of frustration with loading SEG Y seismic data. In both cases, the frustration stemmed from the same problem. After some epic emails, I realized I need to write a post about it — next time I can just send a URL!

In a nutshell, the specific problem both these people experienced was missing or bad trace location data. Because this can be such a hard problem to troubleshoot, I never trust location data in a SEG-Y file. You just don't know where it's been, or what has happened to it along the way — what's the datum? What are the units? And so on. So my standard procedure for loading data is:

  1. Define the survey geometry, at every trace for a 2D, or just with corner-points for a 3D. Note that for 2D data the geometry is usually in a separate nav file. For 3D it may be in the processing report or in the ASCII or EBCDIC header of the SEG-Y file. Now the traces have somewhere to go. Create a GEOMETRY, which is a description of where the line goes on the earth, in surface coordinates, and where the starting trace is, how many traces there are, and what the trace spacing is. In other words, the geometry tells you where the traces go. It's variously called 'navigation', 'survey', or some other synonym. Sometimes this info is in the SEG-Y file, but often this is an unreliable source of nav data. Better to have a navigation file, or annotated map, or something separate.
  2. Load the traces into their homes, often one line at a time for 2D. The cross-reference is the trace number (or CDP number, or line and xline numbers, or whatever you have). Load the actual TRACES, which are the meat of the SEG-Y file (but are not human-readable). So all you really want to get from the SEG-Y are the trace numbers, which are usually in a low byte number. In your file, it looks like you can use byte 21. This doesn't help you much without navigation, however.

Of vital importance is some independent corroboration — a map, ideally — of the geometryand the shape and orientation of the survey. I can't count the number of back-to-front surveys I've seen. I even saw one upside-down (in the z dimension) once, but that's another story.

The anatomy of a SEG Y file

SEG-Y files have two components: the EBCDIC header and the traces. Your EBCDIC header is almost useless, as they often are. The traces also have two bits: a header and the data. The data are stored on the file in 4-byte 'words'. Each word has its own address, or 'location' (a number), and a meaning. The headers map the meaning to the location, e.g. the trace number is stored in byte 21. To see the byte headers, you can use OpendTect > Survey > Import > Seismic > SEGY, and select your file. It will bring up a viewer. Ask for 1000 traces, to get a good look at the headers. Petrel's loader will certainly let you do this too, I just don't know how. All seismic data loading software have a trace header viewer.

If there are coordinates in a SEG-Y file, they're supposed to be in bytes 73 and 77. Or in 81 and 85. Bytes 181 and above are undefined in the SEG standard, so sometimes people put coordinates there. Basically they can be anywhere.

Figuring out the location of the trace numbers isn't always a picnic either. In a 3D, you have to find the line and CDP numbers (or inline and crossline, if you prefer). These increase like so, for a 3 × 3 3D survey:

Line 1 1 1 2 2 2 3 3 3
Xline 1 2 3 1 2 3 1 2 3

The detective work continues... Finding a coordinate byte is often just a matter of looking for something that looks like coordinates. Often (in a North American UTM zone) this is a 6-digit x and a 7-digit y location, almost always in consecutive byte locations. But there's nothing like that in your file.

Loading SEG Y data into OpendTect

Here are the specifics of the workflow in OpendTect:

  • Select the file, ask for at least twice the number of traces that you have in an inline (or just put 1000), and say 'format' from header; click Next
  • Look at the header and trace headers, and figure out where the data are. If I have a geometry already I'm just looking for inline, xline, and data; check No (you almost always need to change byte locs), and Next
  • Give it the inline and xline bytes, and anything else you need. Change base positioning to coords if the headers is the best you can do, Save the setup, and Go
  • Select the file, ask for at least twice the number of traces that you have in an inline (or just put 1000), and say 'format' from header; click Next- Look at the header and trace headers, and figure out where the data are. If I have a geometry already I'm just looking for inline, xline, and data; check No (you almost always need to change byte locs), and Next- Give it the inline and xline bytes, and anything else you need. Change base positioning to coords if the headers is the best you can do, Save the setup, and Go

External links