Page [ 1 ]

Q:  In what ways does Sensor treat black oil and compositional problems differently?

A: 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 data.

Q:  What shortcuts, approximations, or sacrifices to accuracy, if any, explain the CPU times of Sensor?

A: 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 properly isolated equilibrium regions, insert two data lines TIME 100/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 problems^37-43*.  In one case, CPU times among five participants varied by a factor up to 50 for the same dataset and same machine⁴⁰.   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.

Q:  Do parallel applications provide any overall performance advantage in simulation on multicore machines, or on any other hardware?

A:  Even though parallel applications may provide single run speedup, the answer is no, except where the current maximum single-process memory of 128 GB may not be sufficient to run the problem serially (that's enough for an 80 million cell case in Sensor, or 8 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 allow 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 (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 point operations per second, or FLOPS).  Using Sensor minimizes FLOs required per run, avoids parallel sub-process communication requirements, problems, and inefficiencies and 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 Implicit formulation.

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.

When the 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 (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 new 64-bit version, SENSOR 64, now allows access of more memory (up to the machine limit, theoretical = 8 TB).  The maximum physical memory currently available on computers running x64 has recently doubled to 128 GB, allowing Sensor black oil cases up to about 80 million cells.  Cost for those machines with the maximum 128 GB RAM may range into the tens of thousands, but currently available 64-bit machines with 8 to 16 GB of memory cost around US $4000 to $5000 and are more than sufficient for most cases.  The pc with 16 GB can accommodate cases up to about 10 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 billion cells on a single node.

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.

Q:  Can you indicate in one place all the steps necessary to run the Sensor simulator and plot results with Plot2Excel? 

A: We illustrate for spe1.dat, and compare results with a modified spe1 case.
1. 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:

cd C:\

mkdir sensor

cd sensor

mkdir testspe1

cd testspe1

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 variables.

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:

cd C:\sensor\testspe1

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 fort.61 f61spe1). 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.  Enter:

sensor  spe1a.dat  spe1a.out

Move or rename fort.61 to (say) "f61spe1a".   

5. In the work directory, construct the SensorPlot data file (say) "spe1.sp" as:

TITLE
  SPE1 compare cases of gas going into sol'n 
  and not going into sol'n above 4014 psia bubble pt.
ENDTITLE 

FILE
  f61spe1     Rs'>0   ! Sensor result file and a
  f61spe1a    Rs'=0   ! source name as a single word.

OUTPUTNAME
  spe1       ! any name desired

FIELD
  QOIL   (Y2) GOR    (T) SPE1 EFFECT OF Rs SOLUTION GAS ABOVE BP
  CUMOIL (Y2) CUMGAS
  PAVG   (Y2) OILREC
END 

Enter at command prompt:  SensorPlot.exe.  You will be prompted for the name of the SensorPlot data file, enter "spe1.sp". See file “SensorPlot.inf” for the run summary. SensorPlot will generate 2 files: “spe1.tab” with data tables and “spe1.plt” with plot-log records.

6. 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.

Page [ 1 ]