Preparing an ECLIPSE reservoir model for use with enkf
The Ensemble Kalman Filter algorithm is sequential in it's formulation. This means that unlike other assisted history matching tools ERT relies heavily on the restart capability of ECLIPSE. Thus, some preparatory steps must be taken to make a reservoir model ready for use with the ERT. In essence, the ECLIPSE data file has to be modified so that:
- It can be started from any point in the file system.
- A non-unified restart file and summary file are written at each report step (i.e. at each DATES, TIME and TSTEP keyword in the ECLIPSE SCHEDULE section.).
- The layout of the active grid blocks is invariant between realizations.
This page explains the necessary modifications that are needed to prepare an ECLIPSE reservoir model for use with the ERT application. Some modifications are general, and applied to the whole data file, whereas some are needed only in specific sections of the data file.
When parsing the ECLIPSE data file, the enkf application can be used to replace a few magic keywords. This is of course entirely optional, but can be very convenient for e.g. uncertainty analysis.
General modifications and advises
Copy the orignal ECLIPSE data file
When your ECLIPSE data file is ready for use with ERT, it cannot be used directly (i.e. without the ERT application) with ECLIPSE. Thus, it is strongly recommended that you modify a copy of the original data file.
Use global INCLUDE and IMPORT statements
ERT will not run the ECLIPSE simulation in the same folder as the original ECLIPSE data file resides. Thus, it is necessary that all INCLUDE and IMPORT statements (expect for those files that will be generated by the ERT) in the ECLIPSE data file are global. I.e., the include statements shall have the full path to the included files.
-- CORRECT -- This statement is global. INCLUDE '/project/field/ressim/include/my_file.txt' / -- WRONG -- This statement contains a relative path. INCLUDE '../../include/my_file.txt' /
Use the PATHS keyword
The PATHS keyword in ECLIPSE can be used to create an alias for a path. This is very convenient if you need to move the entire project.
Modifications in the RUNSPEC section of the ECLIPSE data file
ERT expects non-unfied restart and summary files. If present, remove the UNIFOUT and UNIFIN keywords.
Modifications in the GRID section of the ECLIPSE data file
It may be necessary to modify the GRID section of the ECLIPSE data file to ensure that the layout of the active grid blocks is invariant between different realizations. This limitation comes from the EnKF algorithm itself, and can not easily be relaxed.
It is difficult to say up front if these modifications are necessary, but they typically are if:
- Stochastic realizations of porosity and/or net-to-gross are used.
- Pore volume is changed in the conditioning, using e.g. MULTPV or ADDZCORN.
- One of the two previous, together with aggressive use of MINPV or MINPVV.
Note: The ERT application will automatically detect if the layout of the active grid blocks has changed. Thus, it is safe to postpone these actions until the problems actually appear.
To ensure that the layout of the active grid blocks remain invariant between realizations, the following procedure is recommended:
- Copy the ECLIPSE data file to a new folder.
- In the copied data file, set all parameters that you plan to estimate and that can affect the pore volume to their lowest bound. This is done using e.g. the PORO, NTG and MULTPV keywords. Note that this limit can not be zero, as this will cause entire regions or even the whole grid to be deactivated! The lower limit will also need to be enforced when the problem is parametrized later on (e.g., if the stochastic porosity imported from rms can be zero, it will need to be truncated up to the lower limit used to map the active cells.).
- Use the copied data file to generate a new .EGRID file, e.g. start ECLIPSE with the copied data file. It is recommended that you add the NOSIM keyword before doing this. Note also that it might be necessary to change the GRIDFILE keyword to make ECLIPSE produce a .EGRID file. The following setting is recommended:
GRIDFILE 2 1 /
- Check the .PRT file from the ECLIPSE run. If a too large portion of the grid blocks were deactivated, the lower limits has to be increased and a new .EGRID file has to be created. In some cases, it may also be necessary to lower the value of the MINPV or MINPVV keywords. If this is done, you must use the same value for MINPV or MINPVV in the ECLIPSE data file that is used with the ERT.
- Use the tool kw_extract.x to extract the necessary grid information (kw_extract.x should be installed in the same path as the ERT.). Replace MY_GRID with the basename of your ECLIPSE model and issue the commands:
kw_extract.x MY_GRID.EGRID COORD.imp COORD kw_extract.x MY_GRID.EGRID ZCORN.imp ZCORN kw_extract.x MY_GRID.EGRID ACTNUM.imp ACTNUM
You can also collect all the keywords in one file with
kw_extract.x MY_GRID.EGRID MY_GRID_INFO.imp ZCORN COORD ACTNUM
- In the grid section of the data file that you plan to use with the enkf, replace INCLUDE statements including COORD/ZCORN/ACTNUM etc. with the following IMPORT statements:
IMPORT 'ZCORN.imp' / IMPORT 'COORD.imp' / IMPORT 'ACTNUM.imp' /
IMPORT 'MY_GRID_INFO.imp' /
- In the ECLIPSE data file which you will be using for ERT you should now comment out any occurences of MINPV/MINPVV.
- Take a copy of the actual .EGRID file, this should be given to enkf with GRID parameter in the main enkf configuration file.
The layout of the active cells should now be invariant between realizations.
Converting COORD.imp to COORD.grdecl
The files produced by the kw_extract.x program are binary and load faster into ECLIPSE than the ordinary grdecl files, i.e. in general we recommend using them. However if you want to use ordinary grdecl files it is reasonably simple to convert the files to this format. It is a two-step process:
- You must use the program convert.x (located at the same place as the ERT binary) to convert the file from unformatted to formatted.
convert.x COORD.imp COORD.grdecl
- Then you must open the COORD.grdecl file with an editor and update the header. When opening the file the top will look this:
Simplify to this
'COORD ' 671500 'REAL' .....
In addition you must add a terminating '/' at the end of the file.
One situation where this process might be necessary is when the path names are to long, ECLIPSE only handles 72 characters long filenames in IMPORT statements, whereas it can handle up to 132 characters in INCLUDE statements.
Modifications in the SOLUTION section of the ECLIPSE data file
The SOLUTION section in the ECLIPSE data file is used to specify initial conditions for the ECLIPSE run or restart. The actual ECLIPSE keywords used depends on whether the run is an ECLIPSE restart or not:
- If it is not an ECLIPSE restart, initial conditions are either calculated from equilibrium conditions using the EQUIL (and potentially SWATINIT) keyword, or given explicitly using e.g. SWAT, SGAS, PRESSURE etc.
- If it is an ECLIPSE restart, initial conditions are read from an ECLIPSE restart file given with the RESTART keyword.
These families of keywords are mutually exclusive, i.e. if you have an EQUIL keyword you can not have a RESTART keyword. Thus, the ERT application needs to modify a large part of the SOLUTION section automatically to make ECLIPSE run smoothly. In order to make this happen, you need to replace all initialization code in the ECLIPSE data file with a <INIT> string, see example below.
-- Keyword EQUIL removed. -- -- EQUIL -- -- Datum P woc Pc goc Pc Rsvd Rvvd N -- 2582.0 268.56 2692.0 0.0 2582.0 0.0 1 0 0 / -- Keyword RESTART removed. -- -- RESTART -- MY_ECLIPSE_MODEL 100 / -- Inserted <INIT> string to let ERT handle initialization. <INIT>
Output of inital restart file
This step is optional. If you want (or need) the initial restart file from the ECLIPSE run, you may need to change the RPTSOL keyword. There are many settings for this keyword that actually causes ECLIPSE to write the initial restart file, but at least the following works:
RPTSOL RESTART=2 /
Modifications in the SUMMARY section of the ECLIPSE data file
The SUMMARY section can generally be left untouched. However, you should make sure that data you want to use in the conditioning process (e.g. rates and BHP) is written to the summary file at each report step.
Modifications in the SCHEDULE section of the ECLIPSE data file
The SCHEDULE section of the ECLIPSE data file is used to control the temporal progression of the simulation. The ERT depends heavily on the SCHEDULE data. Thus, it is often necessary with some modifications to the SCHEDULE section.
Use a separate SCHEDULE file
ERT requires that the contents of the SCHEDULE section is in a separate file. When the ERT application is used, it will write an appropriate schedule file for the simulation type requested to the simulation folder. Thus, the INCLUDE statement used to source the contents of the SCHEDULE sections should be local.
SCHEDULE -- Commented out inclusion of original schedule file. -- INCLUDE -- '/project/field/ressim/schedule/my_schedule.INC' / -- Reading schedule file generated by the ERT on simulation start INCLUDE 'my_schedule.INC' / END
Do not use nested SCHEDULE files
Do not use the INCLUDE keyword in the schedule file. Nested schedule files will not be parsed correctly. This is normally not a problem with automatically generated schedule files.
Do not use the star (*) notation
Do not use the star notation to address a collection of wells or groups, nor to generate a sequence of e.g. timesteps using the TSTEP or TIME keyword. Schedule files which make use of the star notation are not parsed correctly. This is normally not a problem with automatically generated schedule files.
Ensure that the SKIPREST keyword is present
The SKIPREST keyword will cause ECLIPSE to skip subsequent keywords until restart time. It should be present at the very start of the schedule file. If the SKIPREST keyword is not present, the EnKF algorithm will not behave as expected!
Ensure that RPTSCHED and RPTRST keywords are correctly set
This is a common source of problems. To make enkf run smoothly, the following procedure is recommended:
- At the very start of the schedule file, add the following:
- Remove any subsequent RPTSCHED and RPTRST keywords.
Note: Automatically generated schedule files often have RPTSCHED and RPTRST "all over the place".
When ERT writes the ECLIPSE data file for a simulation it starts with the datafile, does some minor modifications to it and writes the updated file to the directory where the ECLIPSE simulation will be run. Before writing the updated datafile ERT does some search-replace operations of various magic strings. The string <INIT> must be inserted as described in initialization. In addition there are some other magic strings which are automatically available to use:
|<REPORT_STEP1>||The report step the simulation starts from in ECLIPSE number format, e.g. 0099.|
|<REPORT_STEP2>||The report step the simulation ends at, e.g. 0100.|
|<RESTART_FILE1>||The ECLIPSE restart file the simulation is starting from.|
|<RESTART_FILE2>||The ECLIPSE restart file the simulation ends with.|
|<ECL_BASE>||The base name of this ECLIPSE simulation.|
|<IENS>||The realization number, formatted as a plain intger starting at 0.|
Observe that in addition to these predefined strings all keywords you define with DATA_KW are available as magic strings in the datafile. In addition to the ECLIPSE datafile the search-replace operation is carried out on job-description of all the jobs in the forward model.
Example: Using different relperm models with <IENS>
This is most relevant when the ERT application is used for uncertainty evaluations and not actual history matching. Let us say you have generated ten different relperm tables and want to check the resulting variation in rates. If the ten relperm tables are stored ten different files:
RELPERM_0.INC RELPERM_1.INC RELPERM_2.INC ... RELPERM_9.INC
You could use the following include statement in your ECLIPSE file:
-- Including a pr. realization relperm model. INCLUDE '/some/path/to/relperm/RELPERM_<IENS>.INC' /
The <IENS> will then be replaced with realization number, effectively giving you ten different simulations. This can of course be used with different parameters as well.