Reformatting & geometry QC

Part 2 is the chain of operations between “data exists on a hard drive” and “velocity analysis can start.” None of it is glamorous. All of it is essential. The first step is the least glamorous of all: reformatting, converting the vendor-delivered SEG-Y into the processing system’s internal format, and its conjoined twin geometry QC, where you verify that every trace is what its header says it is.

1. Reformatting in ten bullet points

• Read SEG-Y files from the vendor (often multi-terabyte).
• Parse the 3200-byte textual header, document any peculiarities.
• Parse the 400-byte binary header, extract sample rate, trace count, format code (IBM floats, IEEE, 16-bit int, etc.).
• For each trace, parse its 240-byte trace header plus N samples.
• Apply the coordinate scalar from bytes 71-72: a positive value ($+10$, $+100$, $+1000$, ...) multiplies the stored coordinate, a negative value divides by its magnitude, and $0$ or $+1$ leaves it unchanged.
• Handle byte order correctly: the SEG-Y standard is big-endian, but many writers emit little-endian (revision 2 flags it in the binary header).
• Re-pack into the processing system’s internal format (ProMAX/SeisSpace, Omega, Echos, Madagascar RSF, and so on).
• Check trace count against the vendor report: a mismatch means traces were lost, duplicated, or the format was misread.
• Sanity-check sample rate, sample count, and record length; every downstream operator uses them.
• Output a first geometry QC report: fold map, shot map, receiver map, and histograms of trace-header values.

2. One survey, loaded six ways

The fold map is the single most informative diagnostic. If you can only display one picture after reformatting, make it a fold map and compare it with the fold the survey design planned. The figure below loads one synthetic 3D land survey six ways: once correctly and five times with a header bug. Pick each load, compare the loaded fold in (b) with the planned fold in (a), and learn the signatures until you can name them from across the room. Notice the one bug the fold map cannot see.

3. What to look for

• A smooth trapezoidal plateau. Geometry loaded cleanly: in the figure every bin sits at its planned fold of 16 and the edges ramp down over the last 300 m. Proceed. The plateau is smooth only when the bin fits the midpoint spacing ($\\mathrm{RI}/2$ by $\\mathrm{SI}/2$, 25 m here); with 30 m bins even a clean load stripes between 16 and 64 traces per bin.
• An empty map: nothing inside the survey outline. The coordinate scalar was ignored or applied backwards, or the byte order is wrong. The value ranges tell which: coordinates ten times too large (shot eastings of 6 150 250 m in the figure, against 615 025 m planned) point at the scalar, and nonsense (a scalar that reads $-2305$) points at byte order. Re-read bytes 71-72 with their sign convention, or flip the endian interpretation, and re-load. In local coordinates that start near zero, a scalar bug that shrinks the survey piles every trace into one corner instead.
• A fold map shifted from the survey plan. The stored CDP field is stale. In the figure the map moves 100 m north and 23 % of bins miss their planned fold, all of them at the edges, where the difference (c) shows a plus and minus pair while the plateau cancels. Recompute CDPs from the shot and receiver coordinates in the loader and discard the stored values.
• A low-fold band or a hole. Traces are missing for a subset of shots or receivers. One missing receiver line lowers fold along a band parallel to it (by 25 % over 800 m in the figure) without emptying a single bin, because its midpoints spread halfway to every shot that recorded it; only a whole missing swath opens a hole. Check against the vendor report and re-request the missing SEG-Y file.
• A fold map that looks perfect. A shot/receiver swap leaves every midpoint $(x\_s + x\_r)/2$ and every offset $|x\_r - x\_s|$ unchanged, so the fold map and the offset histogram cannot see it. Plot the shot map and the receiver map separately: in (d) the header shots sit on the receiver lines, and none of the 992 lies on a source line.

4. The ten-minute QC checklist

Run these in order on every new dataset. Stop at the first failure and fix before continuing.

1. Fold map matches survey-design planned fold.
2. Shot map shows every planned shot line and spacing.
3. Receiver map shows every planned receiver line and spacing.
4. Offset histogram lies within the planned offset range; no implausibly large values, and negative values only where the offset convention is signed.
5. Azimuth rose matches the survey design.
6. Sample rate matches the vendor report (e.g. 2 ms).
7. Trace length matches the vendor report (e.g. 6 s).
8. Total trace count matches the vendor report exactly, or every difference is documented.
9. First-break time range is plausible for the target depths.
10. A sample shot gather shows primaries at the expected $t\_0$ values.

Only after all ten pass do you proceed to any further processing. Every seismic project that went sideways in production started with a QC item that was silently skipped.

5. Why the investment pays

Every minute spent here is a day saved later. A scalar bug that goes undiagnosed for two weeks creates two weeks of processing products on the wrong geometry, velocity picks, statics and migrations, all of which must be redone. A missing receiver line noticed in geometry QC takes a phone call; noticed at interpretation, it takes a reshoot.

6. The sort domains, and what each is for

Raw data arrives in shot order, but a processor re-sorts it constantly, because each problem is easiest to see, and each correction easiest to apply, in a particular domain. The same traces, re-ordered, expose different things, and knowing which domain to display is half of QC.

• Shot (common-source) gather. The recording domain. First breaks, refraction statics, source-generated noise (ground roll, air blast), and shot-to-shot amplitude balancing all live here, because they are organized by source. Linear noise really is linear in this domain, which is why FK and radial filters are designed on a shot gather.
• Common-receiver gather. All traces sharing one receiver. This is where a single bad geophone gives itself away: a dead, reversed, or ringing channel is a stripe here and nearly invisible anywhere else. Receiver statics and receiver-consistent amplitude terms are solved in this domain.
• CMP (common-midpoint) gather. The workhorse. Velocity analysis, NMO, residual statics, stack, and AVO all happen here, because every trace in the gather images the same subsurface point at a different offset. Almost everything from Part 3 onward assumes you are in this domain.
• Common-offset gather, or section. One offset, every midpoint. A single common-offset section is a rough, zero-effort image of the structure, handy for a quick structural look, for migration QC, and for catching offset-dependent problems such as a statics bust that only shows at far offset. DMO and some migration QC operate here.
• Offset order, inside a CMP. Less a separate domain than the sort within the CMP gather: by absolute offset for a tidy, monotonic moveout display, or by signed offset so a velocity error reads as a symmetric smile or frown (Section 3.3).

The working rule: when something looks wrong on the stack, ask which domain would organize the problem into a straight line or a single stripe, then display it there. A receiver fault is invisible on a CMP gather and obvious on a common-receiver gather; a velocity error is the other way around.

Where this goes next

Section 2.2 starts the actual waveform processing. Trace editing removes bad samples and dead traces; amplitude recovery compensates for the known physical decay of wave amplitudes with travel time. Both are simple operations that every later step depends on.

References

• Sheriff, R. E., Geldart, L. P. (1995). Exploration Seismology (2nd ed.). Cambridge UP.
• Yilmaz, Ö. (2001). Seismic Data Analysis (2 vols.). SEG.
• Claerbout, J. F. (1976). Fundamentals of Geophysical Data Processing. McGraw-Hill.