Example

DATES

1 JAN 1998 /

15 JAN 1998 /

1 MAR 1998 /

1 JUL 1998 /

1 JAN 1999 /

/

Order of actions

When determining where to put e.g. a well action in the SCHEDULE section to get it to happen at the desired time, it can be helpful to observe that Eclipse reads the section only as far as necessary. I.e. once it encounters a TSTEP or DATES, it will start to advance the solution to the specified next milestone, using the data it regards as current.

Example

Start date has been defined as 1. Jan 2004 in the RUNSPEC section (ref the basic data input example). An order of input could then be,

SCHEDULE

WELSPECS

...

COMPDAT

...

WCONPROD

...

--The defined wells and rates are valid from start date, and will

--now be used when advancing the solution to 1. FEB 2004

DATES

1 FEB 2004 /

/

WELTARG

...

--The current date is 1.FEB 2004. So the change defined in WELTARG

--will happen at this date

--The solution will now be advanced first to 1.MAR 2004, then

-- further to 1.APR 2004, using the current rate defined in WELTARG DATES

1 MAR 2004 /

1 APR 2004 /

/

.

.

8.3 Convergence Control I (keyword TUNING)

This subject will be covered later, but deserves some mentioning here.

Only exceptionally can the solution be advanced from one milestone to the next (as described in 8.2) in a single ministep. Eclipse has a default handling of its solution procedure, in this context mainly by adjusting the ministep size. The TUNING keyword is used when the user wants to override Eclipse default behaviour.

When advancing the solution we want to take as large ministeps as possible (to minimize computing time). On the other hand there is an upper limit to the possible ministep size, which depends on the solution procedure and the solution itself. The way Eclipse tries to optimize this procedure is by looking at the ministep it has just finished. If the solution was found without problems, Eclipse will take this as a signal that the length of the ministep can be increased. If on the other hand the solution

51

was only found after convergence problems, Eclipse will take that as a hint that the ministep size should be reduced (chopped).

There are some parameters that governs this behaviour,

Example of how these parameters are used, assuming the default values.

When the simulation starts, the length of the ministep is 1 day (TSINIT). If the solution is found without problems, the length of the ministep will be increased, by a factor TSFMAX, so the following ministep will be 3 days. As long as the convergence is OK, the ministeps will be increased by a factor 3 (TSFMAX) every time, so the next ministeps would be 9, 27, 81 days. (Evolved time after these ministeps would be 1 day, 4 days, 13 days, 40 days, 121 days.) The solution at 121 days, following the 81 days time step was found after convergence problems, so the ministep size is reduced, hence the following step will be 81 * 0.3 (TSFMIN) = 24.3 days long. If the solution was not found at all, we had a convergence failure, and the next step would be 81 * 0.1 (TSFCNV) = 8.1 days. In this manner the length of the ministep will fluctuate between TSMINZ and TSMAXZ, increasing length when all is well, chopping when problems are encountered.

Often we observe that every time the ministep length is increased beyond some value, the following step has convergence problems, and the step length is chopped. In such cases it is much more optimal to redefine TSMAXZ to a value which allows for OK convergence, and hence the simulation will progress without convergence problems and chopping (which are computer time demanding). In the example above, we observed that 81 days was too much. If we later saw that every time the ministep length became larger than 60 days, the following step was chopped, then it would be wise to set e.g. TSMAXZ = 50 days.

What these numbers should be is very case-dependent, and no rules of thumb can be given. The essential information is in the run log or .PRT file. So this output should always be examined after a run!

The keyword TUNING is used to set convergence flags. It is comprised of three records, the first one handles primarily time step control, the second one contains internal convergence controls, and should as a general rule never be modified. The third record contains controls on the iteration schemes, which will be covered later.

At this stage we only look at the first record, and leave record 2 and 3 at default values. The syntax of the first record is then,

TUNING

TSINIT TSMAXZ TSMINZ TSMCHP TSFMAX TSFMIN TSFCNV TFDIFF ... /

Note: TSINIT is the first ministep following the TUNING keyword, not the first step in the simulation as such.

Example,

Set max length of any ministep to 45 days, reduce increase factor after OK convergence to 2.0, and enter the other default values explicitly:

52

9. Regions

So far we have tacitly assumed that the reservoir can be regarded as a single entity in all aspects. This will seldom or never be true. A single set of relative permeability curves will rarely be valid everywhere, compaction will normally be dependent on soil type etc.

In general, Eclipse allows for subdividing the reservoir into sub-sets, or regions. The regions serve two different purposes. One is to subdivide the reservoir into separate regions which are described by different characterizations of various kinds. The most common of these are,

•Regions of validity for relative permeability curves, SATNUM

•Regions for different sets of PVT-data, PVTNUM

•Regions where different equilibration parameters exist, EQLNUM

•Regions for different compaction data, ROCKNUM

The other kind of regions is for reporting purposes only. We may be interested in e.g. how much water flows from one part of the reservoir to another. The user may subdivide the reservoir into as many regions as desired in any possible manner, and request separate reports for each region (see later). The standard way of doing this is by the keyword FIPNUM (Fluid-In-Place regions), but additional user defined regions are possible, ref. Eclipse documentation.

The way the regions are defined and used is very similar for the different kinds of regions, so we take SATNUM as an example.

The SATNUM keyword defines the saturation regions. Each grid cell is assigned one SATNUM

number between 1 and NSATNUM, the total number of regions. Then if a certain grid cell belongs to SATNUM region number M, this means that the relative permeability data for this grid cell will be

obtained from table number M. Hence instead of defining a single family of relative permeability curves, we must now specify NSATNUM tables (of each kind).

Example

Assume our grid is 10 x 20 x 6 grid cells. One set of relative permeability curves is to be used in the two upper layers (K=1 and K=2), another set in layers 3 and 4, and a third set in layers 5 and 6. NSATNUM = 3, and we would specify the SATNUM regions (in the REGIONS section), as

SATNUM

400*1 400*2 400*3 /

whereby the two upper layers (10x20x2 = 400 cells) are assigned to SATNUM region 1, the next two layers to SATNUM region 2, and the last two layers to region 3.

Instead of the single relative permeability table we used in chapter 4, we will now need three, as,

0.30.0046 0.712 2.7

0.80.167 0.004 0.033

0.30.0046 0.712 2.7

0.80.167 0.004 0.033

53