|
|||||||||
![]() |
From DGInsider, Q4 1998
|
||||||||
(Note: In all scripts and command lines that follow, a backslash ( \ ) at the end of a line indicates that the current line is continued on the line that follows. When creating the script or typing the command line, these lines should be entered as one continuous line without the backslash.)
In EarthVision 5.x, one of the most noticeable changes to the capabilities that were available in EarthVision 4.x has been the introduction of the new horizon gridder. Full documentation on this new method is available in the EarthVision User's Guide, but here are a few tips for those making the transition from the 4.x horizon gridder to the 5.x horizon gridder.
The tolerance value controls the filtering out of data points if they lie within a certain distance from a fault. In the 4.x horizon gridder, tolerance was measured in X,Y units along the normal from the fault. But this method would cause problems when Z units were different from the X,Y units, for example, if you had feet by feet by milliseconds. In EarthVision 5.x, the tolerance is a percentage of total model range (still measured along the normal to the fault). To gain a better understanding of how the tolerance affects the data, the data sets can be automatically "labeled" during the calculation and then viewed in the 3D Viewer in order to see which points have been filtered out.
These parameters in the sequence file determine the control of extrapolation of an intermediate surface. In EarthVision 4.x, these values were specified in distances from the reference horizon. In EarthVision 5.x, these values are used differently and now refer to the percentage of the Z-range of the horizon data. For example, a MinValue of 0 and a MaxValue of 100 restricts the extrapolation of an intermediate surface to exact Z-range of the data (0 being 0% of the data or Z min and 100 being 100% of the data or Z max). With the improvements in extrapolation, it is recommended that these MinValue/MaxValue parameters be initially removed from the sequence files to see how the surfaces behave without them. If more control is needed, percentage values may be entered for these through the interface. It is not recommended to use 0 and 100 (which would prevent the surface from ever exceeding an input data value), but rather a slightly larger range, such as -5 and 105, which would allow the surface to exceed the input data values by 5% in the both Z directions.
In the 4.x version of horizon gridding, only points within a fault block were used to create the horizon grid in that fault block. With the geometric reconstruction method of the 5.x version of the horizon gridder, all the points of a model are used to create a horizon. This method has a couple of consequences:
- Problems in a surface in one fault block may be caused by a data problem in an adjacent fault block. It is thus necessary to check for data busts in the entire region surrounding a problem found in a resultant surface.
- A horizon surface is now calculated for each fault block, even fault blocks that do not have data points. If a user wishes to suppress a horizon in a particular fault block, the horizon gridding should be run first, then that horizon in that particular fault block should be turned off in the GSB (Geologic Structure Builder) model. To do this, select the fault block in question, choose Model Definition -> Select Sequence, then deselect the "Use" button for the horizon that is to be eliminated.
In version 4.x of the horizon gridder, only points within a fault block were used to create the horizon grid in that fault block. To control extrapolation in these areas, a "Helper" data set could be specified that allowed points outside the fault block to be used in the horizon gridding calculation for that fault block. With EarthVision 5.x and the geometric reconstruction method now used for horizon gridding, helper data sets are no longer allowed. If they exist in a sequence file, they are treated as "Adjustment" data and are used in whatever fault block they physically appear. These extra data points can often cause "bubbles" to appear in the horizon gridding surface.
The 5.x version of the horizon gridder has been designed to strictly honor the dying fault polygons specified in the sequence file, thereby providing very accurate "stitching" in the region of the horizon where the fault dies out. (Stitching occurs outside the dying-fault polygon boundary along the projection of the trace of the fault.) Sometimes it can appear, however, as if the gridding is ignoring data near a dying-fault polygon boundary. The data are not actually being ignored; instead the horizon gridder is faced with a conflict of stitching the surface around the fault polygon boundary versus a data point pulling the surface in a different direction. In some of these cases, a clipping polygon (that laterally clips the entire model) may obscure the dying part of the fault making it difficult to understand why the data point is not being honored. If a horizon looks to be ignoring data that have not been filtered out by a tolerance value, the next step often is to remove the dying fault polygons and see if the model improves. If the model does improve, the dying fault polygons need to be slightly enlarged to allow the horizon gridder "more room" in which to honor both the data points and the dying fault polygon.
[Home]
[Corporate]
[Events & News]
[EarthVision] [Support]
[Services] [Contact
Us]
© 1999-2007 Dynamic Graphics, Inc. All
Rights Reserved. Legal Notices.
See Legal Notices for appropriate copyright trademark legend.
Feedback: webmaster@dgi.com
Last updated: March 22, 2007