|
<< Click to Display Table of Contents >> Navigation: Modeling > FD 3D modeling |
FD 3D Modeling generates synthetic pre-stack seismic shot gathers using a 3D finite-difference (FD) wave-equation engine. Starting from a 3D depth-domain interval velocity model and an acquisition geometry, the module simulates acoustic wave propagation shot by shot — propagating a source wavelet forward through the velocity model and recording the wavefield at each receiver location. The result is a realistic synthetic dataset that reproduces both primary reflections and wave-propagation effects present in the velocity model.
The module is used primarily for full-waveform inversion (FWI) workflow support, velocity model QC, and synthetic-to-real data comparison. It is well suited to complex 3D geological settings where ray-based forward modeling is insufficient. GPU acceleration and distributed (remote) execution are both supported, making large-scale 3D surveys practical.
Processing is organized shot by shot: each source point from the geometry defines one chunk of work. Within each chunk, the depth velocity model is clipped to the aperture window around the source and receivers, the FD engine is initialized on a GPU device, and synthetic traces are computed for all receivers in that shot. Output is written directly to a GSD file.
The 3D depth-domain interval velocity model used to drive the finite-difference simulation. Connect a depth velocity gather (GDepthVelocityItem) produced by any depth velocity building or inversion module. The model must be on a constant datum — all traces must share the same datum elevation, and the datum must be above the surface topography for every bin. When the velocity model is connected, the module automatically reads and displays the model grid dimensions (NX, NY, NZ), cell spacings (DX, DY, DZ), velocity range (min/max), and the datum elevation in the read-only "Input data detected parameters" group.
The acquisition geometry defining all source-receiver pairs for which synthetic traces will be computed. Connect a GTraceVectorItem containing valid source and receiver coordinates. The module groups traces by source point to form common-shot gathers. Each unique source point becomes one independent FD modeling job, which can be distributed across GPUs or remote workers. The geometry must be consistent with the spatial extent of the velocity model; traces outside the model bounds will be excluded from the computation.
The path and file name for the output GSD file that will receive the computed synthetic shot gathers. Specify a new .gsd file path. Use the Writing mode parameter to control whether shots are appended to an existing file or written in direct (overwrite) mode.
An optional external source wavelet gather (WaveletGather) to be injected at each source point during the FD simulation. When connected, the first trace of the gather is used as the source time function. If no wavelet is provided, the engine uses its own internal default wavelet. Providing a carefully designed wavelet (for example, a minimum-phase wavelet matching your real data) improves the realism of the synthetic output and simplifies subsequent comparison with field recordings.
Controls the bit depth used when writing synthetic traces to the output GSD file. Options are 32 bits (default, full floating-point precision), 16 bits, or 8 bits. Reduced bit depth saves disk space at the cost of amplitude precision. For modeling workflows requiring quantitative amplitude analysis or FWI residual computation, keep the default 32-bit format.
Determines how output shots are written to the GSD file. Direct (default) overwrites any existing file at the specified path, starting fresh each run. Append adds newly computed shots to the end of an existing file, which is useful when restarting an interrupted run or accumulating shots across multiple workflow executions.
This read-only group is automatically populated when the depth velocity model is connected. It displays the detected properties of the input velocity cube: the number of grid nodes in each direction (Velocity count X, Y, Z), the physical cell spacings (Velocity DX, DY in m; Velocity DZ in m depth), and the minimum and maximum velocity values found in the model (m/s). Use these values to verify that the connected model has the expected extent and resolution before running the simulation. The fields Current IL show and Current XL show allow you to select which inline and crossline slice is displayed in the velocity viewer.
Reserved parameter. Not currently active.
Reserved parameter group. Not currently active.
Read-only display of the number of crossline grid nodes detected in the velocity model. This value is auto-filled when the depth velocity input is connected and reflects the actual dimensions of the model cube.
Read-only display of the number of inline grid nodes detected in the velocity model. This value is auto-filled when the depth velocity input is connected and reflects the actual dimensions of the model cube.
Read-only display of the number of depth samples in the velocity model. This determines the vertical extent of the FD simulation domain. The value is auto-filled from the connected velocity model.
The spatial grid spacing used for the FD modeling simulation, in metres. This value is automatically derived from the velocity model as the minimum of the crossline bin spacing, inline bin spacing, and depth sample interval — ensuring that the FD grid satisfies the Nyquist criterion in all three spatial directions. Overriding this value manually allows you to run at a coarser spacing to reduce computation time, at the cost of reduced accuracy for high-frequency content.
Read-only display of the average inline bin spacing detected from the velocity model, in metres. The module computes this automatically by measuring the physical distance between consecutive inlines in the velocity cube.
Read-only display of the depth sample interval detected from the velocity model, in metres. Together with Count Z, this defines the total vertical depth range of the simulation: total depth = Count Z × Delta Z.
When enabled, the module reads elevation information from the input trace headers to detect and honour surface topography during the FD simulation. Cells above the true surface are filled with the Air velocity value, creating a free-surface boundary that accounts for land surface relief. Enable this option when modeling land surveys with significant elevation variation; leave it disabled for flat-datum or marine surveys.
The velocity value (m/s) assigned to grid cells above the detected surface topography when Detect topography is enabled. This parameter is only relevant for land surveys. Set it to a near-zero value (for example, 300 m/s) to approximate a free surface, or use the actual air acoustic velocity (343 m/s) for a physically consistent boundary.
The number of absorbing boundary cells added around the FD modeling domain on all sides. Default: 30 cells, minimum 1. These padding layers implement a perfectly matched layer (PML) or taper that absorbs outgoing waves at the grid edges, preventing artificial reflections from the boundaries of the finite computational domain from contaminating the synthetic seismograms. Larger values suppress boundary reflections more effectively but increase GPU memory usage and computation time. For most surveys, the default of 30 cells is adequate; reduce it only if memory is severely limited.
Reserved parameter. The dominant frequency used internally by the FD engine is derived automatically from the input wavelet and velocity model. This control is not currently exposed in the module interface.
The internal time step of the finite-difference time-marching scheme, in seconds. Default: 0.0005 s (0.5 ms), minimum 0.00001 s. The FD solver must satisfy the Courant stability condition: the time step must be small enough relative to the spatial grid spacing and maximum velocity to keep the simulation numerically stable. Smaller values improve stability and accuracy at the cost of more time steps per shot. The default is suitable for typical seismic frequency bands (up to ~80 Hz) with grid spacings of 5–25 m. If the simulation becomes unstable or produces noise, reduce this value. Note that this is the internal modeling step — the output sample interval is controlled separately by Output data DT.
Reserved parameter. The number of time samples in the output traces is derived automatically from Output data time divided by Output data DT. This control is not currently exposed in the module interface.
The lateral margin, in metres, added around the bounding box of each shot's source and receiver positions when extracting the velocity sub-cube for the FD simulation. Default: 500 m. Increasing the aperture ensures that waves traveling outside the direct source-to-receiver corridor are included in the simulation, which is important for modeling wide-angle reflections, head waves, and diffractions. However, a larger aperture requires more GPU memory per shot. If you observe edge-effect artifacts in the synthetic output, try increasing this value.
Read-only display of the datum elevation (m) automatically detected from the depth velocity model. All traces in the velocity model must share this same constant datum. The FD simulation starts wave propagation from this datum level. If the model validation fails due to inconsistent datums across traces, an error is reported when the velocity input is connected.
The sample interval of the output synthetic traces written to the GSD file, in seconds. Default: 0.004 s (4 ms). The FD engine runs at the finer Time step internally and sub-samples the wavefield at this interval to produce output traces. Set this to match the sample interval of the field data you intend to compare with the synthetic output. The total number of output samples per trace equals Output data time / Output data DT.
The total record length of each output synthetic shot gather, in seconds. Default: 6 s. The FD simulation is run for this duration. Set it to match or slightly exceed the maximum two-way travel time of interest in your survey area. Longer record lengths require proportionally more computation time and GPU memory.