Well spacing studies in tight gas reservoirs are usually performed using material balance tools such as MBAL or full reservoir simulators such as Eclipse. Both require commercial licences.
Open-source alternatives now exist. OPM Flow reads standard Eclipse input files, runs on Linux or WSL, and produces output that can be analysed entirely in Python. Building a material balance equivalent in Python from scratch is possible but takes real engineering time and it is still a tank model. OPM Flow runs the same physics as Eclipse and costs nothing.
This post demonstrates a practical workflow for building a radial grid model from wireline-scale petrophysical data, visualising the model in 3D, and evaluating how drainage radius affects plateau length and gas recovery. All code is open source. All figures were generated in Python.
A radial grid model places a single well at the centre of a cylindrical drainage volume. The only variable that changes between spacing cases is the outer radius, which represents the midpoint between adjacent wells in a regular pattern. Increase the radius and each well drains more reservoir volume; decrease it and more wells are required.
The key result from this type of analysis is not a single number but a design envelope: for a given contractual plateau length requirement, what is the minimum drainage radius that delivers it? That minimum drainage radius defines the maximum well count for the acreage, which in turn defines the capital programme.
Beyond well spacing, the same model structure supports:
All of them run in seconds in a radial grid model. The entire workflow from raw log data to production forecast charts runs without a single commercial licence.
In ResInsight, radial grids appear as polygons rather than true cylinders because they are stored as corner-point geometry internally. This affects visual appearance only, cell volumes and flow calculations remain mathematically equivalent to the analytical radial formulation.
To demonstrate the workflow without using proprietary field data, a synthetic analog was constructed representative of a high-pressure, deep, tight gas carbonate.
Porosity was generated as a correlated random field with a Gaussian depth trend and superimposed heterogeneity, producing a realistic 1 ft-resolution profile with a mean of 7.6% and a range of 1.5–14.9%. Four tight zones were embedded to represent permeability baffles.
Permeability was derived from the porosity profile using an exponential poro-perm transform:
k = 0.030 × exp(0.58 × φ%)This gives a geometric mean permeability of 2.56 mD at 1 ft resolution, preserved at 2.55 mD after 3:1 geometric mean upscaling to the simulator grid. The geometric mean is the physically meaningful average for radial flow in a heterogeneous vertical column.
Connate water saturation was derived from a Swirr–porosity relationship:
Swirr = (0.0048 / φ) × 1.65Swirr values are capped globally at 0.0792 — the maximum consistent with the saturation endpoint tables across all five permeability groups. For log display purposes, total in-situ water saturation was computed from the Archie equation using a formation water resistivity of 0.025 Ω·m.
Figure 1: Synthetic well log — porosity, water saturation, permeability, and poro-perm transform
PVT was taken from a black oil analog in field units. Initial reservoir pressure is 7,947 psia at 14,422 ft TVD datum, with temperature of 311°F. Gas gravity 0.64, formation water salinity approximately 50,000 ppm.
Five permeability groups were defined following standard tight carbonate practice, with gas relative permeability curves using Corey exponent of 6.5 and maximum krg of 0.9. Critical gas saturation ranges from 0 (high-perm group) to 0.31 (tightest group, k < 0.25 mD).
One advantage of the Python workflow is visualisation. Radial grids are awkward to inspect in traditional reservoir software, particularly at wireline-scale vertical resolution. PyVista allows the geometry to be reconstructed as a true cylindrical mesh directly from the simulator cell coordinates, making heterogeneity and completion placement much easier to interpret.
The resfo library reads OPM INIT and restart files directly into numpy arrays. PyVista's StructuredGrid object constructs the cylindrical mesh from the radial cell boundaries without any corner-point approximation:
The same approach renders dynamic properties from restart files: pressure depletion, gas saturation evolution, and completion interval placement relative to the gas-water contact.
Figure 2: PyVista 4-panel 3D view — porosity, permeability, gas saturation, pressure
The spacing sensitivity varies drainage radius across four cases. All other parameters are identical — same petrophysics, same rate target, same BHP floor.
| Drainage radius | OUTRAD | Well spacing | GIIP per well |
|---|---|---|---|
| 250 m | 820 ft | 500 m | ~25 Bscf |
| 500 m | 1,640 ft | 1,000 m | ~103 Bscf |
| 750 m | 2,460 ft | 1,500 m | ~232 Bscf |
| 1,000 m | 3,280 ft | 2,000 m | ~414 Bscf |
The target rate is 15 MMscf/d with a minimum THP of 1,450 psia. Plateau ends when reservoir pressure can no longer support the target rate at the THP constraint.
Figure 3: Gas rate and THP vs time — four spacing cases
The plateau duration difference between 500 m and 2,000 m spacing is the number that drives the well count decision. Tighter spacing delivers shorter plateau per well but more wells on the same acreage — the optimum depends on capital cost, surface facility capacity, and contract terms.
The single-well radial grid model is an underused tool in well spacing studies. It runs in seconds, requires no commercial licence when implemented in OPM Flow, and takes wireline log data directly at the resolution it was measured.
The main advantage is speed. Questions that would normally require multiple full-field simulation runs can be answered with a single-well model run in seconds. That makes it practical to screen well spacing, completion design and coning risk before committing to larger simulation studies.
For early-stage development planning, the radial model is often the fastest route from wireline data to an engineering decision.
The Python stack: resfo for reading Eclipse output, PyVista for 3D visualisation, Plotly for interactive production charts provide a complete post-processing workflow at zero cost.
OPM Flow version 2026.04. Python libraries: resfo, PyVista, Plotly.