Depth velocity updater

<< Click to Display Table of Contents >>

Navigation:  Velocity >

Depth velocity updater

 

Description

The Depth velocity updater refines a 3D interval velocity model in the depth domain using tomographic inversion of residual move-out (RMO) information. It is designed for iterative velocity model building in pre-stack depth migration (PSDM) workflows: starting from an initial interval velocity model and a set of measured velocity residuals (the delta-M or delta-Vrms field), the module computes a corrected velocity volume that minimizes the time-domain mismatch between observed and modeled reflection travel times.

The inversion is performed on a two-level grid: a fine ray-equation grid controls how the velocity update is propagated along ray paths using the Ricatti equation solver, while a coarser variable grid holds the slowness (inverse velocity) perturbation solved by either LSQR or Split-Bregman regularized linear inversion. The module iterates globally, checking the residual error after each update step and retaining only improvements; if an iteration worsens the model the step scale is automatically halved. Velocity bounds are enforced throughout via a user-defined corridor that can be derived automatically from the input model or specified manually as a depth-velocity table.

Use this module after common image gather (CIG) analysis and residual velocity picking to update the depth velocity model before re-migrating. Typical use involves connecting the current migration velocity model as the Input model, the picked velocity residuals as the Delta M or Delta Vrms input, and the original starting model as the Original model (used for datum handling and transformation). GPU execution is supported and recommended for large 3D volumes.

Input data

Input model

The current 3D interval velocity model to be updated, provided as a depth-domain velocity gather (VistaGatherSettingsVelocity). This is typically the velocity volume produced by the most recent depth migration pass. The model defines the spatial extent and sample grid for the output: the updated velocity will have the same trace layout and depth sampling as this input. This input is mandatory; if not connected the module will report an error.

Delta M picking gather

A depth-domain gather containing the measured velocity residual field (delta-M), expressed as the difference between the current model velocity and the velocity required to flatten the common image gathers. Connect this input when the residuals are available as a seismic-format gather volume. Either this input or the Delta Vrms picking item (below) must be connected; connecting both is allowed and the gather takes precedence. The gather trace lengths must be compatible with the Input model depth extent (within a factor of ten).

Delta Vrms picking item

A structured velocity-picking item (GDVrmsPickingItem / GVerticalVelocityPickingItem) that carries the spatially distributed residual RMS-velocity corrections. Use this input when the residuals have been picked interactively in a velocity analysis session and stored as a picking object rather than a gather. If both this item and the Delta M gather are connected, the gather takes precedence.

Original model

The reference velocity model used to define the survey datum and the global-to-local coordinate transformation applied during ray tracing. This is typically the very first (starting) velocity model in the depth migration workflow, before any updates. Providing the correct original model ensures that datum corrections are consistent across iterations. The spatial extent used for grid sizing is taken as the maximum of the Input model and Original model extents.

Parameters

Construct V0 map from model

When enabled, the near-surface starting velocity (V0) used by the fast-marching travel-time solver is extracted automatically from the top layer of the Input model at each surface location, producing a laterally varying V0 map. This is the recommended setting for surveys with significant lateral near-surface velocity variation. When disabled, the single constant value specified in the V0 parameter below is used everywhere. Default: disabled (constant V0).

V0

The constant near-surface velocity (m/s) used as the starting velocity for the fast-marching Eikonal solver when Construct V0 map from model is disabled. It represents the velocity at the datum surface from which ray paths originate. Set this to the approximate replacement velocity used during datum static corrections. Default: 1500 m/s. Minimum: 330 m/s. This parameter is hidden when V0 map construction is enabled.

Fast marching step

The spatial grid spacing (m) of the internal fast-marching travel-time computation used to map depth coordinates to two-way travel time. Smaller values produce more accurate travel-time tables but increase memory and computation time significantly. For typical production surveys a value of 5–10 m is sufficient; use smaller values (1–3 m) only when very precise near-surface travel-time accuracy is required. Default: 5 m. Range: 0.1–100 m.

Number of global iterations

The number of outer tomographic update cycles to run. In each global iteration the module solves for a slowness perturbation, applies it to the current model, recomputes the travel-time residuals, and decides whether to keep or reject the update. More iterations allow larger cumulative velocity corrections but increase run time proportionally. Monitor the Convergence chart vista to assess when further iterations no longer improve the residual. Default: 10. Minimum: 1.

Step scale

A scaling factor (0 to 1) applied to the computed slowness perturbation before adding it to the current model. Values smaller than 1 produce more conservative, incremental updates and improve stability when the residual field is noisy or the model is sensitive. If an iteration worsens the residual error the module automatically halves this value for the subsequent iteration. Start with the default value of 0.5 and reduce it (e.g., to 0.2–0.3) if the inversion oscillates or produces artifacts. Default: 0.5.

Regularization type { Current update, Cumulative update, Result model }

Controls which velocity field the Tikhonov (or Split-Bregman) regularization term is applied to, determining the smoothness constraint behavior across iterations:

Current update — regularizes only the slowness perturbation computed in the current iteration. This is the most common choice and produces smooth incremental updates without constraining the total model shape. Default.

Cumulative update — regularizes the sum of all updates applied so far. This tends to produce smoother final models but may slow convergence when large corrections are needed.

Result model — applies the regularization constraint directly to the updated velocity model itself. Use this option when the absolute smoothness of the output model is more important than the smoothness of individual updates.

Solver { LSQR, Split-Bregman }

Selects the linear solver used to compute the slowness perturbation from the travel-time residual equations.

LSQR — an iterative least-squares solver with Tikhonov (L2) regularization applied separately in the lateral (X/Y) and vertical (Z) directions. This solver is robust and converges quickly for smooth residual fields. It exposes the Number of LSQR iterations, LSQR Tikhonov lambda X/Y, and LSQR Tikhonov lambda Z parameters. Default and recommended for most workflows.

Split-Bregman — an L1-based regularization solver that promotes piecewise-constant (blocky) velocity models and is well-suited when sharp velocity boundaries are expected, such as at salt interfaces or unconformities. It exposes Split-Bregman-specific iteration and epsilon parameters instead of the LSQR parameters.

Number of LSQR iterations

The number of inner conjugate-gradient iterations performed by the LSQR solver within each global update cycle. More iterations allow the solver to converge to a more accurate solution of the linearized system but increase computation time per global iteration. Typically 50–200 iterations are sufficient. Visible only when Solver is set to LSQR. Default: 100. Minimum: 1.

LSQR Tikhonov lambda X/Y

The lateral (horizontal) Tikhonov regularization weight for the LSQR solver. Larger values impose stronger lateral smoothing on the velocity update, suppressing short-wavelength lateral variations that may be caused by acquisition footprint or sparse ray coverage. Reduce this value when the survey has dense, uniform coverage and you want to resolve fine lateral velocity features. Increase it for sparse or irregular geometries. Default: 1.0. Minimum: 0. Visible only when Solver is LSQR.

LSQR Tikhonov lambda Z

The vertical Tikhonov regularization weight for the LSQR solver. Larger values enforce smoother vertical velocity gradients in the update. In many geological settings the vertical velocity structure is expected to be gradational, so this value can often be kept equal to or slightly larger than the lateral lambda. Reduce it when resolving thin high-contrast layers is important. Default: 1.0. Minimum: 0. Visible only when Solver is LSQR.

Split-Bregman global iterations

The number of outer Bregman update cycles within the Split-Bregman solver for each global tomographic iteration. Each outer cycle updates the auxiliary L1 variable and Lagrange multipliers. More outer cycles improve convergence of the L1 constraint but increase computation time. Default: 3. Minimum: 1. Visible only when Solver is Split-Bregman.

Split-Bregman local iterations

The number of inner conjugate-gradient iterations used to solve the L2 sub-problem within each Split-Bregman outer cycle. Increase this if the inner sub-problem is not converging adequately (visible as oscillation in the convergence chart). Default: 5. Minimum: 1. Visible only when Solver is Split-Bregman.

Split-Bregman epsilon X/Y

The lateral penalty weight (mu parameter) for the Split-Bregman solver, controlling the strength of the lateral L1 sparsity constraint. Larger values enforce more abrupt lateral transitions in the velocity update. Tune this together with the vertical epsilon to balance lateral versus vertical edge preservation. Default: 1.0. Minimum: 0. Visible only when Solver is Split-Bregman.

Split-Bregman epsilon Z

The vertical penalty weight for the Split-Bregman solver, controlling the strength of the vertical L1 sparsity constraint. Increase this to preserve sharper impedance contrasts at depth horizons. Default: 1.0. Minimum: 0. Visible only when Solver is Split-Bregman.

Grid parameters

This group controls all spatial grid spacings and aperture limits used by the ray-tracing and tomographic inversion grids. These parameters directly affect both the accuracy of the velocity update and the computation time and memory requirements. Use the Calculate number of chunks custom action to estimate the memory footprint before running.

Min solver depth

The shallowest depth (m) at which velocity updates are computed and applied. Setting a positive minimum depth prevents the inversion from modifying the near-surface interval, which is often constrained by refraction statics or first-break tomography and should not be altered by reflection tomography. The effective minimum is clamped to the top of the Input model. Default: -9999 m (no restriction; updates begin at the top of the model).

Max solver depth

The deepest depth (m) at which velocity updates are computed and applied. The effective maximum is clamped to the bottom of the Input model. Restricting the depth range reduces computation time and avoids spurious updates in poorly illuminated deep zones. Default: 9999 m (no restriction; updates extend to the bottom of the model).

Update taper size

The depth (m) over which the velocity update is tapered to zero at the boundaries of the solver depth range (Min and Max solver depth). A non-zero taper prevents sharp discontinuities at the edges of the update zone. Set this to a value comparable to 2–3 times the expected vertical wavelength of the velocity anomaly. Default: 0 m (no taper applied). Minimum: 0.

Source line step X/Y

The lateral grid spacing (m) of the fine equation grid used for ray-path integration via the Ricatti equation. This grid determines the spatial resolution at which ray paths are traced and the velocity update is propagated along each ray. Smaller values improve accuracy but increase memory and run time. Typical values are 200–1000 m, depending on the survey aperture and desired resolution. Default: 500 m. Minimum: 1 m.

Min aperture

The minimum lateral search radius (m) around each CMP location within which travel-time data are collected for the inversion. Ray paths shorter than this distance are excluded. This prevents very short-offset, near-vertical rays from dominating the tomographic system (which would provide poor depth resolution). Default: 500 m. Minimum: 50 m.

Max aperture

The maximum lateral search radius (m) around each CMP location from which travel-time data are included. Rays originating beyond this distance are excluded. Limiting the aperture prevents far-offset, shallow-angle rays from introducing noise or artifacts from the edges of the illuminated zone. Set this to approximately half the maximum meaningful offset for the target depth. Default: 2500 m. Minimum: 50 m.

Variable grid step X/Y

The lateral grid spacing (m) of the coarse inversion grid on which the slowness perturbation is solved. This is the resolution of the output velocity update in the horizontal directions. Larger values produce smoother, lower-resolution updates and are appropriate when ray coverage is sparse. Smaller values allow the inversion to resolve finer lateral features but require denser ray coverage and more memory. Default: 200 m. Minimum: 1 m.

Variable grid step Z

The vertical grid spacing (m) of the coarse inversion grid on which the slowness perturbation is solved. This determines the vertical resolution of the velocity update. Set this to a value consistent with the vertical resolution of the residual velocity field — typically 100–500 m for reflection tomography. Default: 200 m. Minimum: 1 m.

Equation step Z

The vertical step size (m) used when integrating the ray-path equations (Ricatti equations) through the velocity model. This controls the accuracy of the depth-to-time mapping along each ray. Smaller values improve accuracy at the cost of more computation. For most surveys 25–100 m is appropriate; use finer values only when the velocity model has strong vertical gradients or thin high-velocity layers. Default: 50 m. Minimum: 1 m.

Offset step

The lateral sampling interval (m) along each ray path used when accumulating the slowness sensitivity kernel (Frechet derivatives). Smaller values sample the ray more densely, improving sensitivity accuracy, but increase memory for the ray-parameter storage array. Default: 50 m. Minimum: 1 m.

Interval velocity table

A depth-indexed table of minimum and maximum allowable interval velocities that constrains the inversion result when Use corridor based on input model is disabled. Each row defines a depth zone with its velocity bounds. Add rows to cover the full depth range of the model. The default row has Start depth 0 m, Min velocity 1500 m/s, Max velocity 7000 m/s. This parameter group is hidden when the model-based corridor is active.

Advanced

Contains advanced options for the LSQR solver constraint mode and the velocity corridor definition method. Expand this group to access the constrained-solver toggle and corridor settings.

Use constrained LSQR solver

When enabled, the LSQR solver enforces the velocity corridor bounds (Min/Max corridor) as hard constraints during the inversion, so that the solved slowness perturbation cannot push the updated model outside the allowed range. When disabled, the bounds are applied as a post-processing clamp after each update. Constrained mode is more conservative and prevents overshoot but may slow convergence. Default: disabled.

Use corridor based on input model

When enabled (default), the minimum and maximum allowable velocities at each model cell are derived automatically from the Input model by applying a percentage-based corridor: the minimum corridor is the input velocity minus the corridor width, and the maximum is the input velocity plus the corridor width. This approach keeps the updated model physically close to the prior model and prevents runaway updates. When disabled, the velocity bounds must be specified manually using the Interval velocity table. Default: enabled.

Corridor width

The fractional (percentage as a fraction of 1) deviation from the Input model velocity that defines the allowed corridor when Use corridor based on input model is enabled. For example, a value of 0.2 means the updated velocity may differ from the input model by at most ±20% at each location. Start with a conservative value (0.1–0.2) and increase it if the inversion requires larger corrections than the prior model allows. Default: 0.2 (20%). Range: 0–1. Visible only when model-based corridor is active.

Visualization

Controls which inline, crossline, and depth slices are displayed in the vista panels during and after processing, and whether intermediate model iterations are saved to disk as SEG-Y files. These settings do not affect the computed velocity model.

Inline to show

The inline number to extract and display as a 2D depth section in the Model inline slices and Time error inline slices vista panels after each iteration. Set this to an inline that crosses the main area of interest to monitor convergence spatially. Default: 1.

Crossline to show

The crossline number to extract and display as a 2D depth section in the Model crossline slices and Time error crossline slices vista panels. Default: 1.

Depth slice to show

The depth (m) of the horizontal slice extracted and displayed in the Model depth slices and Time error depth slices map-view panels. Default: 0 m (top of the model).

Save intermediate results to SEG-Y

When enabled, the updated velocity model after each global iteration is saved as a separate SEG-Y file. This allows you to examine the model evolution across iterations and to select the best intermediate result if the final model has overshot. Files are named using the specified prefix followed by the iteration index (e.g., model_iter0.sgy, model_iter1.sgy, ...). Default: disabled. Enabling this also reveals the Save path and Name prefix parameters.

Save path

The directory where intermediate SEG-Y model files will be written. The directory must already exist; the module will report an error if it is not found at execution time. Visible only when Save intermediate results to SEG-Y is enabled.

Name prefix

The filename prefix for intermediate SEG-Y files. Each file will be named as prefix_iter<N>.sgy, where N is the zero-based iteration index. Use a meaningful prefix such as the project or area name. Default: "model". Visible only when intermediate saving is enabled.

Settings

Execute on { CPU, GPU }

Selects whether the tomographic computation runs on the CPU or on a CUDA-capable GPU. GPU execution can substantially accelerate the fast-marching and ray-tracing stages for large 3D models. GPU mode requires a compatible NVIDIA graphics card and appropriate driver installation. Default: CPU.

Distributed execution

Enables distributed (cluster) execution, allowing the inversion to be split across multiple computing nodes for large surveys. Configure cluster node addresses and credentials in the g-Platform distributed computing settings before enabling this option.

Bulk size

The size of each distributed processing chunk. Larger chunks reduce network overhead but require more memory per node. Use the Calculate number of chunks action to determine the recommended chunk count before adjusting this value.

Limit number of threads on nodes

When enabled, restricts the number of CPU threads used per distributed node. Useful to prevent the job from consuming all cores on shared cluster machines.

Job suffix

An optional text label appended to distributed job names to distinguish simultaneous runs of this module on the same cluster.

Set custom affinity

When enabled, allows manual specification of the CPU core affinity mask for thread scheduling. Use this on NUMA systems to pin the job to specific processor sockets for better memory locality.

Affinity

The CPU affinity mask value when custom affinity is enabled. Consult your system administrator for the appropriate bitmask for your hardware configuration.

Number of threads

The number of CPU threads used for parallel processing on the local machine. By default this is set to the number of logical cores detected on the system. Reduce it to leave cores available for other applications running simultaneously.

Run scripts

Optional shell scripts that run automatically before and after the module executes. Use these to automate pre-processing steps (e.g., copying input data) or post-processing steps (e.g., archiving results).

Script before run

Path to a script file that is executed before the module starts processing. The module waits for this script to complete before beginning.

Script after run

Path to a script file that is executed after the module finishes processing. Use this for notification, archiving, or chaining downstream tasks.

Skip

When enabled, the module is bypassed entirely during flow execution and passes its input through to the output unchanged. Use this to temporarily disable the velocity update step without removing the module from the processing flow.

Output data

Output model

The updated 3D interval velocity model in the depth domain, produced after all global iterations are complete. The output model has the same spatial layout and depth sampling as the Input model. Only the iteration that achieved the lowest travel-time residual error is retained: if a later iteration worsens the error the module keeps the previous best result. Connect this output to the depth migration module to run the next PSDM pass with the improved velocity model.

Information

Expected number of chunks

A read-only field populated by the Calculate number of chunks custom action. It reports how many processing sub-tasks the inversion will be split into when running in distributed mode, derived from the number of inline and crossline grid slices. Use this to plan distributed job allocation.

Approximate chunk size

A read-only field populated by the Calculate number of chunks custom action. It displays the estimated total memory footprint of one processing chunk in human-readable units (e.g., "2.4 GB"). Use this to verify that each compute node has sufficient RAM before launching a distributed run.

Graphics

Custom actions

Calculate number of chunks

Run this action before executing the module to estimate the number of distributed processing chunks and the approximate memory per chunk, given the current grid parameter settings and the connected input models. The results are written to the Expected number of chunks and Approximate chunk size information fields. This is particularly useful before distributed runs to confirm that the selected grid spacings are feasible within the available node memory. Both the Input model and Original model must be connected before running this action.