All GridSTAT files reside in the same working directory, e.g. GSWORK. All files from the same project share the same file name but have different extensions.
There are seven types of input files for the current version of GridSTAT: (1) seismic data files, (2) well data files, (3) layer data files, (4) XYZ data files, (5) fault files, (6) grid files, and (7) horizon marker files.
The seismic data files are imported in SEG-Y binary format. They must be converted to GridSTAT binary before they can be used in the program. This conversion can only be done within the UNIX version of GridSTAT. Once the conversion has been accomplished, however, the resulting files can be used on either the UNIX or PC version of the program.
The other six types of files are imported in ASCII format. Data columns in the ASCII format import files may be separated by space, tab, or comma. Well data files, layer data files, XYZ data files, and fault files are converted to GridSTAT binary data file before they can be used. Conversion to binary both makes the files more compact and calculations within GridSTAT faster.
The extension of the resulted binary data file is BD1. The same GridSTAT binary data files can be used for both the PC version and UNIX versions, and GridSTAT will automatically convert between the different PC and UNIX formats.
Well data files contain column-wise data for a series of depth (or time or other index). Default extension for well data file is LOG. Other ASCII format files should have extension DAT.
Layer or XYZ data files are column-wise ASCII files where each row is for a separate well or data point. The difference between layer data and XYZ data is that layer data may consist of multiple layers from multiple data columns while XYZ data may contain Z coordinate (elevation) and only one data column per row. For layer data, the layer sequence number is used for Z coordinate (1 for top layer, 2 for second layer, etc.). For XYZ data, each data entry is associated with X coordinate, Y coordinate, and Z coordinate (elevation). The Z here is the elevation location, and the data value for that location is the attribute for that data point. In a conventional mapping software, Z is usually the elevation to be mapped and that corresponds to the data column in importing layer data into GridSTAT.
Grid file can be imported as attribute grid. But more often they are imported as horizon (top of formation) grids. The extension of horizon (formation top) grid in GridSTAT is GDT. Presently, grid files from Zmap, CPS-3, VIP, and any regular grid file without header can be imported in GridSTAT.
Horizon markers are imported as column-wise ASCII files. The extension of horizon marker files after they are imported into GridSTAT is IMK. Marker files are used to constrain log data. Marker files cannot be used without log data. To display or map the markers without log data, import horizon markers as layer data.
When a file is imported into GridSTAT, the results are saved in the current project (UNTITLED for new project) and you can expect to find the data again the next time you enter GridSTAT.
In all data files and marker files, the well name is used as the key identifier. Well names can be any combination of characters (except commas and spaces) up to 13 places. The well name for GridSTAT data must be unique for each well. "FAULT" is reserved for fault data and should not be part of any well name.
Because all files in a project share the same name with different extension, all files sharing the same name will be deleted if that project is deleted. Also when GridSTAT export data files, the file names will be the same as the project name and the extension will be .LOG or .DAT. Therefore, it is recommended to keep a set of the original ASCII data files in a separate directory so that they will not be deleted when a project happens to use the same name.
Any files that are created or manipulated within GridSTAT may be considered as output files. Most commonly, though, it is grid files that are considered as GridSTAT output. The extension for grid file is GD3.
Presently GridSTAT is able to export grid files to VIP, ECLIPSE, SIMBEST, SGM, ZMAP, and DATA VISUALIZER. The extension of the export file is EXP.
The default extension for well data import files is .LOG. Besides well logs, well data files may be core data, production rate (vs. time), or temperature data.
An example of a Well Data File that has (1) all the wells in the same file and (2) includes a two-line header for each well is:
Example: Well Data File (with headers) in GridSTAT Format (C:\GSWORK\allwells.LOG)
WELL=3/4a-M2Z EASTING= 431314.7 NORTHING= 6754490.1 KB= 4342.
DEPTH GR RXO RT RHOB NPHI CALI
9591.5 -99999.0 6.963 6.022 -99999.0 -99999.0 8.938
9592.0 -99999.0 6.822 5.935 -99999.0 -99999.0 8.928
9592.5 -99999.0 6.473 5.721 -99999.0 -99999.0 8.918
...
WELL= 3/4a-M4 EASTING= 430416.2 NORTHING= 6755666.8 KB= 4298.
DEPTH GR PSR ATR RHOB NPHI
9986.0 80.533 -99999.000 -99999.000 -99999.000 -99999.000
9986.5 80.587 -99999.000 -99999.000 -99999.000 -99999.000
9987.0 77.547 -99999.000 -99999.000 -99999.000 -99999.000
...
Keywords in the first line of each header are WELL=, EASTING=, NORTHING=, and KB= .
In Well Data Files, the numbers after EASTING= and NORTHING= should be formation top coordinates, not surface coordinates.
The number after KB= is the distance that the log datum is from sea level. Physically, the log datum can be, for example, a matte, the ground, or a Kelly bushing. Since it is very common to use the Kelly bushing as the log datum, we have used KB= to denote the log datum, even though we may in fact be using matte or ground elevation. If the depth is in subsea, use KB=0.
The only keyword in the second line of the headers is DEP, which is embedded in the word DEPTH. Usually, these depth values in a Well Data File are drill depth.
The remaining words in the second line of the header are the names of the data (e.g., for the first well, gamma ray (GR), two different resistivity (RXO and RT), bulk density (RHOB), porosity (NPHI), and caliper (CALI)). The ... line means there are more data lines there.
As already mentioned, instead of putting all the well data into one file, the data for each well can be put into a separate file. Then, one can put two lines of header information at the beginning of each file.
The depth in a Well Data File is usually drill depth and is taken to increase in the downward direction. (Note that the sequence of numbers -0.5, -1.0, -1.5, -2.0, etc., is decreasing in the downward direction.)
When working with deviated wells, one can put the deviation data in a separate file. The format of the deviation data is:
Example: Well Deviation Data in GridSTAT Format
WELL= 3/4a-M2Z EASTING= 213232.3 NORTHING= 193232.0 KB= 168.5
DEPTH TVD X Y
0.0 0.0 0.0 0.0
100.5 100.0 1.02 -0.3
1457.0 1200. -92.8 138.2
3253.5 2624.3 -352.3 732.4
......................................................................................
Keywords in Well Deviation Data are WELL=, EASTING=, NORTHING=, KB=, DEPTH, and TVD. X and Y are not keywords.
The first line of each header gives the well name and the location of the well at the surface. The second line is headings for the four data columns. DEPTH means drill depth or measured depth. TVD means true vertical depth. X and Y are easting and northing values of points along the well. X and Y can either be actual coordinates or offsets from the surface easting and northing, respectively. GridSTAT determines which is the case by checking to see how close the X and Y coordinates of this first point are to zero.
For SGM format log data files, there is a header segment and a data body segment. Each segment contains a line of "=" signs to identify the data columns following that line. Comment lines are started with "!" sign. Header data must have well name in first item and X,Y,KB in the 3rd, 4th, and 5th items respectively. Multiple wells may be placed in a single file.
Example: Well Data in SGM Format
!WELL ID TYPE SRF.CRD.X SRF.CRD.Y KB ELEV TD WS
============ ==== =============== =============== ======== ========
115 VERT 18467 15940 3289
! WELL: Test #132 (COMP. DENSITY)
! PARAMETERS: DEPTH PND2
! UNITS: FT PERCENT
========== ========= ========= ========= ========= =========
5750.000 4.409
5751.000 5.650
5752.000 6.801
5753.000 6.975
5754.000 6.150
5755.000 5.676
5756.000 7.635
Additional steps required when importing SGM well data format file into GridSTAT include: from the Options pull down menu Importpar panel, select SGM for Log Data File Type. The Depth column label and Data column label should be selected.
If the well data files do not contain the coordinates and elevation reference, a header file will be required. This header file will be the same as a marker file. The marker header file should contain the x-y coordinates and KB column in addition to well name and marker depth columns. If markers are unavailable, use a dummy column for the marker top. For example of marker file format, please see the next section: Horizon Marker File.
There are two ways to match the well name in the marker header file to the well in the well data file. One is to have a well name column in the well data file. Otherwise the filename will be used as well name.
If a column in the well data file is the well name, that column can be used to locate the header information from the marker header file. If the well name is changed in that column, GridSTAT will start a new well.
Example: Well Data with Well Name Column
Well,Depth,Perm
ST_0504,962,2720
ST_0504,963,5380
ST_0504,964,5560
ST_0504,965,6740
ST_0504,966,7750
ST_0504,967,5820
ST_0504,969,1220
ST_0504,970,5950
ST_0504,971,4820
ST_0001CH,1136,695
ST_0001CH,1137,170
ST_0001CH,1145,3460
ST_0001CH,1146,2750
ST_0001CH,1147,795
Additional steps required when importing well data with well name column include: from the Options pull down menu Importpar panel, select Match Well for Log Data File Type, and select the Well column in addition to Depth and Data columns before clicking Convert from the Import panel.
A common data format is LAS or similar format that contains well logs. Information about X-Y-KB is usually not in these files. And the files do not contain a column of well name that can be easily matched with the well name in the marker header file. In this case, the file name (excluding the extension) will be used as well name and each file can contain data from one well only. Current version of GridSTAT does not support wrapping.
Example: Well Data with Well Name Column
~Version Information
VERS. 2.0 :CWLS LOG ASCII STANDARD - 2.0
WRAP. NO :One line per depth
......
~Curve Information
DEPTH .FT :Curve # 1
GR .API :Curve # 2
CAL .INCHES :Curve # 3
PNLS .DECIMAL :Curve # 4
~ASCII Log Data
4500.900 40.937 8.582 .067
4501.000 41.315 8.582 .066
4501.100 41.281 8.582 .066
4501.200 41.247 8.582 .065
......
Additional steps required when importing well data without well name column: from the Options pull down menu Importpar panel, select Match Filename for Log Data File Type. The desired Data column and Depth column must be selected. For LAS format, the data name is taken from the lines after ~Curve Information and data starts after the ~ASCII Log Data line.
The classic way to correlate wells is to use markers (horizons) for the top and bottom of each zone. Geologists usually pick markers from logs or core. If marker information is available and thought to be reliable, it can be put into GridSTAT format and used directly for the geostatistical calculations.
It's required that Marker Files contain the same well name as the Well Data Input Files. This allows the markers to be matched to the wells in the binary data file.
The first line of the marker file should contain the labels for each column.
An example of a Marker File made from geologically picked markers is shown below.
Example: Marker File to import into GridSTAT
WELL GBDTOP GBDBASE GBSTOP GBSBASE SATOP SABASE
REFERENCE_Z -460 -487 -487 -529 -529 -551
CVU-1 -99999 -99999 -99999 -99999 -99999 -99999
CVU-2 -460 -487 -487 -529 -529 -551
CVU-3 -422 -450 -450 -488 -488 -512
...........................................................................................................................................................
CVU-57 -247 -295 -295 -337 -337 -557
In the first line of this file, the labels are the names of the markers GBDTOP, GBDBASE, GBSTOP, GBSBASE, SATOP, SABASE.
None of the markers are available in well CVU-1, so the null value -99999 appears for all zone tops and bases.
REFERENCE_Z is a keyword indicating the markers in this line are to be used as depth normalization reference. If no reference is given, the first well of the data set will be used as reference. In this example the reference is copied from well CVU-2. It can be modified and does not have to be the same as any particular well.
An alternate file format for a Marker File made from geologically picked markers is:
Example: Marker File to import into GridSTAT
well x y kb Bmarker Zone2 Zone3
MA12 805930.3 6774512. 2959 -1745 -99999 -99999
MA13 813701.6 6781806. 2909 -1740 -1822 -1853
............................................................................................................................
MA17 816144.3 6776897. 2905 -1739 -1832 -1868
The words "well", "x", "y", "kb", "Bmarker", "Zone2", and "Zone3" are simply identification labels to remind the user what data is in what column. The well names MA12 and MA13 etc. must be the same as in the well data files. When log data is to be imported but the log data files do not contain X-Y-KB information, it is necessary to have X-Y-KB columns in the marker file and the marker file should be imported before the log data file. If the log data file contains X-Y-KB for import, the X-Y-KB in the marker file will be ignored.
In a Marker File, measured depth is positive downward and subsea depth is positive upward. It's recommended that subsea depth be used. If measured depth is used conversion to subsea is needed within GridSTAT. For missing markers, -99999 is used.
Marker files may also be imported as layer data. This is especially true when there are missing markers. A grid can be generated from the layer data of markers and then a marker file can be sampled (from Tools pull down menu Horizon/Marker panel) from this grid. In order to import marker file as layer data, the marker file should contain x-y columns.
If the marker file is to be used for depth correlation between seismic data and well data and the markers are different for seismic data and well data, a column should be added to the marker file to identify the data type by data name. This data name should match the data name in the binary data file.
Single Plane Fault
Single plane faults are added interactively from the DataQC panel FanSection Graph within GridSTAT.
Vertical Fault File
Polyline faults can be interactively entered from the DataQC panel Basemap Graph by Adding Empty Wells with well name set to FAULTid where id is a number representing the fault id. Fault control points having the same id should be entered together and will be connected. During gridding, control data on the other side of any fault polyline will not be used.
ASCII fault maps can be created outside of GridSTAT. Before they can be used in GridSTAT, however, they must be transformed to GridSTAT binary format.
The format for a Fault File is:
Example: Fault File in GridSTAT Format
67892.3 12367 1 20
66721.1 11118 1 17
69048.4 11039 1 15
51834.7 9209 2 -34
53943.6 9733 2 -39
..............................................................
In this file, the first column is the EASTING coordinate of a point on the fault. The second column is the NORTHING coordinate. The third column is the number or segment identification of the fault. The fourth column is the vertical displacement or throw of the fault. If the throw is unknown, leave it out.
Fault displacements follow a right hand rule. With the thumb up, point the right hand along the direction of the fault. (The direction of the fault is determined by the order that the points appear in the Fault File.) A positive displacement is when the left side of the formation is higher than the right side.
When a fault branches or splits, it is considered as two separate faults: a parent plus a split. Parent faults must be listed first. The split is considered to be a different fault and given a different number or identification, even though it is physically connected to the parent.
Vertical faults must begin and end with zero throw. If the user does not explicitly put in zero throws in the Fault Data Input File, GridSTAT will automatically extrapolate the throw to zero.
The result of import conversion is in binary data file.
Mechanical data includes casing and perforation information. Mechanical data is imported as log data, except that the data name should be "MECHANICAL". Each object, such as casing, perforation, or plug, is stored as a set of three numbers: type of object, top, and bottom.
Type of objects:
0 perforation
> 0 casing (top = 0) or solid liner (top>0)
< 0 slotted liner
-99. plug back
The absolute value of type represents the radius (in the same unit as XY coordinates, e.g. ft) of the object.
Top and bottom are the top and bottom of the object in measured depth.
For example, a perforation starts at 2300 ft. and ends at 2350 ft. is stored as three numbers: 0.,2300.,2350.; a casing ends at 2600 ft. with 1ft (12 inch) radius: 1., 0., 2600.; a slotted liner 2 of 2ft radius from 1200 ft. to 2400 ft.: -2., 1200., 2400.; a plug at 3145 ft.: -99., 3145, 3145.
The following is an example with a perforation, a slotted liner, a casing, and a plug:
WELL= ex1 EASTING= 213232 NORTHING= 193232 KB= 168
Depth MECHANICAL
1. 0.
2. 2300.
3. 2350.
4. -2.
5. 2400.
6. 2500.
7. 3.
8. 0.
9. 2400.
10. -99.
11. 3145.
12. 3145.
The depth column is used as a sequence index. The result of import conversion is in binary data file.
Well header data is used for well header posting. It is imported as Well Header with the following available columns:
The result of import conversion is in binary data file.
Grid files are a typical output of the GridSTAT program. When grid files are created as GridSTAT output, the files are automatically in the correct format.
Sometimes, it may be useful to bring grids created outside GridSTAT into GridSTAT for analysis and display. In these cases we will need to know the format for GridSTAT grids. Therefore, the GridSTAT format for both surface and 3D grids is discussed below.
All grid files are in ASCII format. Grid file format is headers followed by a single column of numbers. That single column of numbers contains the values of some attribute, such as vshale, resistivity, porosity, etc.
For a 3D grid, the way that the numbers in the column are ordered is as follows: The numbers start at the southwest top of the grid. Then all the grid blocks are visited following the rule that z is incremented first, then y, and then x. z is considered positive downward, and the coordinate system is left handed.
A surface grid is just like a 3D grid except that z is not incremented. Therefore the grid blocks are visited following the rule that y is incremented first and then x.
Surface Grids
In GridSTAT, a surface grid is a surface divided into equal size curvilinear rectangles with a value (e.g., for porosity) assigned to each rectangle.
Example: Surface Grid File in GridSTAT Format
1
46 52 1
543534 23647 1 100 100 1
-99999
.28
.22
.214
.1
.195
.......
Thus the format of a surface grid file is just like that of a 3D grid except that parameter values associated with the z direction are set equal to one (see Example of a 3D Grid File in the next section).
3D Grids
In GridSTAT, a 3D grid is a series of blocks (equal size for brick model, variable thickness when following horizons) with a value (e.g., for porosity) assigned to each block. An example of a GridSTAT file that defines a 3D grid is:
Example: 3 D Grid File in GridSTAT Format
1
46 52 267
543534. 23647. -463. 100.0 100.0 2.0
-99999
.28
.22
.214
.1
.195
.......
Note that there are no keywords in a 3D grid file.
The first four lines of this ASCII file are header.
The first line must start with the integer 1. This integer must be separated from anything else on this line by a space.
The second line is the number of grid blocks in the x, y, and z directions, respectively. These numbers are in free format.
The first three numbers of the third line is the location of the top southwest data point of the grid. The next three numbers are the grid block dimensions in the x, y, and z directions. Both sets of numbers are free format.
The fourth line is the free format null value. The rest of the file is a sequence grid values. The sequence of the grid is following z direction down first, then increasing y to the North, then increasing x to the East. Note that z value in the grid header is depth (negative above sea level).
A surface grid is a special 3D grid where number of layers is 1.
An attribute grid will have the extension GD3. If the project has only an attribute grid (this will be the case when the grid is generated outside GridSTAT or the grid is simulated), this grid can be saved as data file from File pull down menu Save As panel, giving a different name and turning on Save As Data.
All Irregular Spatial Data Files are ASCII files.
The main difference between Irregular Spatial Data Files and Grid Files is that for a grid, the reservoir is divided into a number of equal sized blocks (brick model), and then a value is assigned to each block. For irregular spatial data, however, we need not divide the reservoir into blocks. Rather we can assign values at irregular (arbitrary, random) points in space by giving the x-y or x-y-z coordinate of each point and then the associated value.
An example of a 3D Irregular Spatial Data File is:
Example: Irregular Spatial Data File in GridSTAT Format
x y z attribute
3 .121 29.7 4.2212
78. .0001 2.1 84.36
.....................................................
Note that there are no keywords in an Irregular Spatial Data File.
The first line is a header that is simply the labels for the four columns of the file. The four file columns are the three spatial coordinates (x, y, and z) and a property value.
A layer data file would be exactly like the one above except the third column of the file would be missing.
Data columns in data input files can be separated by a comma, a tab, a space, or spaces.
The data in all ASCII files is free format. In other words, the position of the decimal place is arbitrary. In fact, it's not even required to have a decimal point.
Well names can be any combination of characters (except commas and spaces) up to 13 places.
As long as it's consistent, data can be in feet, meters, lat-long, etc.
In all well data files, depth increases downward. On the other hand, it is customary in Marker Files to have depth decrease downward. GridSTAT follows this convention. Also by convention, subsea values are usually used. Thus, for example, any depth below sea level in a Marker File will have a negative sign in front of it.
It's very important to use a consistent null value throughout any given set of data files. As a rule of thumb, it's usually best to put the null value out of the range of the data. A good general purpose null value is -99999.
"Keywords" really means "key groups of letters". Thus in a Well Data File, DEP is a key group of letters and will be recognized by the program as such, even though the letters "DEP" may actually occur in the word "DEPTH".
When keywords are used more than once in a file, only the first occurrence is recognized.
In geostatistics work, it's typical to spend more than half of one's time putting the data in the proper format and "cleaning it up". Just a few of the almost infinite number of data problems that may arise are: