August 6, 2013 Seismic Data Preprocessing Workshop
http://sepwww.stanford.edu/oldsep/stew/Summer2013Workshop/
In this session you tackled the second of three hands-on projects—prestack time migration. This migration
is conceptually simple, but involves several parameters controlling tradeoffs between accuracy, resolution,
and performance.
Prestack Time Migration
The OpenCPS documentation provides a workflow for running their Prestack Time Migration module
along with a fair number of options, including ways to run it in parallel across multiple processes or
machines.
Prestack time migration (PSTM) uses a simplified version of the Kirchhoff migration method. The
parameter that most controls speed is the migration aperture, controlled by a time/radius table and an
aperture ratio that squeezes the circular pattern into an elliptical one. As the amount of work is
approximately proportional to the average number of traces within this aperture, one should expect the
runtime to follow a square law, i.e., doubling the aperture radii quadruples the runtime. Reducing the
output trace length and/or its sample rate is another way to cut runtime. This typically produces savings
that are somewhat better than linear because the largest apertures are, or at least should be, near the end of
the output image traces.
Options that affect fidelity, resolution and noise level are the antialiasing, eta (far offset anisotropy
correction), and the Geometry Mode. Antialiasing cuts down background noise steep summation paths,
though in most production sized runs you probably wouldn’t notice a difference except for increased
memory usage and some runtime hit. Internally, the PSTM already oversamples traces, which pushes
many aliasing issues to high frequencies that may well be beyond the bandwidth of the data. The optional
eta table effectively reduces moveout corrections at wide offsets, reducing or removing the “hockey stick”
effect that unmuted NMO produces in the presence of vertically increasing velocities.
For our data, the Geometry Mode should be set to the expensive True-Azimuth Prestack setting as the
midpoint coverage is anything but a set of parallel (narrow azimuth) lines.
To assess the output before stacking, we view the output and select View > Sort to … 3D CDPs. By
navigating the ILINE-XLINE panel, you can bring up migrated gathers at selected locations to assess their
flatness for primaries (the quality of the velocity), something that isn’t particularly good for this crude brute
velocity migration.
After stacking the output, the second line looks like:
Here the ringing precursors in the water column are the aliasing artifacts that arise when the survey has
relatively irregular and low fold, especially when antialiasing is disabled.
Arbitrary Line
The final challenge of the exercise was to select and display a section whose track curves through the area
of dense coverage in the survey. There is, of course, more than one way to do this, but the easiest is to use
the OpenCPS 3D View and pick a table of type “Abitrary(sic) Line”. The steps in this process are
1.
2.
3.
4.
5.
Load a 3D stack
Right click (MB2) in the main view and select Show View > 3D View
In the Navigation View, open the palette and select an INLINE/XLINE slice; move down in
time/depth until the timeslice shows something interesting
In the Navigation View, right click (MB2) and select New > Abitrary Line. Give it a name and
click OK.
Start picking the arbitrary line in the Navigation View; it should render in the 3D View
6.
7.
You may want to turn off some of the 3D View’s orthogonal slices from the palette (checkboxes
next to ILINE, XLINE and TIME).
Shift+Drag of pick moves all the picks at once to pan the arbitrary line back and forth
Note that you can also create an XLINE(ILINE) pick file instead of ILINE(XLINE) if your arbitrary line is
multi-ILINE-valued instead of multi-XLINE-valued.
Here’s what I came up with for my arbitrary line on a machine with a large enough memory to hold the
18Gb migrated image easily.
Unfortunately, this procedure didn’t work for me on the smaller cees-tool platform. There I used a more
cumbersome method, one which can be made to work for truly arbitrary twisted paths, but requires
significant manual editing outside of OpenCPS. The key tool is DBMerge, which has an option for
discarding any trace that doesn’t match a database table row. I’ll leave details to the reader as an exercise,
but the CSV (comma separated values) table should have ILINE and XLINE (as integers) to match trace
headers, and a third sequence number, say PICKNO, to add to selected trace headers in order to properly
sort the selected traces into the arbitrary line.