The technique called nested factorisation is a step-by-step procedure to build the preconditioning matrix B. The method may look complex and laborious, but keep in mind that it is an iterative construction, such that the right hand sides of the following equations are to be understood as “the values known from previous iteration”.

The procedure is initialised by constructing G cell by cell using (75), and then the updates (72) – (75) are performed iteratively until convergence (B changes less than tolerance between two iterations).

“colsum” means the column sum of the matrix.

The way G is defined implies that colsum(A) = colsum(B), which ensures no mass balance errors.

18. Convergence Control II – TUNING parameters

Summing up the discussion of the previous chapters,

At time step tn, we have a solution v = (pw, po, pg, Sw, So, Sg).

To advance the solution to time tn+1, with ∆t = tn+1 – tn, we must solve a nonlinear problem. The solution procedure was,

Define nonlinear problem F(v, tn+1) = 0.

1.Solve nonlinear problem by Newton-Raphson, using v0 = v(tn) as start value.

a.Construct “tangent” – total differential of non-linear problem.

linear system Ax = b.

b.Solve linear system

i.Precondition matrix

ii.orthomin – iterations

iii.End iterations when system has converged

2.Continue iterations until system has converged.

In this solution procedure, there are many parameters which have influence on how the iteration procedure performs.

1.∆t.

All iteration processes perform best if the starting value is close to the sought solution. E.g. returning to the first non-linear problem we solved with Newton-Raphson (Figure 31), it is easy to imagine that if f(x) has many zeros, and we start far from the sought one, we are going

to get the wrong result. If ∆t is small, the solution will probably not change that much over a time step, so that the iteration starting value v(tn) is close to the sought solution v(tn+1). In general we want ∆t as large as possible, but it is always an option to reduce the time step size if convergence problems do occur.

2.Iteration control on outer (Newton) iterations.

a.The error tolerance, when has the process converged?

b.The maximum number of iterations.

Normally the process will converge after not too many iterations.

But what if it doesn’t? It may happen that we are facing a problem that will never converge. We can’t allow the computer to continue iterating till the end of history, so at some time we must say “enough is enough”.

c.What to do if the problem for some reason didn’t converge?

99

3.Iteration control on inner (linear) iterations

a.Error tolerance

b.Maximum number of linear iterations

c.How many search directions (q-vectors) to keep in memory?

In principle all q-vectors should be kept for good performance, but in practice available computer memory doesn’t permit this.

d.What to do if linear system does not converge.

Time step control was discussed in section 8.3, and some more follows below.

The other parameters can all be controlled by the user, and although Eclipse has a good automatic time step and convergence control, for large problems user action will often be required to achieve optimal performance.

In general it is not recommended to change the default values for error tolerances. These are defined in the second record of the TUNING keyword, which as a rule of thumb should never be altered. (No rule without exceptions of course.)

The third record of the TUNING keyword has the syntax (using Eclipse terminology),

NEWTMX NEWTMN LITMAX LITMIN MXWSIT ...

The parameter controlling the number of q-vectors to store is not defined in TUNING. Since this parameter directly affects the amount of computer memory to reserve, it must logically be defined in the RUNSPEC section, with keyword NSTACK:

Example

NSTACK 16 /

sets the number of search directions to keep to 16. (The reason for the name is that the memory area where the vectors are stored is organized as what in computer terminology is called a stack.)

The default value of NSTACK is 10.

Obviously, the way LITMAX and NSTACK are related, defining an NSTACK larger than LITMAX is going to be a waste of memory space, since the total number of q-vectors that are defined throughout the process can’t be larger than the number of linear iterations.

I.e.: Always use NSTACK ≤ LITMAX.

The default values for time step and iteration control work fine in many simulations, especially for small or medium sized problems. Three phase simulations are more likely to create convergence problems than oneor two-phase problems. How to improve performance in simulations is often a result of trial and error, and is definitely assisted by experience with the simulator.

It should be mentioned that Eclipse will often try to advice on how to improve convergence when problems occur. But these advises are not based on some artificial intelligence analysis of the problem, so should be read with some scepticism. E.g. if LITMAX is set to 100, and Eclipse advises you to “increase LITMAX”, the advice can safely be disregarded.

Relative roles of time step, LITMAX and NEWTMX

To move the simulation from time t1 to t2, where we have experienced convergence problems, all three parameters ∆t, LITMAX and NEWTMX can contribute to improved performance, so which buttons to turn? Eclipse will always attempt to use as large time steps as possible, but clearly

100

simulating from t1 to t2 in one step, with 100 Newton iterations, each using 50 linear iterations, will take longer time than dividing the time step in two, if the iterations at each time step are reduced to something like 70 Newton iterations with 30 linear iterations at each step. (First alternative uses a total of 100 * 50 = 5000 iterations, second alternative uses 2 * 70 * 30 = 4200 iterations).

Typical values for actually used number of iterations are in the order of 10-20 linear iterations in each Newton iteration, and rarely more than 10 Newton iterations at each time step. If the simulation persistently requires (substantially) more than this at every time step, it is probably wise to reduce the maximum permitted time step.

Eclipse will report any convergence irregularities in the PRT-file, and to the output window (or logfile). In addition many convergence related parameters can be output as summary data (chapter 11). Linear convergence failure will normally not be dramatic, while non-linear convergence failure is.

This can easily be seen if we go back to the original Newton-Raphson problem, Figure 31. The objective is to find the intersection between f(x) and the x-axis. The linear iterations are used to solve each linear problem, corresponding to finding the intersection between a tangent and the x-axis. Failure in this task means that one or more of the xi on the x-axis will not be in its correct position. But it shouldn’t be hard to imagine that the procedure will continue to work, and a solution eventually found, even if some of the xi may be wrong. Convergence failure of the non-linear equations, however, means that the intersection was never found – i.e. the problem had no solution, or at least we couldn’t find it. This is of course serious, and we can hardly accept it.

Eclipse’s way of handling the convergence irregularities reflect our view.

•A linear convergence failure will be reported as a warning (and a suggestion to increase LITMAX and/or NSTACK), but the procedure continues in the hope that it will be selfcorrecting (as we intuitively see the model problem in Figure 31 will be).

o By the same kind of argument, it is not always necessary or important to force full convergence of the linear equations. If the linear solution is “good enough” to be used further in the procedure after a number of iterations, the procedure will not necessarily be accelerated by running still a few dozens of linear iterations to improve the linear solution marginally. These kinds of questions are very difficult to decide. In general, the best simulation performance can be expected when all linear equations are fully converged at each non-linear iteration.

•Non-linear convergence failure should not be taken lightly. Eclipse will then have to accept an erroneous solution, without knowing how bad it is (it could be so close to the sought solution that no harm is done, or it could be really way off – Eclipse only knows that it didn’t come within the convergence tolerance). Eclipse (and the user) can only hope that the simulation will come “back on track” when the simulation is continued, but to increase the chances of success, the time step size is dramatically reduced for the following time steps.

o Most simulations are run several times, with variation of the data. Often time intervals where convergence problems can be expected can be identified. In such cases it is often wise to reduce the time step before the simulator enters the interval.

o How much the time step will be reduced (chopped) after the convergence failure is determined in the first record of TUNING

o There is an absolute minimum for both time step size and chopable time step size. If convergence failure occurs and the time step cannot be reduced, the chances of finding the way back to the narrow path are slim. Such situations should be avoided at “any” cost!

•As a rule of thumb, rapid changes of reservoir state will require smaller time steps. The classic example is the start of water injection in the oil zone. Since water saturation at the start of the injection is at minimum value, water mobility is zero, so the injected water cannot flow before water saturation is increased, which it will not before the water flows. Solving this problem is definitely easier with a small time step, so one recommendation would be to reset the time step to some small value (e.g. one day) before each major well event.

o No rule without exceptions. Although very rare, situations exist where the solution is so irregular that the convergence problems increase as the time step is reduced, and the most effective is to take one large time step crossing the troublesome interval in one go. (As said – this is exceptional, but should be mentioned...)

101