By Norman Mark, norm_mark@hotmail.com
Introduction
This article is an extension of my work appearing in this publication about 2 years ago which presented automating horizon picking from 2D seismic data. After accomplishing that I had a long-enduring mental block on how to extend the method to 3D for the purposes of automating subsurface mapping, the most tedious, time-consuming, error-prone and least appreciated processes in all of oil and gas exploration, and arguably the most important: no map, no drilling! Bad map – dry hole (usually). Good map – production (maybe). Maps based on artistic inclinations or sales purposes rather than strictly honoring data have led to legendary O&G financial failures.
Here I present the output of code I wrote which actually does automate 3D seismic interpretation, fully honoring all the data, to your profound disbelief, I suspect – and without any wishful-thinking component built in to the computing.
My decades-long experience working with oil and gas exploration and seismic service companies gave me the foundation and curiosity for pursuing the goal of automating seismic survey data mapping and immunized me against self-punishment.
The input data used here are from a good quality public domain 3D seismic data volume, Parihaka, offshore New Zealand, and are pushed through my code on a 10-year old Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz laptop. As it has no graphics card I tested it for graphics capacity to learn how much data it could handle in case I got lucky with my code. Surprisingly, the upper limit for drawing a 3D random point cloud in a browser is 30 million points with about 5 minutes of waiting for the blank browser window to light up with points.
Data Selection
An arbitrary data prism of 101 inlines x 101 crosslines – 10201 traces containing 2 seconds of better than average seismic reflection data quality from the Parihaka cube. The sample rate is 3ms. From this sub-volume local maxima reflection times were computed and used in this study. No filters of any kind were applied to these input data. This 101 traces x 101 traces x 2 seconds data prism contains almost 1 million/over 940,000 peak reflection times. Figure 1 contains views of the data at 3 different depth ranges within my 3D viewer. On the right the full volume of reflection points is colored by depth.
Much can be learned about the geologic structure from these views of the data alone without any further computing beyond computing local maxima from SEGY data. This style of data viewing has not been available in the commercial seismic interpretation software I have seen. The 3D viewer makes it easy to quickly identify zones of interest/targets especially with its transparency options. Again, these data are raw peak times – no amplitude information or isolation of surfaces.
Work Flow
The first step in finding surfaces is finding 2D horizons within each of the separate seismic inlines. Horizons are defined by touching 2D points within an inline or x-plane. By touching, I mean x coordinates change by one and y coordinates change by zero or one.
The following images, Figure 2, show the results of this process. Red points are local maxima and the green lines are the horizons. The left side shows a trace-long section of an inline with 2 seconds peak reflections. The right side is a detailed view of horizons indicated by their connectivity. Green lines connect reflection points one separated by one crossline, typically 12.5 to 25 meters in a modern seismic survey.
The three images in Figure 3 show views of the entire data volume of touching – one unit separation – positive reflection points connected by lines.
These entire volume of chains of points are computed in less than 4 minutes and are output to a text file in the following x,y,z format style:
1837,-92,4240 -> 1837,-93,4241
1837,-92,4244 -> 1837,-92,4245 -> 1837,-92,4246 -> 1837,-93,4247
1837,-92,4251 -> 1837,-92,4252 -> 1837,-92,4253 -> 1837,-92,4254 -> 1837,-92,4255
1837,-92,4257 -> 1837,-92,4258 -> 1837,-92,4259 -> 1837,-92,4260 -> 1837,-92,4261 -> 1837,-92,4262 -> 1837,-92,4263 -> 1837,-93,4264
Here, 4 chains of 3D points – 4 horizons – are shown in inline, reflection time, and crossline with connections between points indicated by arrows. Time is negative in order to display reflection time increasing downward within my 3D viewer.
Although surfaces composed of touching reflection points are seen in these images, the 2D horizons have not been organized into surfaces yet. The chains of points are the input to my algorithm which computes the 3D surfaces. My definition of a surface for this purpose is an assembly of touching points one point thick completely surrounded by open space.
I built 3D viewers to display the input data and 3D surfaces using ThreeJS. Surfaces larger that 5000 points, out of a possible 10,201 points are shown in the below image, Figure 4. The surfaces were computed in about 15 minutes and are shown with unique colors to certify they are in fact entities.
The red axis indicates inline direction and the blue axis indicates crossline direction. The green y axis shows increasing reflection time downward, 0 to 2 seconds.
In another viewer, Figure 5, surfaces are colored by depth to show structural details.
The output format for the surfaces is nearly identical to the format for the 2D horizons, except that the crossline (z-direction) values vary, as one would expect with surfaces. The output file is a listing of touching/adjacent 2D horizons in text format, easily read by mapping software which reads ASCII files.
Computing hundreds of surfaces took twenty minutes of computing on my 10-year old laptop. Mapping these same surfaces using O&G exploration commercial mapping software would take months!
I am currently seeking to apply my software to interested parties.
