petrel tips&tricks from scm - scm e&p solutions ... effort would have taken hours using...

K n o w l e d g e W o r t h S h a r i n g

Petrel TIPS&TRICKS from SCM

Petrel is a mark of Schlumberger

4801 Woodway Drive, Suite 150W • Houston, TX 77056 • www.scminc.com • [email protected]

© 2011 SCM E&P Solutions, Inc.

1

Multiple Input Data for Make Horizons (Petrel) Data available for modeling a horizon often varies from one area of the horizon to another. For example, seismic data may exist for most fault blocks, may be absent for some blocks, and for some of those seismic poor blocks there may be well top data. In blocks completely missing data, a 2D Grid may be created or one that has already been built for a higher or lower surface may be shifted to that block’s horizon position and used as its primary input data. Well data for seismic poor blocks may be dense enough to use as the primary data for building those block’s horizon models. The Make Horizons process allows you to easily and quickly point to different data for each fault block (segment) and use all of the various data sets to build the horizon model. This Tips & Tricks article describes how the Make Horizons process is used to point to different data for different fault blocks. The process is easy, useful, and saves time. The authors typically use this multiple data approach in 20% to 25% of their projects.

Before describing the Make Horizons multiple input data technique, the data set and its interpretation will be reviewed. This faulted data consists only of well tops and fault cuts. The interpretation of how the faults correlate is key to creating an acceptable model and forms the foundation into which the multiple data files are input. 3D displays of the modeled horizons quickly show whether fault correlations are acceptable and the types of problems seen when correlations are incorrect.

Example Data

Some projects that SCM works are seismic poor. That is, they either have no seismic over the area of interest or the seismic is so poor it can’t be used for the zones being modeled. One of those projects was a fairly mature tight gas field in the Wilcox formation of the Texas Gulf Coast. Data were available for approximately 150 wells, 40 plus zones (80 plus horizons), and about 40 faults. The data are proprietary, however, so the authors have created a fake Example Project having similar characteristics for use in this article. The Example Project’s data consist of 5 horizons penetrated by 8 wells with a total of 8 uncorrelated fault cuts and 32 top picks. The data were imported into Petrel. The goal of the project is to correlate the faults, model the faults, build a pillar grid, and model the horizons. The horizons can be treated as planar surfaces cut by normal faults. Wells and tops can be down loaded along with this article and input to Petrel.




2

Figure: Two 3D views of Wells, tops, and fault cuts for the Example Project.

Fault Interpretation (correlation)

Correlating faults in the full field Wilcox project with 150 wells and 600 plus fault cuts was difficult. We had to understand the trend of the faults and their relationships to one another. By searching the literature, studying adjacent fields, reviewing old field maps and talking with geologists experienced in the area, we were able to build our general field knowledge. However, it wasn’t until we built the model that we really worked out the detailed fault correlations.

For this paper’s Example Project, it took two passes of modeling, requiring one man‐day of time, to work out the correlations and build the framework. It took about 3 man‐months to work out the fault correlations on the full field project referred to above. The faults in the Example Project are sub‐parallel, strike SW‐NE, dip to the SE, and define the edges of small slump blocks. The units of interest total about 600 feet thick and the faults can be treated as being planar or having a minor listric form (concave up) through the units.

First Pass Fault Interpretation

All fault cuts were displayed in a 3D Window. The window was rotated to line up cuts and determine which cuts belonged to the same fault. The tops for a particular horizon were also displayed to see if they lined up on a plane in one particular area (possibly a fault block) and if that area was bounded by the correlated fault cuts. When a set of fault cuts were thought to line up and appeared to separate tops that looked to be displaced, they were assigned the same name using the Tops file spreadsheet. At the conclusion of this process, three faults had been identified. A fault model was built for the fault having the most data and extended to cover the model area. Fault models were built for the other two faults, each made to have the same general trend as the first fault.




3

Figure: First Pass attempt at fault correlation with fault models displayed and tied to fault cuts (left) and segments displayed (right).

The First Pass Fault Interpretation was Pillar gridded and the Make Horizons process run to build the structural framework. The techniques for using separate input data for each fault block were used because there were too few top picks to build acceptable horizons in any block. This Make Horizons method for multiple input data is described in detail below using the Second Pass Fault Interpretation.

Figure: First Pass Fault Interpretation’s Structural framework: Horizon10 (top Left), Horizon 20 (top right), Horizon 30 (middle left), Horizon 40 (middle right), and Horizon 50 (bottom left), and faults showing well and fault cut penetrations.

H10

H20

H30 H40




4

There are several problems resulting from this fault interpretation:

Almost all horizons have a problem with the small displacement portion of the dark blue fault in the center of each picture. They reverse along the fault or have little throw. This indicates that the fault does not exist or is in the wrong place. The points in the fault blocks north and south of this fault indicate that the eastern tops may be on one fault block and the western tops on another.

Horizon 20: Wells #7 and #5 should have top picks for Horizon 20 but do not. If they do not have picks then they should be in the fault gap for this horizon. This and the reversal along the central fault indicate that the faults are incorrect at this level.

Horizon 30: Wells #3, #4, #5, and #7 should have top picks for Horizon 30 (same problem as horizon 20). Note also the extreme reversal at Well #5 caused by the top pick being on the wrong side of the fault.

Several of the horizons have fault block surfaces that are severely warped and almost look like portions of them correlate better with portions of adjacent fault blocks.

Well #5 penetrates a fault without a fault cut.

These problems could only be fixed by changes to the fault interpretation and thus a Second Pass Fault Interpretation was done.

H50




5

Second Pass Fault Interpretation

On the Second Pass Interpretation considerable time was spent studying the First Pass and looking at the top picks and fault cuts in a 3D Window. 2D Grids were built of faults once they were re‐correlated and also for the tops in individual fault blocks. It was found that the dip on the structure surfaces in most fault blocks was about 0.5 degrees (basically horizontal) rather than the 2.0 degrees that was used in the First Pass Fault Interpretation. Using this dip to identify which tops belonged together in a fault block helped define where the faults should be threaded through the tops. The final fault interpretation and model is shown in the figure below. This is only one of a hundred possible interpretations but it works with the data.

Figure: Second Pass Fault Interpretation with fault models displayed and tied to fault cuts (left), Horizon 10 built using this correlation (center), and 3D Window view of fault block (segment) distribution and names (right). Note there are now six faults rather than the original three.

Make Horizons Using Multiple Input Data

The Make Horizons process was used to build the structural framework. Normally the input data is inserted into the Input #1 column and the tops into the Well Tops column. In this project there was no data besides the tops. Often, for densely drilled fields, the tops are inserted into both the Input #1 column and the Well Tops column and it works fine (usually with only a few faults). In this example, some blocks had little or no data and using that approach did not work well as seen in the figures below.




6

Figure: Make horizons input using tops in both the Input #1 column and the Well Tops column (top left), with parameters restricting error correction to within segments (top right), and the resulting model’s Horizon 10 (bottom left) and Horizon 50 (bottom right). Note the extreme variation in block displacement and form between the top horizon and the bottom.

Build 2D Grid Input Data

It should be possible to build a flat 2D Grid using the typical dip found on the structure (0.5 degrees) and the average strike and then to move that grid to the top picks’ position in a particular block. With only slight adjustment this grid would then make a good model for the structure in that fault block. This is the approach that was used for each fault block on each horizon.

H10 H50




7

Figure: Fault Block A (segment) with flat planes dipping 0.5 degrees at azimuth 145 degrees for each horizon (left) and after using them as input to the Make Horizons process (right). Note the fit is not a perfect but close and the well tie process of Make Horizons warps the grid to the data and clips it to the faults.

The Make/edit surface process (using Artificial algorithms plane) was used to build a base structure grid covering the entire area of interest. That planar grid was copied and an Arithmetic Operation used to shift the copy to the top picks position for a specific block. Because this had to be done for each horizon (5) and for each block (7) there were 35 grids to copy and shift. Also the amount to shift the grid for each block had to be determined by experimentation. This effort would have taken hours using Petrel’s interactive tools. Instead, seven workflows were created, one for each fault block. Input to each workflow was the flat starting grid built above and the work folder into which that fault block’s grids were to be written. The workflow had five lines where each block’s shift value was entered. In the workflow each input grid was copied, the entered value was used to shift the grid, and the grid was moved to the output folder and renamed. A 3D window with only the tops for the fault block being worked was displayed and each shifted grid checked to ensure it was properly positioned. When no tops existed for a horizon in a block, the average spacing between that horizon and one that did have a top was used to position the grid.

Figure: Make/edit surface process used to build the planar grid (left) used as input to the workflow.




8

Figure: One of the workflows used to build the planar grids for a fault block. The base input grid does not have to be a plane but could have some other form.

Because each workflow was self cleaning (removed folder content) and wrote to its own fault block folder, the file management was automatically taken care of. The folders containing the grids were always in top down order and ready for input to the Make Horizons process.




9

Figure: Folders and grids defining the initial form of the structural surface in each fault block (segment).

Setup Make Horizon Parameters

Once each workflow was run and the grids fine tuned, the input was ready for Make Horizons. The primary difference between this style of input and that normally used is the addition of more Primary Input columns. Each of the Input columns was linked, using the Segment tab, to a segment (fault block) in the model. In this Example Project, Input #1 was associated with Segment A, Input #2 with Segment B, and so on.

Figure: The typical data input dialog for the Make Horizons process.

Figure: This Example Project’s data input dialog for the Make Horizons process, using 7 primary input columns (top) and the Segments tab used to link the data to the segments (bottom). Note that each of the Input columns is filled with grids from one of the fault block folders described above.




10

The other parameters of the Make Horizons process are treated pretty much the same as when only using one primary input data column. The one difference is on the Well Adjustment tab. The Method parameters, normally with Across segments checked, are usually changed to have Inside segment only checked. This of course will need to be experimented with. The logic behind this change is that the primary input for a horizon in one fault block (a 2D grid) was built independently from that in the adjacent block and the two will likely have independent errors. Because of this, their error corrections probably should not be mixed across fault (segment) boundaries.

Figure: The Well Adjustment tab with the Inside segment only parameter checked because the errors are independent across the faults (due to the way the primary input surfaces were built).




11

Review the Results

After the Make Horizons process was run, the individual horizons were reviewed in a 3D window to see if Make Horizon parameters or the input data needed adjustment. In this case, the results were acceptable. Again, you are reviewing all well penetrations. If the well penetrates the horizon, then there must be a top pick. If the well penetrates a fault, then there must be a fault cut. There should never be a missing top or fault cut from one of these penetrations unless the log data is bad.

Figure: Second Pass Fault Interpretation’s Structural framework: Horizon10 (top Left), Horizon 20 (top right), Horizon 30 (middle left), Horizon 40 (middle right), Horizon 50 (bottom left), and faults showing well penetrations. Note that all horizons look acceptable, tops only where horizons are penetrated and cuts only were faults are penetrated.

H30 H40

H10 H20

H50




12

A More Common Scenario for Multiple Data Inputs

The above example is an extreme case, although useful, having different primary data for every fault block (segment) on every horizon. This is not normal. Usually, only one or two horizons, if any, require more than one primary input data set. For example, you might have three seismic events, two of which have been picked across the entire area and the third picked over much of the area but absent from two fault blocks. In this scenario you might have two primary input columns (Input #1 and Input #2). In the first column is placed the seismic data for all three events. In the second column is placed the same seismic data for the first two events and for the third event a grid built to represent the surface in the blocks were the seismic is missing.

Figure: Make Horizons input data for three seismic events with one only partially covering the area and requiring a “manufactured” grid to fill two of its fault blocks (top) and the Segments tab settings needed to use the correct data to build all three horizons (bottom).

Multiple Data Inputs as a Way to Merge Files

Sometimes you will have two files (not including tops) that represent the same horizon and you want to use both as primary input to the Make Horizons process. For example you may have two vintages of 2D seismic for one of your horizons and both need to be used. You could merge the two files or you could use a second Input column to merge them on the fly in Make Horizons.




13

Figure: Make Horizons input data showing two primary input files for one of the horizons (top) and the Segments tab settings (bottom). Note that both Input #1 and Input #2 are used for all segments but Input #2 only has data for Horizons 30.

petrel tips&tricks from scm - scm e&p solutions ... effort would have taken hours using...

Documents