Kirchhoff time migration in g-Platform, pre-stack and post-stack, run from topography instead of from a flat datum. An interactive migration velocity loop scans whole ranges of velocity at once, and the same engine takes a 2D line on a laptop or a full 3D survey across a GPU cluster.
Migration is the step that turns a section into an image. Every sample is treated as the apex of a diffraction curve described by the RMS velocity field; the Kirchhoff operator sums amplitudes along those curves and writes the result at the true reflection point, so diffractions collapse and dipping reflectors move back where they belong. g-Platform migrates from topography rather than from a flat datum, which keeps the recording surface in the travel-time calculation and makes the replacement velocity a real parameter rather than a formality. What the migration needs from you is regularized input with no gaps in the offset distribution and a smoothed velocity field — gaps and rough velocities are what migration artefacts are made of.
Before & after
Diffractions collapse, dips move home.
Before
After
Migration engines
One algorithm, four ways to run it.
The Kirchhoff kernel is the same throughout. What changes is where the data lives, how the output is sorted and what the run is for — a single test gather, a production 3D volume, an azimuth study, or a quick look at a stack.
Gathers in memory
Gather in / gather out
2D or 3D pre-stack time migration of CMP gathers held in RAM, writing the migrated gathers and the migrated stack in one pass. The same engine migrates a stack section post-stack, which is the quick way to test an aperture or take a first look before committing to a full pre-stack run.
Files on disk
File in / file out
Reads pre-stack traces straight from SEG-Y and accumulates the image bin by bin, so surveys far larger than memory migrate without ever being loaded. Output as offset classes, variable offset classes or offset-vector tiles; GPU-accelerated, distributed across nodes, and resumable after an interruption.
Offset mode
Offset-class CIGs
Accumulates energy into common image gathers sorted by source-receiver offset rather than by angle — the form offset-dependent amplitude work, AVO and velocity QC need.
Azimuthal
Sector-by-sector migration
Images each azimuth sector separately, each with its own RMS model, and outputs offset or common-angle gathers. Velocity that varies with azimuth is what points at fracture orientation and intensity.
Migration velocity analysis
Pick the velocity on the migrated image.
Stacking velocity is not migration velocity. g-Platform builds a storage of migrated images across a whole range of velocity factors first, then lets you pick on those images — so the velocity you choose is judged by the picture it produces.
Automatic velocity scanning
The velocity selector engine migrates the data once per velocity factor across a user-defined range — 80% to 120% in 10% steps by default — and writes every partial image into one KDB storage file.
Semblance on migrated panels
The imaging selector shows stacked and semblance panels at each velocity percentage in 2D and in 3D, for vertical Vrms and delta-Vrms picking — by hand, or with an auto-picker held inside a picked corridor.
Residual moveout, picked
RMO by picking computes semblance in a window around the current RMS model — 500 m/s either side by default — on a gather or a super-gather, then turns the picks into an updated velocity field.
Angle stacks you can shape
Generate common angle gathers over a defined angle range, scan them with the wheel, and paint a mute mask with the Eraser/Enhancer tool to build an enhanced angle stack from the angles that carry the signal.
Mute and offset panels
Pick the mute interactively on the common image gathers, step through the common offsets, and see the effect on the semblance and the stack before the mute is committed to the output.
Eta and VTI anisotropy
PSTM imaging scans the anisotropy parameter eta on NMO-corrected image gathers, picks it inside a corridor, and writes eta-corrected gathers and stacks. The migration engines themselves take a VTI model when the anisotropic operator is switched on.
Azimuth-sectored velocity
Define azimuth sectors, give each its own RMS model, and migrate them independently — the route to azimuthal anisotropy on a wide-azimuth survey, output as offset or common-angle gathers.
Versions kept, not overwritten
Picked velocities, mutes and the stacks built from them are saved to the project database or written out as SEG-Y and GSD, so one parameter set can be compared against the next instead of replacing it.
Workflow
Six steps from conditioned gathers to a migrated stack.
1
Regularize and smooth
Fill the gaps in the offset distribution with the regularization modules and smooth the velocity field. Both are prerequisites, not refinements — gaps produce operator artefacts.
2
Build the velocity storage
Run the velocity selector engine over the chosen velocity-factor range so every trial migration is stored once and can be interrogated as often as you like.
3
Scan, pick, correct
Step through the velocity percentages in the imaging selector, pick Vrms and delta-Vrms where the gathers flatten and the stack focuses, then clean up what is left with residual moveout picking.
4
Find the aperture
Test the migration aperture on a single central CDP, or post-stack on the section, before a production run — it is the parameter that decides both image quality and turnaround.
5
Migrate in production
Set the offset classes, the anti-alias filter and the maximum dip angle, then submit standalone or to the cluster, on CPU or GPU. Long jobs resume from the bins already migrated.
6
Stack and deliver
Take the migrated gathers into stack imaging — they are already NMO-corrected, so no second correction is needed — then shift to datum, mute the low-fold edges and write SEG-Y or GSD.
Run & scale
The parameters that decide the image.
Every value below ships with a default, and most runs change only a handful. Two of them are project facts rather than preferences: the replacement velocity has to match the one used in your datum statics, and the CMP bin intervals have to match the survey, because the anti-alias filter is computed from them.
Operator parameters
What the Kirchhoff summation is allowed to include
Aperture
3000 m by default, constant or varying with time through a time/aperture table. As a rule of thumb, at least the depth of the deepest target multiplied by the maximum expected dip tangent.
Side aperture
A taper band along the survey boundary where the aperture ramps up from zero, so the edges do not end in an abrupt amplitude step.
Max angle aperture
60 degrees by default; 45 to 70 covers most time migration. Steeper apparent dips are dropped from the sum rather than over-migrated.
Anti-aliasing
Off by default. Raising it applies a progressively stronger low-pass on far-offset contributions, working with a 120 Hz default maximum frequency and the inline / crossline bin intervals.
Replacement velocity
1500 m/s by default. Because the migration runs from topography this value must match the replacement velocity used for datum statics, or traces at different elevations mis-tie.
Stretch mute
An optional mute driven by the wavelet stretch factor, which removes the far-offset and shallow contributions the operator distorts most.
Output & compute
What comes out, and what it runs on
Gather type
Common image gathers by offset, common angle gathers for amplitude-versus-angle work, or offset-vector tiles for azimuthal analysis.
Offset classes
Uniform minimum / maximum / increment, or a variable table — dense near offsets and sparse far ones, when the acquisition asks for it.
Normalization
By fold per offset plane by default, or none, per trace or per sample, plus an RMS-velocity normalization that compensates the operator's spreading term for amplitude work.
Execute on
Multi-threaded CPU or CUDA-capable GPU, selected per run. On large 3D the GPU path carries the load, up to around thirty times faster than the same migration on CPU.
Distributed
Cluster execution with each node migrating its own subset of the output bins into the shared output, tuned through a bulk size derived from available GPU memory and the size of one gather.
Test shortcuts
A decimation factor to use every N-th input trace, a boost factor that trades image quality for speed, and a velocity factor for a quick 5% sensitivity check — all back to default for production.
Modules in this group
The time-imaging chain in the g-Platform module tree
Kirchhoff PreSTM — gather in/outKirchhoff PreSTM — file in/outKirchhoff PreSTM — offset modeAzimuthal Kirchhoff PreSTMVelocity selector — PreSTM engine 2D/3DPSTM imaging selector 2DPSTM imaging selector 3DPSTM imaging (eta / VTI)RMO by pickingStack imagingRegularizationShift data & Set topography
More g-Platform capabilities
Time imaging is one link in the chain.
The same project, the same batch processing and the same cluster carry a survey from field tape through to depth. These are the other topics in the g-Platform workflow.
It moves every sample from where it was recorded to where it belongs. The Kirchhoff operator treats each input sample as the apex of a diffraction curve described by the RMS velocity field, sums amplitudes along those curves and places the result at the true reflection point — so diffractions collapse and dipping reflectors move back under their real positions. In g-Platform the migration runs from topography rather than from a flat datum, which is why a replacement velocity matching the one used in your datum statics is a required parameter.
How do I find the right migration velocity?
By migrating with many velocities at once and picking on the results. The velocity selector engine migrates the data repeatedly across a range of velocity factors — 80% to 120% in 10% steps by default — and stores every partial image in a KDB database. The PSTM imaging selector then displays stacked and semblance panels for those percentages so you pick the RMS and delta-Vrms functions that flatten the gathers and focus the stack, manually or with a corridor-constrained auto-picker. RMO by picking refines what is left, scanning a window around the current model and updating it from the picks.
Can g-Platform migrate anisotropic data in time?
Yes, by three routes. The Kirchhoff PreSTM engines take a VTI anisotropy model and modify the travel-time operator when the VTI option is enabled. PSTM imaging computes eta semblance on NMO-corrected common image gathers and produces eta-corrected gathers and stacks after picking. And azimuthal Kirchhoff PreSTM images each azimuth sector separately with its own RMS model, which is how azimuthal anisotropy — fracture orientation and intensity — is measured.
How large a survey can the migration handle?
The file-based engines read traces straight from SEG-Y on disk and accumulate the image bin by bin, so 2D and 3D surveys of any size can be migrated without holding the data in RAM. Work is spread across a cluster with each node taking a subset of the output bins, the kernel runs on CPU or on CUDA-capable GPUs, and an interrupted run resumes from the bins already migrated instead of starting again.
Get started
Migrate your own line and judge the picture.
From regularized gathers through a scanned migration velocity to a production PreSTM volume — take g-Platform for a trial run, or talk to Geomage about your survey.
