|
<< Click to Display Table of Contents >> Navigation: Velocity > Extract 2D velocity line form 3D |
This module extracts a 2D velocity profile from a 3D velocity model by slicing along a user-defined 2D line path. The result is a 2D velocity gather that follows the trace positions described by the stack line, capturing the velocity information from the 3D volume at those locations. This is useful when you need to derive a 2D interval or average velocity model for a crooked 2D line that runs through an area covered by a 3D survey.
Two extraction methods are available, selected by the Alternative parameter. The standard method performs a direct geometric slice through the 3D volume using the bin positions of the stack line. The alternative method uses bilinear spatial interpolation across the 3D model grid, producing a smoother result when the stack line does not fall exactly on 3D grid nodes. The output gather preserves the domain (time or depth) of the input 3D velocity model.
The source 3D velocity model from which the 2D profile will be extracted. Connect a velocity gather item covering the full 3D survey area. The model may be in either time or depth domain — set the Domain parameter to match. When the Alternative extraction method is used, the module reads the bin grid geometry and datum from this item to set up the bilinear interpolation grid. The 3D model must have a regular rectangular bin layout; irregular geometries will cause an error.
The 2D line geometry that defines which locations to sample from the 3D velocity volume. This is a bin point vector item (typically created by the Create Stack Line module) representing the CMP positions of the 2D line as it traverses the 3D survey area. The module visits each bin point in order and extracts the corresponding velocity trace from the 3D model. The number of traces in the output gather equals the number of bin points in this item.
Selects the extraction algorithm. Default: enabled (true).
When enabled, the module uses bilinear spatial interpolation. For each bin point on the stack line, the four nearest 3D model traces are identified and their velocity values are blended using distance-weighted bilinear weights. This produces a smoother result when the 2D line does not coincide exactly with 3D grid nodes, and is the recommended mode for most workflows. The SetDatum parameter is active only in this mode.
When disabled, a direct geometric slice is performed: the 3D model is treated as a 3D matrix and the stack line bin positions are used to extract traces directly via nearest-bin lookup. This is faster but may show staircase artefacts if the 2D line cuts obliquely across coarse 3D inline/crossline spacing. The Domain parameter is active only in this mode.
Controls whether the reference datum from the 3D velocity model is copied to all traces in the output 2D gather. Default: enabled (true). This parameter is active only when Alternative is enabled.
When enabled, the datum value stored in the first trace of the 3D velocity model is assigned to both the source datum and receiver datum fields of every output trace. Enable this option when subsequent processing steps (such as static correction or depth conversion) require a consistent datum reference, and when the 2D line shares the same datum as the 3D survey. Disable it if the 2D line has its own distinct datum that must be preserved from the stack line geometry.
Specifies whether the 3D input velocity model is in the depth domain or the time domain. Default: Depth. This parameter is active only when Alternative is disabled.
Set this to Depth if your 3D velocity model uses depth (metres) as the vertical axis — for example, an interval velocity model in depth domain from PSDM processing. Set this to Time if the model uses two-way travel time (milliseconds) as the vertical axis — for example, an RMS velocity model from PSTM analysis. The setting must match the actual domain of the connected 3D model; a mismatch will produce incorrectly scaled velocity traces in the output.
Selects the processing hardware. For this module, CPU execution is standard. GPU mode is not applicable to velocity extraction and can be left at its default value.
Enables or configures distributed (cluster) processing. This module processes a single 2D velocity profile and does not require distributed execution in typical use.
Controls the number of traces processed in each internal work chunk. The default value is appropriate for most datasets.
When distributed execution is active, limits the number of CPU threads used on each compute node to avoid overloading shared resources.
An optional text label appended to the job name in distributed execution logs, useful for distinguishing multiple simultaneous runs.
Enables manual specification of CPU core affinity for thread scheduling. Leave disabled unless your system administrator has advised a specific affinity configuration.
Specifies the CPU core affinity mask when custom affinity is enabled. Active only if Set custom affinity is turned on.
Sets the number of CPU threads used during execution. The default (all available cores) is appropriate for most cases. Reduce this value if you need to leave processing capacity for other applications running concurrently.
When enabled, this module is bypassed and the workflow continues without executing this step. Use this option to temporarily disable the extraction without removing the module from the processing sequence.
The resulting 2D velocity gather extracted from the 3D model. Each trace in the output corresponds to one bin point from the stack line, and contains the velocity values (in m/s) sampled or interpolated from the 3D volume at that location. The vertical axis of the output matches the domain of the input 3D model: depth (m) when Domain is set to Depth, or two-way time (ms) when set to Time. Connect this output to downstream modules such as depth conversion, 2D migration, or velocity QC displays.
This module has no custom actions. Extraction is performed automatically when the module is executed.