|
<< Click to Display Table of Contents >> Navigation: Velocity > Create horizon velocity item |
This module builds a horizon velocity item by combining interpreted stack horizons with a velocity model. For each horizon in the input collection, the module samples the velocity model at every horizon point and then interpolates both the time surface and the velocity surface across the full map grid defined by the input geometry. The result is a multi-layer horizon picking item in which each layer stores both the two-way time of the reflector and the seismic velocity at that location.
Use this module when you need horizon-tied velocity information for depth conversion, interval velocity analysis, or static corrections. The output horizon velocity item can serve as input to depth migration, time-to-depth conversion, or other velocity-dependent workflows. The datum and replacement velocity parameters ensure that velocity sampling is consistently referenced to a flat datum level across the survey area.
A collection of interpreted post-stack time horizons. Each horizon in the collection represents a distinct reflector surface and will produce one layer in the output horizon velocity item. The horizons must be provided as a collection item containing individual horizon point vectors, each point carrying X, Y, and two-way time coordinates. All horizons should be interpreted from the same seismic dataset and geometry area that is supplied in the prepared input geometry input.
The seismic velocity model from which velocity values are sampled at each horizon point. This can be an RMS, interval, or average velocity model in time. The model must cover the lateral extent and the time range of all input horizons. At each horizon point, the module queries the velocity model to retrieve the velocity value at the corresponding X, Y, and two-way time position, which is then stored in the output velocity surface for that layer.
The bin grid that defines the spatial extent and coordinate reference of the output map. This item supplies the X and Y coordinates of all bin centers, which are used to establish the bounding box and the spatial framework for interpolating the time and velocity surfaces. Typically this is the same geometry item used elsewhere in the processing flow for the survey being processed.
The reference datum elevation (in metres) to which the horizon time values are tied when building the output layer. The default value is 0 m, which corresponds to sea level or a flat reference surface at zero depth. If your survey uses a non-zero datum (for example, a floating datum in land processing), set this value to match the datum elevation defined in your statics workflow. The datum value is passed to each horizon layer and is used as a reference when the horizon picking item is later consumed by depth-conversion or static-correction modules.
The velocity (in m/s) used to fill the near-surface layer between the topographic surface and the datum. The default value is 1500 m/s, which is a typical value for water-saturated near-surface sediments or marine water velocity. The minimum allowed value is 150 m/s. In land surveys, set this to the weathering layer velocity or the velocity used for surface-consistent statics. This value is also used internally when computing map interpolation parameters for the topographic surface.
This group controls the spatial grid step used when interpolating the time and velocity surfaces. After the module samples velocity at all known horizon points, it interpolates the scattered data onto a regular grid with the step sizes defined here. Coarser steps produce faster interpolation but lower spatial resolution; finer steps capture more detail but increase computation time.
The grid cell size in the X (inline) direction used for surface interpolation, specified in metres. The default is 75 m, with a minimum of 1 m. Set this to match the typical spatial sampling of your horizon picks or the CDP bin spacing in the X direction. Using a step that is much finer than the horizon pick spacing will not add information but will increase memory and processing time.
The grid cell size in the Y (crossline) direction used for surface interpolation, specified in metres. The default is 75 m, with a minimum of 1 m. Set this to match the CDP bin spacing or horizon pick spacing in the Y direction. For surveys with non-square bin geometry, set Step X and Step Y independently to reflect the actual sampling in each direction.
Selects whether the module runs on the CPU or a GPU accelerator. For most horizon velocity workflows the dataset size is moderate and CPU execution is sufficient. Select GPU only if a compatible GPU is available and the survey contains a very large number of horizons or very dense horizon picks.
Controls whether the job is distributed across multiple compute nodes in a cluster environment. Enable distributed execution when processing very large surveys that benefit from parallel node computation.
Defines the minimum chunk size (number of horizons or data units) assigned to each compute node when distributed execution is active. Larger values reduce inter-node communication overhead; smaller values allow finer load balancing across nodes.
When enabled, restricts the number of processing threads used on each remote compute node. Use this setting to avoid overloading nodes that are shared with other jobs or that have limited memory per core.
An optional text label appended to the job name when submitting to a cluster scheduler. Use this to distinguish multiple concurrent runs of the same module, for example when testing different parameter settings in parallel.
When enabled, allows manual specification of the CPU core affinity mask for the job. This is an advanced option for performance tuning on NUMA (Non-Uniform Memory Access) systems where binding threads to specific CPU cores can reduce memory latency.
Specifies the CPU core affinity mask when Set custom affinity is enabled. Enter the affinity value appropriate for your hardware configuration. This parameter is visible only when Set custom affinity is turned on.
Sets the number of CPU threads used for parallel processing. The surface interpolation steps for each horizon layer (both the time surface and the velocity surface) are executed in parallel across the available threads. Increasing the thread count reduces computation time on multi-core workstations. Set this to the number of physical cores available for this job.
When enabled, this module is bypassed and its output is passed through unchanged from the previous step in the processing flow. Use this option to temporarily disable the module during parameter testing without removing it from the workflow.
The output horizon velocity item containing one layer per input horizon. Each layer stores two interpolated surfaces: a two-way time surface describing the geometry of the reflector across the survey area, and a velocity surface containing the seismic velocity sampled from the input velocity model at each map node. This item can be used directly as input to depth conversion, interval velocity extraction, or other velocity-dependent processing modules that require horizon-tied velocity information.