Q: We have 2 wells completed at the same depth in the
same reservoir, and one seems to be initially producing a gas condensate and
the other one is producing a black oil. How can that be?
(recently asked in a SPE Reservoir Technical Group discussion)
A: There could be 2 separate reservoirs, as others have
mentioned. That would be indicated by unequal initial fluid phase
contacts levels and pressures (where Pc=0). Or if initial contacts and
pressures are the same and we assume that the formation is a single
reservoir with continuous hydraulic connectivity at initial
capillary-gravity equilibrium, then initial saturations (and therefore
produced fluids) can vary areally at a given depth simply due to
heterogeneity and capillary pressure and phase transition zones. For
example, let's say that your well producing oil is in a low perm zone (0.1
md) compared to the condensate well (100 md), and that porosity is constant,
and that the Leverett J-function applies to Pcgo. Say that the entered
curve has Pcgomx=10 psia at Sg=1, and that the reference J-function value is
Jref = sqrt (kref/phiref) = sqrt (1 md/ 0.1) = 3.162278.
The "oil" well
could be in (towards the bottom of) the oil-gas transition zone
corresponding to the tight rock (.1 md) Pc curve, which is equal to the
entered curve times Jref/J = 3.162278/sqrt(.1/.1) = 3.162278. So max Pcgo
at the oil well is equal to 10*3.162278 = 31.62278. If the average phase
gradients of oil and gas in the transition zones are say, .25 and .15 psia/ft,
respectively, then the total height of the gas-oil transition zone above the
GOC at the oil well is Pcgomx/(go-gg) = 31.62278/.1 = 316.2278 ft.
Pc at the "gas"
well is equal to the entered curve times Jref/J = 3.162278/sqrt(100/.1) =
0.1 The total height of the gas-oil transition zone above the GOC at the gas
well is Pcgomx/(go-gg) = 10*.1/.1 = 10 ft.
If both wells
were completed 30 ft above the GOC, the "gas" well would be initially
producing all gas at reservoir conditions (from above the transition zone,
at Sginit = 1 - Swc) while the "oil" well would be initially producing
mostly oil (So would be close to 1-Swc near the bottom of the transition
zone). This can be demonstrated by initialization of a 2D x-z reservoir
model with only two adjacent columns, one for each well. The initial
downhole oil phase produced (all oil where Sg < Sgc) from the oil well would
be at or close to equilibrium with the initial downhole gas phase produced
from the gas well. Substitute your possible reservoir/fluid properties into
reservoir models (making various assumptions as demonstrated) to check this
and other possible explanations for observations. If the produced
fluids are at or near initial equilibrium then a single pvt representation
can represent them. Consult with a pvt expert for assistance with
Q: If Sensor is technically superior, why isn't it the market leader?
A: The main reason is that in the past we have not offered integrated reservoir
engineering workflows, and have only provided the reservoir simulator.
Our clients have generally been expert users who have recognized the extreme advantages gained by
building workflows with the best available components. However,
commercial pre/post-processing packages and workflow integration and
optimization tools recently developed by our associates provide
vastly superior automated and integrated deterministic and probabilistic reservoir modeling
capabilities and workflows, and
are rapidly increasing Sensor's market share. See
In what ways does Sensor treat black oil and compositional problems
Sensor treats black oil and compositional problems with the same logic.
The code and input data are
the same for the two cases, with the obvious exception of PVT treatment and PVT
What shortcuts, approximations, or sacrifices to accuracy, if any, explain
the CPU times of Sensor?
Sensor makes no shortcuts, approximations, or data changes related to accuracy. While Sensor was designed to provide accuracy equal to or greater
than that of other models, the accuracies of different models’ results are
best judged by actual run results. Simple
examples are: (1) compare Sensor’s one-iteration production well 6200 mcf/d
rates of spe3.dat with rates from other models, (2) compare the
initialization of phase identity and pressure in the critical-point black
oil (compositional) test4a.dat (test4b.dat) with other models, (3) for any
problem, test the 0-rate, no-change accuracy of Sensor initialization
(this is a recommended test of initial equilibrium and properly isolated equilibrium regions, insert two data lines TIME 10000/END at the beginning of Recurrent Data for a
few-second run with no wells), (4) for symmetrical problems, check the
symmetry of results.
CPU times can
vary widely among different simulators, as indicated by several of the SPE
Comparative Solution Project problems37-43*.
In one case, CPU times among five participants varied by a factor up
to 50 for the same dataset and same machine40.
Model efficiency depends upon many factors, including (1) choice of
formulation (Impes, Implicit, Adaptive Implicit, etc.), (2) solver type (NF
vs ILU-based methods) and logic of well constraint terms inclusion, (3)
implicit well terms in Impes, (4) method of handling wellbore crossflow, (5)
active-block coding in the solver as well as throughout the model, (6)
Newton-Raphson vs successive-substitution methods in flash and phase
stability calculations, (7) choice of variables in Impes compositional cases with large
Nc, and many more. Hundreds of
published papers discuss these and other aspects of simulator methodology.
Different models’ authors often disagree regarding the best choices
and use different methods. Implementation
can be as important as the choice of methods.
For example, Adaptive Implicit should be more efficient than Impes.
But in one case two models, one using Impes, the other using Adaptive
Implicit, were run on the same data and machine. The Impes run was six times faster. A more extreme
example is given on the Miscible page of this website. Code efficiency can be a
factor. Sensor uses no pre-compilers or other code efficiency enhancers.
As in the
case of accuracy, model speed is best judged by actual model runs. In
addition, the comparisons should be “fair”.
We might run the same dataset on the same machine on Sensor and on
Company A’s Model A and find CPU times of four hours
for Model A. However, if we
asked Company A to run the problem, they might well make minor input
parameter changes to obtain a two or three hour run.
* Reference numbers are those of the Sensor Manual.
Do parallel applications provide any overall performance advantage in
simulation on multicore machines, or on any other hardware?
Even though parallel applications may provide single run speedup, the answer
is no, except where available memory is not sufficient to run multiple
serial cases (the current maximum single-process memory of 512 GB is enough for a
million cell case in Sensor, or 32
simultaneous ten million cell cases). That exception now
possibly includes only a few gigantic fields, but it won't exist for very
long since the available memory is doubling every year or two. Single
runs provide no value. It is the evaluation of sensitivities to many
control and uncertain variables obtained from many runs that allows
predictive optimization. Serial applications can make far more
efficient use of multicore machines (or any other hardware with sufficient
memory) than parallel applications can, since they don't have to pay for the
parallel inefficiencies caused by coupled domains. By running 1
simultaneous serial application per core or processor (on 64 bit hardware generally
capable of providing far more than sufficient memory) to simultaneously
evaluate multiple sensitivities, you can achieve the maximum run rate that
the hardware and software is capable of.
Running one simultaneous serial application per core, or
one per processor on single-core machines, maximizes the hardware output in
terms of the rate it can execute floating point operations (Floating
Operations Per Second, or FLOPS). Using Sensor (1) minimizes FLOs required
per run, (2) avoids parallel sub-process communication and
synchronization requirements, problems,
and inefficiencies and (3) maximizes the overall run rate.
One of our clients was previously running a
single porosity black oil field case using the leading parallel model on an
8-node cluster. They can now run Sensor on each node 15 times faster
than their previous parallel run time using all 8 nodes. Overall,
that's a speedup of 120, over two orders of magnitude. This is much
greater than the black oil speedup we usually see, even considering the huge
parallel inefficiencies. One of the causes (accounting for a factor of
2 or 3) is that for some reason the parallel model wouldn't run well in Impes, while Sensor's Impes formulation was significantly faster than its
Q: In John Killough's original 1995 SPE9 paper, SPE 29110 referenced
on your Who's Fastest? page, Sensor is reported as being only
30% faster than VIP, on the same machine. Yet, your Who's Fastest?
page shows that Sensor is currently 5 or 6 times faster than VIP on that
problem. How can that be?
A: See SPE 29111 (originally presented at the
same conference as 29110, later published as SPE 50990 in SPEREE) - the cpu
time reported for Sensor on SPE9, on the same machine used to run Sensor and
VIP in SPE 29110, shows that Sensor was about 2.5 times faster than VIP in
1995, when using our Nested Factorization solver that we had recently
completed. The Sensor SPE9 run times in SPE 29110 were obtained from
an older version using a solver provided by Phillips that had been used
during early Sensor development. Since 1995, many improvements have
been made and continue to be made to Sensor.
Q: What size problems
can be run on Sensor, and what
is the hardware cost?
A: Problem size is limited only
by addressable machine memory. For any run, Sensor prints the required memory
allocation at the top of the output file. The
required memory depends upon more factors than just the numbers of
components and active grid blocks.
For example, the NF solver requires less storage than the default RBILU(0)
solver. The Table below is a rough guide for Impes cases. For the
implicit formulation, memory requirement is higher and increases more
rapidly with the number of components.
memory required by your run exceeds the available memory on your PC, the run
elapsed (wall clock) time may significantly exceed CPU time due to paging
(use of virtual memory). Sensor
elapsed and CPU times are about the same when available
memory is not exceeded (see the
times appearing at the bottom of the downloadable example problem output files).
The Sensor6k executable is a Windows 32-bit version,
but will run on Windows 32-bit and Windows x64 operating systems
(through the WOW32 emulator). On 32-bit systems, the
maximum memory addressable by a process is 2 GB. This allows black oil
problems roughly on the order of a million blocks.
On Windows x64 operating systems
(8, 7, Vista, XP, Server 2003, or Compute Cluster Server 2003), maximum memory
addressable by the 32-bit executable is 4 GB, allowing black oil problems on
the order of 2 million blocks. Our 64-bit version,
allows access of more memory (up to the machine limit, theoretical = 8 TB).
The maximum physical memory currently available on computers running Windows
8 (x64) is 512 GB (it is 192 GB for Windows 7),
allowing Sensor black oil cases up to about 320 million cells.
Cost for those machines with the maximum 512 GB RAM may range into the tens
of thousands, but currently available 64-bit machines with 16 to 64 GB of memory
are inexpensive and are more than sufficient for most cases. The pc with 16 GB can accommodate cases up to about
million cells, or 10 simultaneous million cell cases (since
Sensor Impes memory requirement varies linearly with problem size as in
above table). If the
theoretical maximum memory addressable by 64 bit processes, 8 TB RAM, were
available, Sensor could run impes black oil cases up to about 5
cells on a single
All estimated maximum problem sizes mentioned above apply
to Impes black oil cases. The user is cautioned that good efficiency
(particularly) in Impes cases requires that grid block sizes (pore volumes) must not be small.
If they are, timestep size limitations will and should be expected to cause
prohibitively long run times, particularly for larger problems. See
the discussion of cpu time scaling with problem size on page 2 of this
section. Also, the ability to run very large problems is not by itself
a good justification to do so. Grid dimensions (number of gridblocks)
should be chosen as the smallest required to control the effects of
numerical dispersion on results while adequately describing geology. In general, very large
problems are justified only by very large reservoirs.
Can you indicate in one place all the steps necessary to run the Sensor
simulator and plot results with Plot2Excel?
We illustrate for spe1.dat, and compare results with a modified spe1 case.
Create a work directory (folder), for example C:\sensor\testspe1, using
Windows Explorer, or to do so by command line from a script or manually from
a Command Prompt Window (to open go to Start/Programs/Accessories and
select Command Prompt), enter the following commands:
You have created and are now in the work directory.
2. Copy your data file into your work directory.
The spe1.dat file is provided in the directory given by the environment
variable %sensordata%. This is easy to do manually by copy/paste from
Windows Explorer, but from a script or from command line following (1)
above, you can enter:
copy "%sensordata%\spe1.dat" .
Notice the space followed by the period at the end (the
period means 'here'). The quotation marks are required when the path
name contains blanks, including the expanded name of any environment
3. If executing manually and the Command
Prompt Window is not open from (1) and (2) above - go to
Start/Programs/Accessories and select Command Prompt, then in the Command
Prompt Window, go to the work directory, by entering for example:
4. Execute sensor. Execute in a script or
manually enter in the Command Prompt Window:
sensor spe1.dat spe1.out
Move or rename fort.61 to (say) "f61spe1" (move
Change the spe1.dat data file to allow no gas solution above bubble
point (as indicated in comments in the spe1.dat data file) and save the
changed file as spe1a.dat.
sensor spe1a.dat spe1a.out
or rename fort.61 to (say) "f61spe1a".
In the work directory, construct
the SensorPlot data file (say) "spe1.sp" as:
SPE1 compare cases of gas going into sol'n
and not going into sol'n above 4014 psia bubble pt.
! Sensor result file and a
source name as a single word.
! any name desired
(Y2) GOR (T) SPE1 EFFECT OF Rs SOLUTION GAS ABOVE BP
CUMOIL (Y2) CUMGAS
Enter at command prompt:
You will be prompted for the name of the SensorPlot data file, enter "spe1.sp". See
file “SensorPlot.inf” for the run summary.
will generate 2 files: “spe1.tab” with data tables and “spe1.plt”
with plot-log records.
Open MS Excel and follow the instructions
on page 10 of the SensorPlot Manual. It will guide you through Plot2Excel to build and view the requested plots.
Note: If you are making many runs and always want the same plots, you can
construct the ".sp" file once with the file name
"fort.61" entered under file.
Then after each run when you want plots, you need only enter
"SensorPlot.exe" and proceed from there. The downloadable Sensor data files include SensorPlot data files of
".sp" extension for spe1, spe2, spe3, spe5, spe7, spe9, spe10,
test2, test3a and test16.
Q: How do Sensor run times scale with problem
A: We illustrate using spe1 as an example.
This case takes about 0.2 cpu seconds on our 2.8 GHz desktop.
If the numbers of blocks and wells are increased by a factor of n, while keeping the grid
block sizes (dx, dy, dz) the same (i.e., the reservoir is replicated by a factor of n), average timestep size will remain about the
same, and the larger case should take approximately n x (0.2 cpu seconds). If spe1 is increased from 10 x 10 x 3 (300
blocks) to 800 x 800 x 3 (almost 2 million blocks), then n=6400 and the
larger case should take about 21 minutes on our machine.
However, if the total reservoir size is fixed, and the
grid block sizes (dx, dy, dz) are decreased such that the total number of
blocks are increased by a factor of n, average timestep size will be reduced
by a factor of n, and the larger case should be expected to take
approximately n x n x (0.2 cpu seconds). Here, we are assuming that
the number of wells and their boundary conditions and spatial locations
remain fixed. We would expect this 800 x 800 x 3 run (n=6400) to take
about 93 days on our machine.
This illustrates the importance of not using block sizes
that are significantly smaller than those required to control numerical dispersion
while adequately describing geology. The model can and
should be used to determine those requirements by examining the sensitivity
of results to the level of spatial discretization, using upscaling methods
of the user's choice.
While most of the provided example cases are small,
Sensor's performance advantage is not a function of the number of gridblocks.
Q: What tuning is needed or recommended for high
efficiency and stability in Sensor?
A: Selections of formulation (default Impes,
or IMPLICIT card for fully implicit) and linear solution option (default ILU,
or NF card for Nested Factorization) can significantly affect performance.
While in some cases a particular formulation is called for (like Implicit
for radial coning problems), in general we recommend test runs to determine
the optimum selections. Very rare cases require modification of
timestep/run control or other solver control defaults. Some options
may improve performance. We recommend that 2D and 3D Impes runs should
be tried first with an entry of CFL 2 for stable step control.
Reduction of the stable step size may be needed in some cases to eliminate
oscillations. The PERC card specifying percolation control in Impes
runs sometimes gives good speedup for gassy oil problems. See Section
7.1 in the Sensor Manual for further discussion of recommended run control.
Q: Can unstructured grids be
used with Sensor?
Yes. They are specified using the structured Cartesian format, in the
form of transmissibilities and cell pore volumes and depths. This is
essentially an accounting problem and must be performed by an unstructured
gridding program. The number of blocks in the x, y, and z directions
are set to include a sufficient number of cells. Any extra cells are
deactivated and cause no penalty. The unstructured cells are ordered
in some way, and the corresponding specified structured transmissibilities
either represent a true unstructured connection, or are zero where no
unstructured connection exists. All other unstructured connections are
specified as non-neighbor connections (transmissibilities). The
connections are assumed k-orthogonal, i.e. Sensor does not employ a multipoint
flux approximation. Since
Sensor's linear solvers are already coded in an unstructured manner, the
unstructured nature of the grid does not cause performance penalties, unlike
some other models with structured matrix representations. Well
intersections and perforation well indices are also computed by the
unstructured gridding program. Map visualization requires an
unstructured viewer linked to the Sensor output and to the unstructured grid
Sensor can also model dual porosity/dual permeability
systems in unstructured grids, through entry of approximately equivalent
rectilinear gridblock dimensions, along with rectilinear matrix block
Q: What about hybrid
Sensor can handle any combination of grid systems that the gridding program
is able to describe.
Q: Can Sensor handle local
Yes. But the refinements must be set up by a gridding program or
pre-processing step in the
context of structured and non-neighbor connections in Sensor's single xyz
grid. This is similar to the setup for unstructured grids described above.
RExcel now performs this function for Sensor (http://www.santecpe.com).
Q: What are the limitations of Analytical and Numerical Simulation?
Techniques for Reservoir Management and
Requirements for Substantiation.
Also see our
Uncertainty Quantification and
SensorPx pages. Inability to account for
uncertainty can be a severe limitation in reservoir modeling. When the
uncertainties have significant effects on results, probabilistic analysis is
needed for optimization and forecasting.