Completions and wellbores — G-1, W-2 and the 28 record types

A permit says what an operator intends. A completion report says what they built. The Full Wellbore Database says what exists. These are the three datasets that describe physical wells, and the last two are the most technically demanding files the RRC publishes — and the most rewarding.

Completion reports: W-2 and G-1

When a well is finished, the operator files a completion report: Form W-2 for an oil well, Form G-1 for a gas well. Same idea, different form, chosen by what the well makes.

The RRC publishes these nightly as a completion information extract. Structurally it is a hierarchical text format: each file describes a filing packet, and within the packet a tagged line identifies each record. The tag comes first on the line and the fields are delimited — the completions extract uses { as its field separator, where several other RRC text extracts use }.

A packet looks like this in outline:

<tracking number>{<form list>{<attachment list>
...
<packet metadata: tracking, packet id, submit date, approve date, operator>
G-1{...                              the gas completion record
G-1 Field Data{...                   field assignment
G-1 Formation Data{...               one per formation, recurring
G-1 Casing Data{...                  one per casing string, recurring
G-1 Production Interval Data{...     one per perforated interval, recurring
G-1 Amount And Material Data{...     stimulation materials, recurring
G-1 Measurement Data{...             test measurements
G-10{...                             gas well status / test

W-2 packets carry the same child record types under a W-2 prefix. A packet contains one or the other, plus its children.

That hierarchy lands in the warehouse as a parent completions table plus child tables for formations, casing strings, production intervals and stimulation materials. When you export completions from EZRRC you get the parent plus the child files, because a completion without its casing and perforation detail is not a completion.

The codes on a completion

Four small code sets do most of the interpretive work, and all four are single digits in the file:

Well type — producing, shut-in producer, active injection (UIC), shut-in injection.

Filing purpose — initial potential, retest, reclassification oil to gas, reclassification gas to oil, reclassification injection to producing, reclassification producing to injection, or well record only. That list is a useful reminder that most completion filings are not new wells.

Completion type — new well, deepening, plug back, sidetrack, horizontal, reentry, other.

Casing type — conductor, surface, intermediate, conventional production, tapered production, other.

Two more appear on the child records: the material/process code on stimulation records (acid under Statewide Rule 13, fracture, cement squeeze, cast iron bridge plug, retainer, other) and the top-of-cement determination code (calculation, temperature survey, cement evaluation log, circulated).

Those are exactly the kind of values that get lost when a dataset is republished as bare digits. EZRRC carries them as real lookup tables and can join the labels into an export on request.

The Full Wellbore Database

The Full Wellbore Database — RRC document WBA091, published weekly — is the master record of every wellbore ever drilled in Texas. About 1.2 million of them.

It is fixed-width ASCII, 247 bytes per record, and hierarchical: the first two bytes of each line are a record type, and there are 28 of them. Records for one well arrive together, beginning with a 01 root record, and the file is read as a stream where a new 01 starts a new well.

Parsing it is a state machine: read a line, switch on the first two bytes, append to the current well's child list, and emit the well when the next 01 arrives.

for line in stream:
    record_type = line[:2]
    if record_type == '01':
        if current_well is not None:
            yield current_well
        current_well = new_well(parse_record(RECORD_TYPES['01']['fields'], line))
    elif current_well is None:
        continue                      # orphan records before the first 01
    elif record_type == '06':
        current_well['casings'].append(
            parse_record(RECORD_TYPES['06']['fields'], line))
    ...

Two details in that sketch matter. Orphan child records before the first root record do occur and must be skipped rather than crashing the parse. And the last well only emits after the loop ends — forgetting that silently drops one well, which is the kind of bug that survives for years.

What is actually useful in there

Record 01, the root. API county and unique number, the district, total depth, original completion date split across century/year/month/day fields, and a stack of flags: plugged, fresh-water converted, subject to 14(b)(2), orphan well hold, completion data on file, water or land. Also the API-correction fields discussed in the API number article.

Record 13, the location. County, abstract, survey, block and section — and the WGS84 latitude and longitude, stored as COBOL signed zoned decimals with seven implied decimal places. This is the authoritative coordinate for a Texas well and the reason the zoned-decimal article exists.

Record 02, the completions. Each completion's oil schedule identity (oil code, district, five-digit lease number, well number) and gas schedule identity (gas district, gas well number), plus the API suffix. This record is the bridge between API-keyed and lease-keyed data.

Records 06 and 07, casing and perforations. Casing gives you size as inches plus a fraction (numerator and denominator as separate fields — this is a COBOL file, there are no decimals in a pipe size), weight, set depth, hole size, cement amount and a cement measurement unit of sacks, yards or feet, plus top of cement. Perforations give you from-depth, to-depth and an open-hole indicator.

Record 09, formations. Formation name and the depth at which it was encountered. Recurring, so a deep well has a full stratigraphic column.

Record 14 and friends, plugging. Plugging date, W-3 filing date, plugging depth, cement composition, mud details, and the logs released. If you want to know whether a well is really dead, this is where you look.

Records 22, 25 and 26, compliance. Rule 14(b)(2) governs inactive wells and carries a long list of hold and violation flags; the record is unusually wide because each hold reason gets its own single-character field.

Wellbore Query: the flat alternative

The RRC also publishes a Wellbore Query extract — the data behind its own online well search. It is a large comma-delimited CSV, one row per well, no header, with around sixty columns: district, county code, API, county name, oil/gas code, lease name, field number and name, lease number, well number, operator name and number, water/land code, depth, shut-in dates, 14(b)(2) flags, well type name, plugging information, most recent permit, the W-2/G-1 filing and completion dates, P-5 renewal month and year, P-5 organisation status, current inactive years and months, and H-15 status.

It is not a replacement for the wellbore database — it has no casing, perforations or formations — but for "give me one row per well with its current status", it is far easier and far faster. Choose by grain: flat status, or full downhole structure.

Putting the three together

Permits, completions and wellbores describe the same wells at three moments.

SELECT w.api_number,
       w.total_depth        AS wellbore_td,
       w.plug_flag,
       count(DISTINCT c.casing_count)  AS casing_strings,
       count(DISTINCT f.formation_cntr) AS formations
  FROM texas.wellbore     w
  LEFT JOIN texas.wb_casings    c ON (c.api_county, c.api_unique) = (w.api_county, w.api_unique)
  LEFT JOIN texas.wb_formations f ON (f.api_county, f.api_unique) = (w.api_county, w.api_unique)
 WHERE w.field_district = '08'
 GROUP BY w.api_number, w.total_depth, w.plug_flag;

Note the composite key. Wellbore child records join on the county and unique number together, not on a formatted API string, because that is how the file stores them. The next article works through the rest of the joins.