|
<< Click to Display Table of Contents >> Navigation: Velocity > Depth velocity inversion |
Depth velocity inversion builds or updates a 3D interval velocity model in depth by inverting stacking (VRMS) velocities. The module starts from an initial depth velocity model — either a user-supplied model or a constant-velocity volume — and iteratively adjusts the interval velocities until the VRMS velocities predicted by the model closely match the observed VRMS input. At each iteration, a fast-marching eikonal solver traces rays through the current model to compute predicted travel times, a slowness perturbation is then estimated by solving a linear system using either an LSQR or Split-Bregman solver, and the model is updated. The best model encountered across all iterations (lowest average time error) is retained as the final output.
Use this module to create a starting depth velocity model for Pre-Stack Depth Migration (PSDM), to refine an existing model using updated velocity picks, or to convert a time-domain VRMS velocity field into a physically consistent interval velocity volume. The output depth model can serve directly as input to Kirchhoff or other depth migration algorithms.
Connect the input RMS (stacking) velocity gather here. This is the target that the inversion attempts to match: the module traces synthetic rays through the updated interval velocity model at each iteration and computes a predicted VRMS field, which is compared against this input. The gather must be in the time domain and formatted as a velocity gather (one velocity trace per bin). Typically this comes from interactive velocity picking on semblance panels.
When enabled, the inversion begins with a laterally homogeneous constant-velocity model rather than a pre-existing depth velocity volume. The geometry (bin positions), depth sampling, and starting velocity are defined by the Datum, Output sample rate, Output samples, and V0 parameters. When disabled, the Initial model input must be connected. Default: disabled.
The reference elevation (in metres) at which the constant starting model begins. Only active when Start from constant model is enabled. The datum must be at or above the surface topography; the module will report an error if any source or receiver elevation exceeds the datum. Default: 0 m.
Vertical sample interval of the output depth velocity model, in metres per sample. Only active when Start from constant model is enabled. Finer sampling captures more vertical velocity detail but increases memory and computation time. Default: 10 m. Minimum: 0.1 m.
Number of depth samples in the output velocity model. Together with Output sample rate, this defines the total depth extent of the model (total depth = samples × sample rate). Only active when Start from constant model is enabled. Default: 500 samples. Minimum: 1.
Connect an existing depth interval velocity model to use as the starting point for the inversion. This is the recommended approach when a prior PSDM velocity model exists, as the inversion will refine it rather than building from scratch. Only active when Start from constant model is disabled. The model must be on a constant datum: all traces must share the same datum elevation.
When enabled, the near-surface velocity (V0) used for fast-marching initialisation is taken from the first time sample of the VRMS input at each bin location, producing a spatially variable V0 map. When disabled, a single constant velocity value specified in the V0 parameter is used everywhere. Enable this option when near-surface velocities vary laterally and the first VRMS picks are reliable. Default: disabled.
Constant near-surface velocity (in m/s) used to initialise the fast-marching travel-time solver. This value seeds the ray tracing at the datum level. Only active when Construct V0 map from VRMS is disabled. Use a value representative of the weathered layer or near-surface velocity. Default: 1500 m/s. Minimum: 330 m/s.
Grid cell size (in metres) used by the eikonal fast-marching solver when computing travel-time fields through the velocity model. Smaller values produce more accurate travel times but require more computation. Larger values speed up processing at the cost of ray-path accuracy. Typical values range from 5 to 50 m depending on the model complexity and required resolution. Default: 5 m. Range: 0.1 to 100 m.
Controls how many inversion cycles are performed. In each global iteration, the module re-traces rays through the current model, computes the VRMS misfit, solves for a slowness update, and applies it. The model with the lowest average time error across all iterations is saved as the final result. More iterations generally improve the fit to the VRMS data but increase run time. If an iteration produces a worse result than the best so far, the step scale is automatically halved to improve stability. Default: 10. Minimum: 1.
Controls the magnitude of the velocity update applied at each global iteration. A smaller step scale produces more conservative updates and more stable convergence, while a larger value results in faster but potentially less stable convergence. The module automatically halves this value if an iteration worsens the model fit. Default: 0.05. Minimum: 0.
Selects the linear inversion algorithm used to compute the slowness update at each global iteration.
LSQR (default): A least-squares iterative solver with Tikhonov regularisation. It minimises the sum of squared misfit plus lateral (X/Y) and vertical (Z) smoothness constraints. Use LSQR for most datasets. The solver parameters are Number of LSQR iterations, LSQR Tikhonov lambda X/Y, and LSQR Tikhonov lambda Z.
Split-Bregman: An L1-regularisation solver that promotes sparse or piecewise-constant velocity updates, which can sharpen layer boundaries. Use Split-Bregman when distinct geological boundaries are expected and sharper velocity contrasts are desired. Its parameters are Split-Bregman global iterations, Split-Bregman local iterations, Split-Bregman epsilon X/Y, and Split-Bregman epsilon Z.
Number of inner LSQR conjugate-gradient iterations used to solve the linear system at each global iteration. More iterations produce a more accurate solution to the linear system but at the cost of increased computation per global step. For well-conditioned problems, convergence is typically achieved within a few hundred iterations. Only active when Solver is set to LSQR. Default: 1000. Minimum: 1.
Lateral (horizontal) smoothness regularisation weight for the LSQR solver. Higher values enforce stronger lateral smoothing of the velocity update, suppressing oscillatory artefacts and producing geologically plausible, laterally continuous models. Lower values allow more lateral heterogeneity but may introduce noise. Increase this value if the output model shows lateral instability. Only active when Solver is LSQR. Default: 100. Minimum: 0.
Vertical smoothness regularisation weight for the LSQR solver. Controls how strongly the velocity update is smoothed in the depth direction. A lower value relative to the X/Y lambda allows sharper vertical velocity gradients while still enforcing lateral continuity. Only active when Solver is LSQR. Default: 10. Minimum: 0.
Number of outer Bregman iterations in each application of the Split-Bregman solver. Each outer iteration updates the auxiliary variable that enforces L1 sparsity. More global Bregman iterations improve convergence of the sparse regularisation but increase the cost of each inversion step. Only active when Solver is Split-Bregman. Default: 3. Minimum: 1.
Number of inner LSQR iterations performed within each outer Split-Bregman iteration. These inner iterations solve the quadratic sub-problem that arises from the Bregman splitting. Increasing this value improves the accuracy of each sub-problem solution. Only active when Solver is Split-Bregman. Default: 5. Minimum: 1.
Lateral regularisation strength parameter for the Split-Bregman solver. Higher values enforce stronger lateral smoothing of the velocity update, similar in effect to the LSQR Tikhonov lambda X/Y. Only active when Solver is Split-Bregman. Default: 100. Minimum: 0.
Vertical regularisation strength parameter for the Split-Bregman solver. Controls how much the L1 constraint suppresses rapid vertical velocity variations in the update. Only active when Solver is Split-Bregman. Default: 10. Minimum: 0.
A depth-dependent table that defines physically acceptable velocity bounds. Each row specifies a Start depth (m), a Min velocity (m/s), and a Max velocity (m/s) valid from that depth down to the next row. The inversion clamps all updated velocity values within these limits, preventing geologically unrealistic results. Default bounds: 1500–7000 m/s starting at 0 m depth. Only visible when Use corridor based on input model is disabled.
This group contains parameters that control the spatial sampling grids used internally for ray tracing, VRMS computation, and the inversion update. These settings directly affect both result quality and computation time. Coarser grids run faster but may miss fine-scale velocity structure.
Lateral grid spacing (in metres) used when computing the synthetic VRMS field from the current model. This parameter is currently reserved for internal use and is not visible in the user interface. Default: 500 m.
Vertical grid spacing (in metres) used when computing the synthetic VRMS field from the current model. This parameter is currently reserved for internal use and is not visible in the user interface. Default: 500 m.
Minimum source-receiver offset (in metres) to include when computing the synthetic VRMS at each bin. Rays with offsets below this threshold are excluded. This prevents near-offset contamination where ray paths are nearly vertical and provide little constraint on lateral velocity variation. Default: 250 m. Minimum: 50 m.
Maximum source-receiver offset (in metres) to include when computing the synthetic VRMS. Rays beyond this offset are excluded. Setting an appropriate maximum prevents long-offset rays from travelling outside the model boundaries or through poorly sampled regions. Default: 2500 m. Minimum: 50 m.
Lateral spacing (in metres) of the internal variable-density grid on which the slowness update is computed and stored before interpolation back to the model grid. A finer variable grid captures more lateral detail in the velocity update but requires more memory and computation. Default: 200 m. Minimum: 1 m.
Vertical spacing (in metres) of the internal variable-density grid. Controls the depth resolution of the slowness update before it is mapped back onto the output velocity model. Default: 200 m. Minimum: 1 m.
Lateral grid spacing (in metres) of the ray-equation grid used to formulate the forward problem (system of equations relating slowness to travel-time). This grid is the basis of the linear system that the LSQR or Split-Bregman solver operates on. A finer ray grid produces more accurate forward modelling but increases the size of the linear system significantly. Default: 100 m. Minimum: 1 m.
Vertical grid spacing (in metres) of the ray-equation grid. Controls the depth resolution of the linear forward system. Together with Ray grid step X/Y, this determines the total number of unknowns in the inversion. Default: 100 m. Minimum: 1 m.
Increment (in metres) between successive offset values used during ray tracing. The module traces rays for a series of offsets from the minimum to maximum aperture at each bin. Smaller offset steps sample the offset axis more densely, improving the accuracy of the VRMS integration over offset, at the cost of more ray traces per bin. Default: 100 m. Minimum: 1 m.
This group contains advanced options for constraining the inversion. These settings control how the module limits the range of velocity values that the solver is allowed to produce, providing geological control over the inversion result.
When enabled, velocity bounds from the corridor (either from the input model corridor or the interval velocity table) are enforced during the LSQR solve itself, not just as a post-processing clamp. This produces strictly bounded updates at the cost of additional computation. When disabled, the bounds are applied as a clamp after each LSQR solve. Default: disabled.
When enabled, the velocity bounds applied during the inversion are derived automatically from the initial model: at each depth and location, velocities are constrained to lie within a relative percentage corridor centred on the initial model value. The corridor width is set by the Corridor width parameter. When disabled, bounds are taken from the user-defined Interval velocity table. Default: enabled.
Width of the velocity corridor as a fraction (0 to 1) of the initial model velocity. For example, a value of 0.2 means velocities are constrained to within ±20% of the initial model value at each point. Narrower corridors keep the inversion close to the prior model (useful when the prior is reliable), while wider corridors allow larger updates. Only active when Use corridor based on input model is enabled. Default: 0.2 (20%). Range: 0 to 1.
This group controls which inline, crossline, and depth slices of the evolving velocity model are displayed in the real-time monitoring views during processing. Setting these values allows you to monitor convergence at specific locations of interest without waiting for processing to complete.
Inline number displayed in the real-time model inline slice view during processing. The module updates the displayed velocity section and time-error section for this inline after each global iteration. Set this to a representative inline through the area of interest. Default: 1.
Crossline number displayed in the real-time model crossline slice view. Set to a line that crosses key geological features to monitor whether the inversion is resolving them correctly. Default: 1.
Depth level (in metres) of the horizontal map slice displayed in the real-time depth slice views. Use this to monitor lateral velocity variations and time-error patterns at a target depth during the inversion. Default: 0 m.
When enabled, the velocity model at the end of each global iteration is written to a separate SEG-Y file. This allows you to review the model evolution iteration by iteration, diagnose convergence issues, or roll back to an earlier iteration if the final result is over-iterated. Files are named using the Name prefix followed by _iter0, _iter1, etc. and saved to the Save path directory. Default: disabled.
Directory path where intermediate SEG-Y velocity model files are saved. The specified folder must already exist before running the module; otherwise processing will stop with an error. Only active when Save intermediate results to SEG-Y is enabled.
Text prefix prepended to each intermediate SEG-Y file name. For example, a prefix of "model" produces files named model_iter0.sgy, model_iter1.sgy, and so on. Must not be empty when intermediate saving is enabled. Only active when Save intermediate results to SEG-Y is enabled. Default: "model".
Selects whether the ray-tracing and inversion computations run on the CPU or on a CUDA-capable GPU. GPU execution can substantially accelerate the fast-marching travel-time solver and the ray summation steps for large models. Select GPU only if a compatible GPU is available on the processing node.
Enables distributed processing across multiple compute nodes. When active, the module distributes inversion sub-problems (inline and crossline chunks of the model) across remote nodes for parallel execution.
Minimum number of model lines (inline or crossline slices) per distributed processing chunk. Larger chunks reduce communication overhead but may cause uneven load distribution between nodes.
Controls the number of CPU threads used for multi-threaded processing. Increasing the thread count can significantly reduce run time for large models on multi-core workstations. Leave at the default to use all available CPU cores.
When enabled, this module is bypassed during flow execution. No processing is performed and no output is written. Use this to temporarily disable the inversion step without removing it from the processing flow.
The output depth interval velocity model — a gather in the depth domain with one velocity trace per bin. This is the best model found across all global iterations, defined as the model with the lowest average predicted-vs-observed VRMS time error. Connect this output to a depth migration module or to the Initial model input of a subsequent inversion run for iterative model building. The model is stored on the same constant datum as the initial model input.
Displays the estimated total number of processing chunks (inline + crossline model slices) that will be distributed across nodes. Populated automatically by the Calculate number of chunks action. Read-only.
Displays the estimated memory size of each chunk, to help plan distributed processing resource requirements. Populated automatically by the Calculate number of chunks action. Read-only.
The module provides the following real-time visualisation views, updated after each global iteration:
Model slices inline / crossline: Shows the current and best velocity model sections along the inline and crossline directions defined by the Inline to show and Crossline to show parameters. The best model (lowest error) is highlighted separately from the history of all intermediate models.
Time error slices inline / crossline: Displays the residual between predicted and observed VRMS travel times along the same sections. Areas with large residuals indicate where the model still needs improvement.
Model depth slices and Time error depth slices: Horizontal map views of the velocity model and time error at the depth level set by Depth slice to show.
Convergence chart: Plots the average RMS time error as a function of iteration number. A steadily decreasing curve indicates healthy convergence. A stagnating or increasing curve suggests over-iteration, excessive step scale, or insufficient model freedom (corridor too narrow).
Selected bin / All bins: Map views showing the spatial distribution of all input bins and the currently selected bin for detailed inspection.
Run this action before executing the module in distributed mode to estimate the number of processing chunks and their approximate size. The results are displayed in the Expected number of chunks and Approximate chunk size information fields. Use this to verify that the job will fit within available memory on each node and to plan the number of distributed computing resources needed.