Reservoir simulation pdf

Item 5, GOC is the depth of the gas-oil contact ignored in single-phase, oil-water, and gas-water problems. Capillary pressures specified at the contacts items 4 and 6 will overrule capillary pressures defined in the relative permeability tables. Note that if a contact is not present in the reservoir it should be defined above or below the reservoir, not defaulted.

These are flags for specifying initial variation with depth of gas solution, bubble point, vaporised oil, or dew point. Eclipse documentation for details, as the flags will not be used in these notes. The Nacc parameter — accuracy of initial fluids in place calculations The initial vertical distribution of fluids will be governed by fluid densities and capillary forces.

Starting from the top and going downwards the typical distribution will be, gas, gas-oil transition zone, oil, oil-water transition, water. By initialisation we aim to define fluid saturations in each grid cell such that the system is in equilibrium, i. Appears obvious, but very often not obeyed in practice. For simplicity we discuss only the oil-water contact, and assume no transition zone, i. Only grid cells which contain the oil-water contact can pose problems. Recall that a grid cell is actually a point in space for the simulator, so although we can envisage a saturation variation within a cell volume, such a variation is not possible in a simulation cell — we can only assign one value of e.

So the question is, which value to choose? The simplest and perhaps most obvious solution is to use the saturation at the cell centre, i. Although Equation 16 is simple as it stands, it becomes rather complex if we try to generalise it to handle transition zones. Eclipse therefore uses an alternative approach to calculate initial cell saturations from exact fluid distribution.

Imagine the cell divided into a number of horizontal slices of equal thickness. For each such slice, the slice saturation is defined as the saturation at the slice centre. Then the cell saturation is the volume-average of the slice saturations. This saturation calculation will obviously be more accurate the more slices we use. The number of such slices is defined by the Nacc paramter. Nacc is limited to Note that the default value is -5 i.

The reservoir was discovered by an appraisal well in which a reservoir pressure of bars was measured at depth m SMSL. The oil water contact is at a depth of m, and there is no free gas present in the reservoir so we define GOC above the reservoir. We use the initially measured pressure as datum, and will initialise our three-phase model with the accurate fluids-in-place calculation with 20 slices, using the tilted cell option. No capillary transition zones. The full problem of proper initialisation cannot be discussed in these notes, but some basic features are presented, as they should be known by simulator users.

When building simulation models for real reservoirs in a commercial setting i. This can often only be achieved by using accurate fluids-in-place initialisation, so even though cell-centre initialisation has many advantages it is frequently not an option. Additionally, the initial saturation distribution in the reservoir is seldom or never as simple as a fluid contact with or without transition zone. Saturation distribution is generated from seismics and saturation vs. The bottom line is that we often wish to initialise our simulation grid with a certain saturation field, but this results in a non-equilibrium model.

Note that these should never be used if cell centre initialisation has been chosen. Basically, three flags can be set to control simulator behaviour: MOBILE: Adjusts rel-perm end points critical saturations such that relevant fluids are only just immobile at the calculated or defined initial saturations.

The changes are applied throughout, not only during initialisation. However, no one can argue that the means have a flavour of artificialness, and are outside the control and knowledge of the user. More importantly, the simulator does change the input data, and these modifications are not only used to force a stable initialisation, but will continue to be applied throughout the run, some times with unintentional behaviour as result.

The time dependent dynamic data describe how the reservoir is produced. Eclipse processes the dynamic data a little different, as the input file is only read as far as necessary to compute the next time step.

Basically, the section is comprised of three different kinds of data, 1. Specification of wells, and guidelines for production or injection. Control of progress of the numerical computational scheme optional 3. In reality wells can be simple or complex, and controlled by a number of devices, to meet surface constraints. Most simulators will therefore offer an extensive list of features for controlling simulator well behaviour, some of which we cover in the following section. Well specification.

Includes the static properties of the well as the well name, location, dimensions, Completion data. Although the well itself can penetrate a long part of the reservoir, it will be open for flow between well and reservoir only in limited sections actually holes , called completions or perforations, connections.

Specification of target rates and constraints for well production or injection. The first item is given only once for each well, and must be specified before any other well data can be defined.

The second kind of data changes occasionally, while the third kind typically is updated relatively often. In production simulation, wells are very often put under group control, which means that in stead of controlling each well individually, wells are organized in groups, and the control criteria applies to the group as such. Groups can also be organized hierarchically. Group control will however not be covered in these notes.

The well control keywords contain many flags, some of which are not needed in the simple problems we study in these notes. Each well definition consists of one line terminated by a slash, and an empty record is used to terminate the keyword.

All later reference to the well will be by Wname. Gname: Name of group to which the well belongs. Advice: Use some simple dummy-name, like G1. ZBHP Reference depth for bottom hole pressure. The flowing bottom hole pressure, PBHP, is the pressure inside the well bore. It varies with depth, but not that much if tubing wall friction can be neglected.

It is advised to set this value to the depth of the topmost perforation, which can be done by defaulting it. Phase Preferred phase for the well. Auto-shut-in Flag for determining what to do with the well if the simulator determines to close it6 due to some control violation. The options are, SHUT, which isolates the well completely from the reservoir, or STOP; which only plugs the well above the reservoir, and hence allows for crossflow after the well has been closed.

The STOP option is normally the most realistic compared to actual field wells, but will be more calculation intensive and can cause convergence problems, a reasonable reason for choosing SHUT. XFlowFlag Flag for defining if crossflow is permitted through the perforations This can and does occur in real wells, but the computational considerations discussed above are valid in this context also.

DensCalc At this stage, can be left at default value. Note that in all cases where a character-variable flag is expected, a unique abbreviation is accepted. Each line record contains data as described below. As each record is read existing data is updated such that the most recently read specification is the valid one.

Observe that the syntax is tailored for vertical wells. There is also a third option, AUTO. We contend ourselves with a simple example. Assume a well is completed down to m, with OWC at m. Further assume that in the simulation grid, both OWC and the well are in the same cell. In that case, the cell will contain mobile water such that the well will produce water immediately.

Obviously in reality, the well will not produce water before the OWC has risen to the well completion level. We could model this behaviour by defining an artificially high Swc in the well cell, such that the water would be seen as immobile until saturation reached a level which corresponds to the OWC having risen to the perforation. Kh Permeability thickness, i. This value is a measure for the production or injection capacity of the well. The default value is to take K as the cell permeability and h as the connection length, which is the cell thickness for a vertical well.

If the well is perforated across the entire cell it is normally OK to use the default value. But often the well is only perforated in part of the cell thickness, and also the average cell permeability may not be representative for the permeability in the interval that is perforated. In such cases it is better to specify the Kh explicitly. Dir The direction the well penetrates the cell. For a vertical well this is the Z-direction, for a horizontal well parallel to the x-axis X.

The choices are X, Y, or Z. Generally it is recommended to default this value, in which case the Peaceman equivalent radius will be used see below. Expression 18 actually requires that the well has a finite non- zero radius. We also recognize the permeability thickness in expression When a well is drilled the drilling pressure inside the well is normally kept higher than external reservoir pressure, to avoid reservoir fluids flowing into the well during drilling.

Normally drilling fluids will penetrate the reservoir, and the drill procedure itself can damage a zone near the well. Some times, a stimulating fluid is added to the damage zone to improve productivity. The bottom line is that in general there is a zone near the well where flow properties are different than those assumed when deriving Equation 18 , such that actually observed pressure drop differs from that predicted by Equation Pressure near wellbore pe p, bars Without skin pwf w.

And we cannot observe variation like the one described by Equation 20 unless we have a very fine grid near the well. What we need is some mechanism that relates the cell pressures we have computed in the simulator to the expressions above. In papers from and Peaceman showed that if the drainage radius re is replaced by an equivalent cell radius rb, Equation 22 can be used to compute max. Several suggestions for improving this expression has seen light during the last decades.

All connections are open for production. Default saturation table will be used, the wellbore diameter is 0. Well PROD2 is completed in cells 9, 5, 4 , 9, 5, 5 , and 9, 5, 6.

Only part of the layer thicknesses are perforated, so we will define the Kh-products manually. If no constraints are violated the rate will be determined by the primary guide, defined by the Control mode item. Each line record in the keyword contains production data for one well, and production specifications for a well are valid until they are redefined.

Eclipse documentation. CtrlMode Primary control mode for the well. The specified mode is the guiding mode that the well will be controlled by if no other constraints are violated.

Tables for Vertical Flow Performance Calculations are important for doing real field simulations, but will not be covered here. RESV is a special target. In principle it refers to a fluid rate measured at reservoir conditions.

But the flag RESV tries to come around this problem. Unfortunately, the calculation of equivalent reservoir fluid volumes are based on average reservoir pressure, not the pressure of the actually produced fluid.

So the RESV fluid volumes are only approximately correct. When the fluid flows from the reservoir to the surface in the well, the fluid pressure will decrease as the fluid moves upwards. The pressure drop is proportional to the completion depth, and more or less equal to hydrostatic pressure. Obviously, if the fluid leaves the reservoir at a pressure which is lower than the pressure drop it experiences on the way to the surface, it has too low energy to reach the surface at all.

Therefore, if fluids are to be produced without additional means of lifting, it is required that the fluid pressure is above some minimum level when they enter the well. This is the minimum required bottom hole pressure BHP. From Equation 21 we see that the BHP will be lower when the rate is increased. A BHP violation can therefore often be met by reducing rate. The reason for this is that THP is the pressure measured at the tubing head, i.

THP is hence an accessible measure, while BHP, measured in the reservoir is only available when such measurements are done, which will be relatively infrequent if at all. The VFP relations are complex, involving depths, tubing lengths and fluid saturations, and are beyond the scope of these notes.

We will therefore stick to the BHP constraints. The primary control mode is by oil rate, and the guides will be applied as follows: First Eclipse checks if it possible to fulfil the primary goal. If any of the items in the bullet list are violated, then Eclipse will attempt to reduce the oil rate until all the constraints are OK.

If it is not possible to fulfil the constraints with a positive oil rate, then Eclipse will write a message and close the well for the current time step. But at later time steps the well will be checked to see if it can be reopened. Observation: Violation on the secondary targets will generally not be discovered before at the end of the computations for the current time step.

Eclipse will therefore have to redo the entire calculations with redefined input, and iterate until a solution satisfying all constraints has been found. Note that for an injector, the argument is turned upside down, such that we now need a high surface pressure to get the fluid into the reservoir. If this is not possible, injection rate will be reduced so that the bottom hole pressure constraint is fulfilled.

Next the well INJ4 is defined. INJ4 will be controlled by bottom hole pressure, i. Another kind of constraints are those that are based on economy. A natural requirement for any well would be that the value of produced hydrocarbons from the well should as a minimum pay for the costs of maintaining the well.

The constraints are in order, minimum oil production rate, minimum gas production rate, maximum water cut, maximum gas-oil ratio, maximum water-gas ratio. If the specified minimum oil rate or gas rate cannot be satisfied, the well will be closed unconditionally. Eclipse documentation EndRunFlag Request for whether the simulation shall be terminated if the well is shut or stopped. If YES the simulation will continue till the next report step and then terminate.

Default is NO. The keyword has several additional items, ref. If these requirements are not met the offending well will be closed, but the run not terminated. But when the last well has been shut, there is no point in continuing the simulation.

For our purpose this will always be FIELD, in which case the constraints apply to the field as whole. It is suited for situations where only one parameter for a previously defined well shall be changed. The advantage is primarily in the post-processing phase, when target data can be compared to simulated results. Some down-time is unavoidable. This would however not be entirely correct, as the bottomhole pressure calculations would be based on an erroneous rate. A correct solution can be obtained by use of the WEFAC keyword well efficiency factor , which is used to specify the factor of producing time to total time.

In general, implicit solution schemes which Eclipse uses by default allow for larger time steps than explicit schemes. Although we will also adopt this sloppy terminology, we will firstly define a more accurate notation. The simulator will advance the solution from one point in time to another.

The size of the step is governed by the problem and the solution procedure, but some guidelines are often provided by the user. These solution-dependent time steps are called ministeps by Eclipse. The user will specify milestones times or dates of special interest. These milestones may be e.

Therefore, such snapshots are only produced on user specified times normally much larger intervals than the milestones described above.

How much Eclipse shall write to this file is determined by the user, and described later, at this stage we only note that Eclipse writes data to the. PRT file at the milestones. In addition, any change to well data or other dynamic data can only happen at the milestones. An obvious and minimum required use of the milestones is to tell the simulator how far forward in real time to simulate.

By this scheme the milestones would be after 5, 15, 30, 60, , , , , , and days. In practice we often know the milestones by date, not by time intervals, so it is more common to define the milestones by the DATES keyword. Eclipse knows about month lengths and leap years, so DATES is an easier way to define the milestones at the start of a year or month.

Example Start date has been defined as 1. FEB MAR , then -- further to 1. Only exceptionally can the solution be advanced from one milestone to the next as described in 8. Eclipse has a default handling of its solution procedure, in this context mainly by adjusting the ministep size. 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 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.

Evolved time after these ministeps would be 1 day, 4 days, 13 days, 40 days, days. 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. 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! 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. Example, Set max length of any ministep to 45 days, reduce increase factor after OK convergence to 2. 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. We may be interested in e. 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 way the regions are defined and used is very similar for the different kinds of regions, so we take SATNUM as an example. 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.

Example Assume our grid is 10 x 20 x 6 grid cells. Instead of the single relative permeability table we used in chapter 4, we will now need three, as, SWOF -- Sw krw kro Pcwo 0.

Simplified input and modification of Eclipse arrays We have earlier defined the default Eclipse input format for an array e. In general these commands work by first defining a box where the associated input applies, and then defining the input. The BOX keyword is used to set such a box explicitly, but the box can also be defined as a part of the input. NOTE: When a box has been defined, it remains valid until a new box is defined.

When Eclipse reads data it immediately performs an action on the data array it is processing. This action can be to overwrite an existing value, or do arithmetic to an existing value. With this knowledge we can build data arrays by repeated assigning and reassigning values, assuring that the end result is the final operations we performed.

Breakdown of the different edit-keywords, BOX A box is an index-cube, i. The standard array input format is hence a special case where the box is the entire reservoir. A terminating slash ends the keyword. The two ways we have done this are equivalent, i.

The rest is region 1. In region 1, porosity is 0. In region 2, porosity is 0. In this example we will first define data for the whole grid, then redefine in the central area. First defining one value for a large box here the entire grid and then redefining a sub-box is often efficient. Thereafter the modification keywords may be used if needed. Syntax for each line of keyword: SourceArray TargetArray Box Each line is terminated by a slash, and an empty record slash alone terminates the keyword.

Obviously the two boxes must be of the same size in all three directions. Eclipse output, formats and files A complete specification of the reservoir state at any time, i. Only data explicitly requested by the user are written to result files. If a needed data vector was not requested in result specifications, the simulation has to be re-run to obtain the desired data. Basically, Eclipse output can be divided into three different types, 1.

Textual output. Contains run summaries, feedback messages, warnings, and errors. Optionally text listing of data arrays or aggregate values. Output aimed at visualisation of time-dependent behaviour, i. Output aimed at keeping track of the reservoir state data array values in all cells at user defined times.

There are several options for how the files are written. At this time it is of special interest to note the difference between unified and non-unified files. Non-unified, which is the default, means that Eclipse writes a new file at every time step where output is requested. With unified files Eclipse stores all the relevant results in a single file. Unified has the advantage of fewer files in a folder, while some external software may require non-unified files.

If not specified non-unified files are used. This ending, or extension is called the file name tail. The part of the name before the separating period is called the file name root.

For historical reasons and compatibility it is recommended to use not more than 8 characters in the file name root. Obviously this cannot be the actual name of the data file. The first part of this file is a listing of the data input and interpretation phase. In addition to simple progress reports, any irregularities in input will be reported here, at three levels of seriousness, MESSAGE normally just information from Eclipse, as e.

The user is encouraged to check the origin of warnings. A typical warning is that pressure-dependent tables will be extrapolated if pressure goes above or below so-or-so. If the user is confident that such pressure levels will not occur, the warning is not a problem. If possible, a dataset with errors will be read and initialised as far as possible, but the simulation proper will not start.

Note that such errors are not found before they are encountered, which may be far into the run. If the simulation will not run, or stops unexpectedly, always suspect an error, and consult the report file, where hints to what went wrong normally can be found.

By default all input is written back to the report file. This is normally not desired, e. In the dynamic phase, a short convergence summary is written at each ministep. This includes current time, length of current time step ministep , why this length was chosen, how convergence performed, average reservoir pressure and water cut. For details ref. When starting Eclipse from the GeoQuest Launcher panel in a Windows-environment, a report log short summary including the messages, warning, errors, and convergence reports will be written to a console window.

Sometimes we would prefer to have this output to a file instead. This is possible in the MS Windows environment in linux use standard file redirection if we create a DOS batch file, e. LOG instead of to the command window. To execute the command, run the file ECL. The concept can easily be extended to enabling automatic starting of several Eclipse runs in a row, by inserting more lines of the same kind different data sets of course in the. BAT file, or running other programs in between the Eclipse runs, to check or modify results etc.

The RPTXXX keywords In addition to the data referred to above, which is always written to the report file, the user may specify which arrays to write to the file, and at which time steps if relevant.

Most users find that results are best processed graphically, hence keeping textual output to a minimum. But some times the numeric values are needed, so it is nice to know how they can be made available. Eclipse documentation if needed. Each of the other keywords is associated with a list of flags that turn writing of the specified feature on or off. The number of flags is very long, so here we concentrate on the most common flags — for complete specification ref.

Can also be used to control writing of restart files, which will be covered later. As noted above, textual output of dynamic arrays like pressure, saturation is only exceptionally needed or desired, as they are normally better analysed by a visualisation program.

About any array can be output to the report file, ref. The most common is to show evolution of some variable vs. How to visualise results in a post-processing program will not be covered here. The important fact to notice is that Eclipse stores only those variables the user explicitly requests. The data to store are listed in the summary section, a complete list of permitted variables can be found in the Eclipse reference manual.

We concentrate on the general syntax, and some of the most common data. These names are so common that all Eclipse users should know at least the most used of these rules. For completeness we list all of the common ones , although some of the terms have yet not been defined time step means ministep.

Which and what is really logical from the context, and some can be defaulted. Also note that Eclipse always requires a terminating slash when keyword data is defined. Field keywords have no associated data, and hence no terminating slash. Statement valid also for all of the convergence report keywords.

Well keywords need the names of the wells, as e. In the early versions of Eclipse all character variables had to be enclosed in quotes. As newer versions have become available, more and more keywords permit character variables without the quotes, but there are still a few left.

Connection keywords require both a well name and a connection. Since each record is composite both well name and connection , each must be terminated with a slash, and an empty record terminates the keyword. For Region keywords, if the keyword data is associated with one region only, the region numbers must be listed, as e.

If the keyword data is associated with data from two regions, typically flow from one region to another, then a list of region-pairs must be defined, each pair terminated by a slash, e. An empty record terminates the keyword, e. S results from the first to the second milestone etc. The keyword EXCEL no associated data is then available, whereby Eclipse writes a file in format readable by a spreadsheet program as Excel.

The definition of the restart file is just to ensure that the contents of the file matches this requirement. The reason for wanting to do such restarts is most easily given by an example.

Assume we have run a simulation case for 20 years with a defined well scenario. We now want to compare the case to another case where we put an additional injection well on injection after 15 years. Obviously the first 15 simulated years are equal in the two cases, so we would have to perform an identical simulation for 15 years before we do the change.

If we have stored the reservoir state after 15 years in a restart file, then we could pick up the state from there, add another well and run only the last five years anew.

Details on how to do this will come later. Since restart files contain a complete description of the reservoir state, they are also well suited for graphic visualisation of the state, e. And by visualising several such restart data in a sequence, we can get a picture of how the reservoir state changes with time. The dates at which restart data are stored in the restart files are called restart dates. Since restart files tend to be large they are normally generated less frequently than the milestones.

Recommended intervals between restart dates are case-dependent, and would be based on how rapid the reservoir state changes, and the size of each file. Note that it is possible to specify that the restart files are only needed for visualisation purposes not actual restarts , which results in somewhat smaller files.

In a standard black oil simulation, pressure, gas and oil saturations, and gas resolution is written to the restart file by default. These parameters are therefore not necessary to request. Restart files will only be created at the requested dates if a time step is available. If for example milestones are defined every second year, restart files will not be created more often than every second year irrespective of what was requested in the RPTRST keyword. Also restart files will always be created on a milestone time step.

Jan , which is not a report time, but the first report time after that, namely 1. Initial file and initial restart file The initial file, or INIT-file contains all cell-valued static data, like porosity, permeability, It is useful to have this information available for graphic visualisation, so it is recommended to always request writing of an initial file.

Such a restart file contains information about all the dynamic data before any flow starts, and is normally useful. Note that the numbering of the X-files is synchronized with the summary files.

X is always the initial restart file if requested. X is the first restart file in the sequence not counting the initial , and is created at milestone X are written at the same date.

Note that this was different in early versions of Eclipse. Restarting a simulation As described above, a restart is what we do when we pick up the simulated state at some date where we have a restart file available , and start a new simulation from that date. Development of the state up to the point where we do the restart is then assumed to be described by the run we restart from.

We will not discuss the SAVE way here. The restarted run must be given a case name different from the original run. We will restart this run from time step milestone 20, where the state has been saved in a file CASE1. Fault modelling — Non-neighbour connections It is clear from Figure 7 or equivalent Figure 16 below that one characteristic of faults is that, which grid cells are neighbours is different when a fault is present than not. The fault plane in reality a volume is typically an area of crushed rock, with poorer properties than the non-fault volume.

To describe flow across a fault it is therefore necessary to define the possible flow paths, and the effective reduced fault permeability. At the end of a time step, the bottom hole injection pressure may theoretically be calculated using the well equation:.

As a better approximation, it is normally accepted to use the sum of the mobilities of the fluids present in the injection block in the well equation. Well equation which is often used for the injection of water in an oil-water system: k ro k rwi B. Injection wells are frequently constrained by a maximum bottom hole pressure, to avoid fracturing of the formation. This should be checked, and if necessary, reduce the injection rate, or convert it to a constant bottom hole pressure injection well.

By letting the hydrostatic pressure caused by the well filled with water control the injection pressure. At the end of the time step, the above equation may be used to compute the actual water injection rate for the step. Upstream mobility term. The water equation will have a water production term given by: Expansion of Discretized equations Boundary Conditions. Production wells are normally constrained by a minimum bottom hole pressure, for lifting purposes in the well. If this is reached, the well should be converted to a constant bottom hole pressure well.

If a maximum water cut level is exceeded for well, the highest water cut grid block may be shut in, or the production rate may have to be reduced. The rate terms contain unknown block pressures, these will have to be appropriately included in the matrix coefficients when solving for pressures.

At the end of each time step, actual rates are computed by these equations, and water cut is computed. The two equations are combined so that the saturation terms are eliminated.

The resulting equation is the pressure equation:. This equation may be solved for pressures implicitly in all grid blocks by Gaussian Elimination Method or some other methods. The saturations may be solved explicitly by using one of the equations. Using the oil equation yields:. Having obtained oil pressures and water saturations for a given time step, well rates or bottom hole pressures may be computed as q wi, qoi and Pbh.

Required adjustments in well rates and well pressures, if constrained by upper or lower limits are made at the end of each time step, before all coefficients are updated and we can proceed to the next time step. The evaluation of coefficients at old time level when solving for pressures and saturations at a new time level, puts restrictions on the solution which sometimes may be severe.

IMPES is mainly used for simulation of field scale systems, with relatively large grid blocks and slow rates of change. It is normally not suited for simulation of rapid changes close to wells, such as coning studies, or other systems of rapid changes. When time steps are kept small, IMPES provides accurate and stable solutions to a long range of reservoir problems.

A simple water injection case A simple quarter five spots model of oil displacement by water injection. The geometry dimension of the first case is 5 x 5 x 1 and second case is 50 x 50 x The oil Producer well at the corner was controlled by constant Bottom Hole Pressure BHP and the water injector well at the centre was controlled by constant injection rate.

Animation of Oil saturation, highest permeability layer at bottom with one water injector well in the left and one production well in right. Animation of Oil saturation, highest permeability layer at the top with one water injection well in the left and one oil production well in right.

Upstream mobility term Expansion of Discretized equations Boundary Conditions. Open navigation menu. Close suggestions Search Search. User Settings.

Skip carousel. Carousel Previous. Carousel Next. What is Scribd? To learn more, view our Privacy Policy. To browse Academia. Log in with Facebook Log in with Google.

Remember me on this computer. Enter the email address you signed up with and we'll email you a reset link. Need an account? Click here to sign up. Download Free PDF. Introduction to Reservoir Simulation. Ekine Etuge. A short summary of this paper. Simulators for various recovery processes have been developed and continue to be developed for new oil recovery processes. Reservoir simulation is the art of combining physics, mathematics, reservoir engineering, and computer programming to develop a tool for predicting hydrocarbon reservoir performance under various oper- ating strategies.

In this figure, formulation outlines the basic assumptions inherent to the simulator, states these assumptions in precise mathematical terms, and applies them to a control volume in the reservoir. The result of this step is a set of coupled, nonlinear partial differential equations PDEs that describes fluid flow through porous media.

The PDEs derived during the formulation step, if solved analytically, would give reservoir pressure, fluid saturations, and well flow rates as continuous functions of space and time. Because of the highly nonlinear nature of the PDEs, however, analytical techniques cannot be used and solutions must be obtained with numerical methods. In contrast to analytical solutions, numerical solutions give the values of pressure and fluid saturations only at discrete points in the reservoir and at discrete times.

Discretization is the process of converting PDEs into algebraic equations. Several numerical methods can be used to discretize the PDEs; however, the most common approach in the oil industry today is the finite difference method. The most commonly used finite difference approach essentially builds on Taylor series expansion and neglects terms that are considered to be small when small difference in space parameters is considered.

This expanded form is a set of algebraic equations. Finite element method, on the other hand uses various functions to express variables in the governing equation.