For your convenience, the description of the keywords in the ERT configuration file
are divided into the following groups:
Commonly used keywords
NUM_REALIZATIONS
This is the size of the ensemble, i.e. the number of
realizations/members in the ensemble. All configs must contain this
keyword.
Example:
-- Use 200 realizations / members
NUM_REALIZATIONS 200
DEFINE
With the DEFINE keyword you can define key-value pairs which will be
substituted in the rest of the configuration file. The DEFINE keyword expects
two arguments: a key and a value to replace for that key. Later instances of
the key enclosed in ‘<’ and ‘>’ will be substituted with the value. The value
can consist of several strings, in that case they will be joined by one single
space.
Example:
-- Define ECLIPSE_PATH and ECLIPSE_BASE
DEFINE < ECLIPSE_PATH > / path / to / eclipse / run
DEFINE < ECLIPSE_BASE > STATF02
DEFINE < KEY > VALUE1 VALUE2 VALUE3 VALUE4
-- Set the GRID in terms of the ECLIPSE_PATH
-- and ECLIPSE_BASE keys .
GRID < ECLIPSE_PATH >/< ECLIPSE_BASE >. EGRID
The last key defined above (KEY) will be replaced with VALUE1 VALUE2
VALUE3 VALUE4 - i.e. the extra spaces will be discarded.
DATA_FILE
Meant to be set to the filepath of an eclipse simulator input, when such
a simulator is used. This does two things. First, the DATA_FILE will be
templated, see RUN_TEMPLATE NUM_CPU
The templated file will be named according to ECLBASE RUN_TEMPLATE
Example:
-- Load the data file called ECLIPSE . DATA
DATA_FILE ECLIPSE . DATA
See the DATA_KW
This is used to replace ERT magic strings into the data file, as well as
update the number of cpus that are reserved for ERT in the queue system.
It searches for PARALLEL in the data file, and if that is not found it
will search for SLAVE and update <NUM_CPU> according to how many nodes are
found, note that it does not parse the data files of the nodes, and will
assume one cpu per node where entry number 5 is not set, and the number of
entry number 5 otherwise plus one cpu for the master node.
It is strongly recommended to use the RUN_TEMPLATE NUM_CPU RUN_TEMPLATE
ECLBASE
The ECLBASE keyword sets the basename for the ECLIPSE simulations which will
be generated by ERT. It can (and should, for your convenience) contain <IENS>
specifier, which will be replaced with the realization numbers when running
ECLIPSE. Note that due to limitations in ECLIPSE, the ECLBASE string must be
in strictly upper or lower case.
Example:
-- Use eclipse / model / MY_VERY_OWN_OIL_FIELD -< IENS > etc . as basename .
-- When ECLIPSE is running , the < IENS > will be , replaced with
-- realization number , and directories '' eclipse / model ''
-- will be generated by ERT if they do not already exist , giving :
--
-- eclipse / model / MY_VERY_OWN_OIL_FIELD - 0
-- eclipse / model / MY_VERY_OWN_OIL_FIELD - 1
-- eclipse / model / MY_VERY_OWN_OIL_FIELD - 2
-- ...
-- and so on .
ECLBASE eclipse / model / MY_VERY_OWN_OIL_FIELD -< IENS >
If not supplied, ECLBASE will default to JOBNAME, and if JOBNAME is not set,
it will default to “<CONFIG_FILE>-<IENS>”.
JOBNAME
Sets the name of the job submitted to the queue system. Will default to
ECLBASE If that is set, otherwise it defaults to “<CONFIG_FILE>-<IENS>”. If JOBNAME
is set, and not ECLBASE, it will also be used as the value for ECLBASE.
GRID
This is the name of an existing GRID/EGRID file for your ECLIPSE model.
It is used to enable parametrization via the FIELD keyword. If you had
to create a new grid file when preparing your ECLIPSE reservoir model
for use with ERT, this should point to the new .EGRID file. The main
use of the grid is to map out active and inactive cells when using
FIELD data and define the dimension of the property parameter files in
the FIELD keyword. The grid argument will only be used by the main ERT
application and not passed down to the forward model in any way.
A new way of handling property values for the FIELD keyword is to use a
help grid called ERTBOX grid. The GRID keyword should in this case
specify the ERTBOX filename (which is in EGRID format). The ERTBOX grid
is a grid with the same spatial location and rotation (x,y location) as
the modelling grid, but it is a regular grid in a rectangular box. The
dimensions of the ERTBOX grid laterally is the same as the modelling
grid, but the number of layers is only large enough to store the
properties for one zone, not the whole modelling grid.
The number of layers must at least be as large as the number of layers
in the zone in the modelling grid with most layers. The properties used
in the FIELD keyword have the dimension of the ERTBOX grid and
represents properties of one zone from the modelling grid. Each grid
cell in the modelling grid for a given zone corresponds to one unique
grid cell in the ERTBOX grid. Inactive grid cells in the modelling grid
also corresponds to grid cells in the ERTBOX grid. There may exists
layers of grid cells in the ERTBOX grid that does not corresponds to
grid cells in the modelling grid. It is recommended to let all grid
cells in the ERTBOX grid be active and have realistic values and not a
‘missing code’. For cases where the modelling grid is kept fixed for
all realisations, this is not important, but for cases where the number
of layers for the zones in the modelling grid may vary from realisation
to realisation, this approach is more robust. It avoids mixing real
physical values from one realisation with missing code value from
another realization when calculating updated ensemble vectors.
Example:
-- Load the . EGRID file called MY_GRID . EGRID
GRID MY_GRID . EGRID
NUM_CPU
This keyword is set right in your configuration file:
Its meaning varies depending on context. For LSF it equates to the -n https://www.ibm.com/support/knowledgecenter/SSWRJV_10.1.0/lsf_command_ref/bsub.n.1.html .
E.g. NUM_CPU 10 10 increase
wait times, since LSF might need to wait until resources are freed in order to
allocate 10 processors.
For TORQUE, it literally is a check that NUM_CPU NUM_NODES|NUM_CPUS_PER_NODE
For the local queue system, NUM_CPU
DATA_KW
The keyword DATA_KW can be used for inserting strings into placeholders in the
ECLIPSE data file. For instance, it can be used to insert include paths.
Example:
-- Define the alias MY_PATH using DATA_KW . Any instances of < MY_PATH > ( yes , with brackets )
-- in the ECLIPSE data file will now be replaced with / mnt / my_own_disk / my_reservoir_model
-- when running the ECLIPSE jobs .
DATA_KW MY_PATH / mnt / my_own_disk / my_reservoir_model
The DATA_KW keyword is of course optional. Note also that ERT has some
built in magic strings.
RANDOM_SEED
Optional keyword, if provided must be an integer. Use a specific
seed for reproducibility. The default is that fresh unpredictable
entropy is used. Which seed is used is logged, and can then be used
to reproduce the results.
ENSPATH
The ENSPATH should give the name of a folder that will be used
for storage by ERT. Note that the contents of
this folder is not intended for human inspection. By default,
ENSPATH is set to “storage”.
Example:
-- Use internal storage in / mnt / my_big_enkf_disk
ENSPATH / mnt / my_big_enkf_disk
The ENSPATH keyword is optional.
HISTORY_SOURCE
In the observation configuration file you can enter
observations with the keyword HISTORY_OBSERVATION; this means
that ERT will extract observed values from the model
historical summary vectors of the reference case. What source
to use for the historical values can be controlled with the
HISTORY_SOURCE keyword. The different possible values for the
HISTORY_SOURCE keyword are:
REFCASE_HISTORY This is the default value for HISTORY_SOURCE,
ERT will fetch the historical values from the xxxH
keywords in the refcase summary, e.g. observations of
WGOR:OP_1 is based the WGORH:OP_1 vector from the
refcase summary.
REFCASE_SIMULATED In this case the historical values are based on the
simulated values from the refcase, this is mostly relevant when you want
compare with another case which serves as ‘the truth’.
When setting HISTORY_SOURCE to either REFCASE_SIMULATED or REFCASE_HISTORY you
must also set the REFCASE variable to point to the ECLIPSE data file in an
existing reference case (should be created with the same schedule file as you
are using now).
Example:
-- Use historic data from reference case
HISTORY_SOURCE REFCASE_HISTORY
REFCASE / somefolder / ECLIPSE . DATA
The HISTORY_SOURCE keyword is optional.
REFCASE
The REFCASE key is used to provide ERT an existing ECLIPSE simulation
from which it can read various information at startup. The intention is
to ease the configuration needs for the user. Functionality provided with the
refcase:
The REFCASE keyword should point to an existing ECLIPSE simulation;
ert will then look up and load the corresponding summary results.
Example:
-- The REFCASE keyword points to the datafile of an existing ECLIPSE simulation .
REFCASE / path / to / somewhere / SIM_01_BASE . DATA
The refcase is used when loading HISTORY_OBSERVATION and in some scenarios when using SUMMARY_OBSERVATION.
With HISTORY_OBSERVATION the values are read directly from the REFCASE. When using
SUMMARY_OBSERVATION the REFCASE is not strictly required. If using DATE in the observation
configuration the REFCASE can be omitted, and the observation will be compared with the summary
response configured with ECLBASE. If REFCASE is provided it will validated that the DATE
exists in the REFCASE, and if there is a mismatch a configuration error will be raised.
If using HOURS, DAYS, or RESTART in the observation configuration, the REFCASE is required and will
be used to look up the date of the observation in the REFCASE.
INSTALL_JOB
The INSTALL_JOB keyword is used to instruct ERT how to run
external applications and scripts, i.e. defining a job. After a job has been
defined with INSTALL_JOB, it can be used with the FORWARD_MODEL keyword. For
example, if you have a script which generates relative permeability curves
from a set of parameters, it can be added as a job, allowing you to do history
matching and sensitivity analysis on the parameters defining the relative
permeability curves.
The INSTALL_JOB keyword takes two arguments, a job name and the name of a
configuration file for that particular job.
Example:
-- Define a Lomeland relative permeabilty job .
-- The file jobs / lomeland . txt contains a detailed
-- specification of the job .
INSTALL_JOB LOMELAND jobs / lomeland . txt
The configuration file used to specify an external job is easy to use and very
flexible. It is documented in Customizing the simulation workflow in ERT.
The INSTALL_JOB keyword is optional.
OBS_CONFIG
The OBS_CONFIG key should point to a file defining observations and associated
uncertainties. The file should be in plain text and formatted according to the
guidelines given in Creating an observation file for use with ERT
If you include HISTORY_OBSERVATION in the observation file, you must
provide a reference Eclipse case through the REFCASE keyword.
Example:
-- Use the observations in my_observations . txt
OBS_CONFIG my_observations . txt
The OBS_CONFIG keyword is optional, but for your own convenience, it is
strongly recommended to provide an observation file.
RESULT_PATH
ERT will print some simple tabulated results at each report
step. The RESULT_PATH keyword should point to a folder where the tabulated
results are to be written. It can contain a %d specifier, which will be
replaced with the report step. The default value for RESULT_PATH is
“results/step_%d”.
Example:
-- Changing RESULT_PATH
RESULT_PATH my_nice_results / step -% d
The RESULT_PATH keyword is optional.
RUNPATH
The RUNPATH keyword should give the name of the folders where the ECLIPSE
simulations are executed. It should contain <IENS> and <ITER>, which
will be replaced by the realization number and iteration number when ERT creates the folders.
By default, RUNPATH is set to “simulations/realization-<IENS>/iter-<ITER>”.
Deprecated syntax still allow use of two %d specifers. Use of more than two %d specifiers,
using multiple <IENS> or <ITER> keywords or mixing styles is prohibited.
Example:
-- Using < IENS > & < ITER > specifiers for RUNPATH .
RUNPATH / mnt / my_scratch_disk / realization -< IENS >/ iter -< ITER >
Example deprecated syntax:
-- Using RUNPATH with two % d specifers .
RUNPATH / mnt / my_scratch_disk / realization -% d / iteration -% d
The RUNPATH keyword is optional.
RUNPATH_FILE
When running workflows based on external scripts it is necessary to ‘tell’ the
external script in some way or another were all the realisations are located in
the filesystem. Since the number of realisations can be quite high this will
easily overflow the commandline buffer; the solution which is used is therefore
to let ERT write a regular file which looks like this:
0 / path / to / realization - 0 CASE0 iter
1 / path / to / realization - 1 CASE1 iter
...
N / path / to / realization - N CASEN iter
The path to this file can then be passed to the scripts using the
magic string <RUNPATH_FILE>. The RUNPATH_FILE will by default be
stored as .ert_runpath_list in the same directory as the configuration
file, but you can set it to something else with the RUNPATH_FILE key.
RUN_TEMPLATE
RUN_TEMPLATE
Example:
RUN_TEMPLATE my_text_file_template . txt my_text_file . txt
this will copy my_text_file_template
It is also possible to perform replacements in target file names:
Example:
DEFINE < MY_FILE_NAME > result . txt
RUN_TEMPLATE template . tmpl < MY_FILE_NAME >
If one would like to do substitutions in the ECLIPSE data file, that can be
done like this:
Example:
ECLBASE BASE_ECL_NAME % d
RUN_TEMPLATE MY_DATA_FILE . DATA < ECLBASE >. DATA
This will copy MY_DATA_FILE.DATA BASE_ECL_NAME0.DATA
If you would like to substitute in the realization number as a part of ECLBASE using
<IENS> %d
Example:
ECLBASE BASE_ECL_NAME -< IENS >
RUN_TEMPLATE MY_DATA_FILE . DATA < ECLBASE >. DATA
To control the number of CPUs that are reserved for ECLIPSE use
RUN_TEMPLATE NUM_CPU
NUM_CPU 4
ECLBASE BASE_ECL_NAME -< IENS >
RUN_TEMPLATE MY_DATA_FILE . DATA < ECLBASE >. DATA
In the ECLIPSE data file:
Parameterization keywords
The keywords in this section are used to define a parametrization of the ECLIPSE
model. I.e. defining which parameters to change in a sensitivity analysis
and/or history matching project.
FIELD
The FIELD keyword is used to parametrize quantities which have extent over the
full grid. In order to use the FIELD keyword, the GRID keyword must be supplied.
A parameter field (e.g. porosity or permeability or Gaussian Random Fields from APS) is defined as follows:
FIELD ID PARAMETER < ECLIPSE_FILE > INIT_FILES : / path /% d MIN : X MAX : Y OUTPUT_TRANSFORM : FUNC INIT_TRANSFORM : FUNC FORWARD_INIT : True
Here ID must be the same as the name of the parameter in the INIT_FILES.
ECLIPSE_FILE is the name of the file ERT will export this field to when
running simulations. Note that there should be an IMPORT statement in
the ECLIPSE data file corresponding to the name given with ECLIPSE_FILE in case
the field parameter is a field used in ECLIPSE data file like perm or poro.
INIT_FILES is a filename (with an embedded %d if FORWARD_INIT is set to False)
to load the initial field from. Can be RMS ROFF format, ECLIPSE restart format
or ECLIPSE GRDECL format.
FORWARD_INIT:True means that the files specified in the INIT_FILES are expected
to be created by a forward model, and does not need any embedded %d.
FORWARD_INIT:False means that the files must have been created before running
ERT and need an embedded %d.
The input arguments MIN, MAX, INIT_TRANSFORM and OUTPUT_TRANSFORM are all
optional.
MIN and MAX allows you to add a minimum and/or a maximum value with MIN:X and MAX:Y.
For Assisted history matching, the variables in ERT should be normally
distributed internally - the purpose of the transformations is to enable
working with normally distributed variables internally in ERT. Thus, the
optional arguments INIT_TRANSFORM:FUNC OUTPUT_TRANSFORM:FUNC INIT_TRANSFORM:FUNC OUTPUT_TRANSFORM:FUNC FUNC
Table 1 Transformation Functions
Function
Description
POW10
This function will raise x to the power of 10: \(y = 10^x\)
TRUNC_POW10
This function will raise x to the power of 10 - and truncate lower values at 0.001.
LOG
This function will take the NATURAL logarithm of \(x: y = \ln{x}\)
LN
This function will take the NATURAL logarithm of \(x: y = \ln{x}\)
LOG10
This function will take the log10 logarithm of \(x: y = \log_{10}{x}\)
EXP
This function will calculate \(y = e^x\) .
LN0
This function will calculate \(y = \ln{x} + 0.000001\)
EXP0
This function will calculate \(y = e^x - 0.000001\)
The most common scenario is that underlying log-normal distributed permeability in the
geo modelling software is transformed to become normally distributed in ERT, to achieve this you do:
1. INIT_TRANSFORM:LOG
2. OUTPUT_TRANSFORM:EXP
Regarding format of ECLIPSE_FILE: The default format for the parameter fields
is binary format of the same type as used in the ECLIPSE restart files. This
requires that the ECLIPSE datafile contains an IMPORT statement. The advantage
with using a binary format is that the files are smaller, and reading/writing
is faster than for plain text files. If you give the ECLIPSE_FILE with the
extension .grdecl (arbitrary case), ERT will produce ordinary .grdecl files,
which are loaded with an INCLUDE statement. This is probably what most users
are used to beforehand - but we recommend the IMPORT form. When using RMS APS
plugin to create Gaussian Random Fields, the recommended file format is ROFF binary.
Example A:
-- Use Gaussian Random Fields from APS for zone Volon .
-- RMS APSGUI plugin will create the files specified in INIT_FILES .
-- ERT will read the INIT_FILES in iteration 0 and write the updated GRF
-- fields to the files following the keyword PARAMETER after updating .
-- NOTE : The ERTBOX grid is a container for GRF values ( or perm or poro values ) and
-- is used to define the dimension of the fields . It is NOT the modelling grid
-- used in RMS or the simulation grid used by ECLIPSE .
FIELD aps_Volon_GRF1 PARAMETER aps_Volon_GRF1 . roff INIT_FILES : rms / output / aps / aps_Volon_GRF1 . roff MIN : - 5.5 MAX : 5.5 FORWARD_INIT : True
FIELD aps_Volon_GRF2 PARAMETER aps_Volon_GRF2 . roff INIT_FILES : rms / output / aps / aps_Volon_GRF2 . roff MIN : - 5.5 MAX : 5.5 FORWARD_INIT : True
FIELD aps_Volon_GRF3 PARAMETER aps_Volon_GRF3 . roff INIT_FILES : rms / output / aps / aps_Volon_GRF3 . roff MIN : - 5.5 MAX : 5.5 FORWARD_INIT : True
Example B:
-- Use perm field for zone A
-- The GRID keyword should refer to the ERTBOX grid defining the size of the field .
-- Permeability must be sampled from the geomodel / simulation grid zone into the ERTBOX grid
-- and exported to / some / path / filename . Note that the name of the property in the input file
-- in INIT_FILES must be the same as the ID .
FIELD perm_zone_A PARAMETER perm_zone_A . roff INIT_FILES : / some / path / perm_zone_A . roff INIT_TRANSFORM : LOG OUTPUT_TRANSFORM : EXP MIN : - 5.5 MAX : 5.5 FORWARD_INIT : True
GEN_DATA
The GEN_DATA key is used to declare a response which corresponds to a
GENERAL_OBSERVATION gd_%d gd_0 gd_1 %d is the report step).
The contents of these result are always of this format:
exactly one floating point number per line .
Indexing GEN_DATA``refers to row number in the forward model's output file,
where the index 0 refers to the first row.
``GEN_DATA GENERAL_OBSERVATION
The GEN_DATA keyword has several options, each of them required:
RESULT_FILE - This is the name of the file generated by the forward
model and read by ERT. This filename _must_ have a %d as part of the
name, that %d will be replaced by report step when loading.
REPORT_STEPS - A list of the report step(s) where you expect the
forward model to create a result file. I.e. if the forward model
should create a result file for report steps 50 and 100 this setting
should be: REPORT_STEPS:50,100. If you have observations of this
GEN_DATA data the RESTART setting of the corresponding
GENERAL_OBSERVATION must match one of the values given by
REPORT_STEPS.
Example:
GEN_DATA 4 DWOC RESULT_FILE : SimulatedWOC % d . txt REPORT_STEPS : 10 , 100
Here we introduce a GEN_DATA instance with name 4DWOC. When the forward
model has run it should create two files with name SimulatedWOC10.txt
and SimulatedWOC100.txt. For every realization, ERT will look within its storage
for these result files and load the content. The files must always contain one number per line.
ERT does not have any awareness of the type of data
encoded in a GEN_DATA GEN_DATA GEN_DATA
GEN_DATA 4 DWOC RESULT_FILE : SimulatedWOC_ % d . txt REPORT_STEPS : 0
The 4DWOC RESULT_FILE:SimulatedWOC%d.txt <runpath>/SimulatedWOC_0.txt
The REPORT_STEPS:0 %d %d REPORT_STEPS: %d 0 SimulatedWOC_0.txt REPORT_STEPS:0,10,20 SimulatedWOC_0.txt, SimultedWOC_10.txt SimulatedWOC_20.txt one result file at report step 0 , in the future the possibility to
load one keyword GEN_DATA GEN_DATA quite strict - it will
fail if the RESULT_FILE %d
Observe that since the actual result file should be generated by the forward
model, it is not possible for ERT to fully validate the GEN_DATA SimulatedWOC_0 .txt SimulatedWOC_0.txt
GEN_KW
The General Keyword, or GEN_KW
where ID priors.txt
Given a priors.txt
where A UNIFORM 0 1
The various prior distributions available for the GEN_KW here
When the forward model is started the parameter values are added to a file located in
runpath called: parameters.json
{
"ID" : {
"A" : 0.88 ,
},
}
This can then be used in a forward model, an example from python below:
#!/usr/bin/env python
import json
if __name__ == "__main__" :
with open ( "parameters.json" , encoding = "utf-8" ) as f :
parameters = json . load ( f )
# parameters is a dict with {"ID": {"A": <value>}}
Note: A file named parameters.txt parameters.json
GEN_KW
GEN_KW ID templates / template . txt include . txt priors . txt
where ID templates/template.txt include.txt priors.txt
As a more concrete example, let’s configure GEN_KW MULTPV
GEN_KW PAR_MULTPV multpv_template . txt multpv . txt multpv_priors . txt
In the GRID or EDIT section of the ECLIPSE data file, we would insert the
following include statement:
The template file multpv_template.txt
BOX
1 10 1 30 13 13 /
MULTPV
300 *< MULTPV_BOX1 > /
ENDBOX
BOX
1 10 1 30 14 14 /
MULTPV
300 *< MULTPV_BOX2 > /
ENDBOX
Here, <MULTPV_BOX1> <MULTPV_BOX2>` < > multpv_priors.txt
MULTPV_BOX2 UNIFORM 0.98 1.03
MULTPV_BOX1 UNIFORM 0.85 1.00
In general, the first keyword on each line in the parameter configuration file
defines a key, which when found in the template file enclosed in < >
Note that ERT only stores values sampled from a standard normal distribution,
and a transformation is performed based on the configuration that is loaded
from file. This means that if the distribution file is changed, the transformed
values written to the run path will be different the next time ERT is started,
even though the underlying value stored by ERT has not changed
Example: Using GEN_KW to estimate fault transmissibility multipliers
Previously ERT supported a datatype MULTFLT for estimating fault
transmissibility multipliers. This has now been deprecated, as the
functionality can be easily achieved with the help of GEN_KW. In the ERT
config file:
GEN_KW MY - FAULTS MULTFLT . tmpl MULTFLT . INC MULTFLT . txt
Here MY-FAULTS MULTFLT.tmpl
MULTFLT
'FAULT1' < FAULT1 > /
'FAULT2' < FAULT2 > /
/
and finally the initial distribution of the parameters FAULT1 and FAULT2 are
defined in the file MULTFLT.txt
FAULT1 LOGUNIF 0.00001 0.1
FAULT2 UNIFORM 0.00 1.0
Loading GEN_KW values from an external file
The default use of the GEN_KW keyword is to let the ERT application sample
random values for the elements in the GEN_KW instance, but it is also possible
to tell ERT to load a precreated set of data files, this can for instance be
used as a component in an experimental design based workflow. When using
external files to initialize the GEN_KW instances you supply an extra keyword
INIT_FILE:/path/to/priors/files%d
GEN_KW MY - FAULTS MULTFLT . tmpl MULTFLT . INC MULTFLT . txt INIT_FILES : priors / multflt / faults % d
In the example above you must prepare files priors/multflt/faults0 priors/multflt/faults1 priors/multflt/faultsn
The files can be plain ASCII text files with a list of numbers:
The numbers will be assigned to parameters in the order found in the
MULTFLT.txt
Alternatively values and keywords can be interleaved as in:
in this case the ordering can differ in the init files and the parameter file.
The heritage of the ERT program is based on the EnKF algorithm, and the EnKF
algorithm evolves around Gaussian variables - internally the GEN_KW variables
are assumed to be samples from the N(0,1) distribution, and the distributions
specified in the parameters file are based on transformations starting with a
N(0,1) distributed variable. The slightly awkward consequence of this is that
to let your sampled values pass through ERT unmodified you must configure the
distribution NORMAL 0 1 in the parameter file; alternatively if you do not
intend to update the GEN_KW variable you can use the distribution RAW.
Regarding templates: You may supply the arguments TEMPLATE:/template/file
and KEY:MaGiCKEY. The template file is an arbitrary existing text file, and
KEY is a magic string found in this file. When ERT is running the magic string
is replaced with parameter data when the ECLIPSE_FILE is written to the
directory where the simulation is run from. Consider for example the following
configuration:
TEMPLATE : / some / file KEY : Magic123
The template file can look like this (only the Magic123 is special):
Header line1
Header line2
============
Magic123
============
Footer line1
Footer line2
When ERT is running the string Magic123 is replaced with parameter values,
and the resulting file will look like this:
Header line1
Header line2
============
1.6723
5.9731
4.8881
.....
============
Footer line1
Footer line2
SURFACE
The SURFACE keyword can be used to work with surface from RMS in the irap
format. The surface keyword is configured like this:
SURFACE TOP OUTPUT_FILE : surf . irap INIT_FILES : Surfaces / surf % d . irap BASE_SURFACE : Surfaces / surf0 . irap
The first argument, TOP in the example above, is the identifier you want to
use for this surface in ERT. The OUTPUT_FILE key is the name of surface file
which ERT will generate for you, INIT_FILES points to a list of files which
are used to initialize, and BASE_SURFACE must point to one existing surface
file. When loading the surfaces ERT will check that all the headers are
compatible. An example of a surface IRAP file is:
- 996 511 50.000000 50.000000
444229.9688 457179.9688 6809537.0000 6835037.0000
260 - 30.0000 444229.9688 6809537.0000
0 0 0 0 0 0 0
2735.7461 2734.8909 2736.9705 2737.4048 2736.2539 2737.0122
2740.2644 2738.4014 2735.3770 2735.7327 2733.4944 2731.6448
2731.5454 2731.4810 2730.4644 2730.5591 2729.8997 2726.2217
2721.0996 2716.5913 2711.4338 2707.7791 2705.4504 2701.9187
....
The surface data will typically be fed into other programs like Cohiba or RMS.
The data can be updated using e.g. the smoother.
Initializing from the FORWARD MODEL
Parameter types like FIELD and SURFACE (not GEN_KW) can be
initialized from the forward model. To achieve this you just add the setting
FORWARD_INIT:True to the configuration. When using forward init the
initialization will work like this:
The explicit initialization from the case menu, or when you start a
simulation, will be ignored.
When the FORWARD_MODEL is complete ERT will try to initialize the node
based on files created by the forward model. If the init fails the job as a
whole will fail.
If a node has been initialized, it will not be initialized again if you run
again.
When using FORWARD_INIT:True ERT will consider the INIT_FILES setting to find
which file to initialize from. If the INIT_FILES setting contains a relative
filename, it will be interpreted relatively to the runpath directory. In the
example below we assume that RMS has created a file petro.grdecl which
contains both the PERMX and the PORO fields in grdecl format; we wish to
initialize PERMX and PORO nodes from these files:
FIELD PORO PARAMETER poro . grdecl INIT_FILES : petro . grdecl FORWARD_INIT : True
FIELD PERMX PARAMETER permx . grdecl INIT_FILES : petro . grdecl FORWARD_INIT : True
Observe that forward model has created the file petro.grdecl and the nodes
PORO and PERMX create the ECLIPSE input files poro.grdecl and permx.grdecl, to
ensure that ECLIPSE finds the input files poro.grdecl and permx.grdecl the
forward model should contain a job which will copy/convert petro.grdecl ->
(poro.grdecl,permx.grdecl), this job should not overwrite existing versions of
permx.grdecl and poro.grdecl. This extra hoops is not strictly needed in all
cases, but strongly recommended to ensure that you have control over which
data is used, and that everything is consistent in the case where the forward
model is run again.
SUMMARY
The SUMMARY keyword is used to add variables from the ECLIPSE summary file to
the parametrization. The keyword expects a string, which should have the
format VAR:WGRNAME. Here, VAR should be a quantity, such as WOPR, WGOR, RPR or
GWCT. Moreover, WGRNAME should refer to a well, group or region. If it is a
field property, such as FOPT, WGRNAME need not be set to FIELD.
Example:
-- Using the SUMMARY keyword to add diagnostic variables
SUMMARY WOPR : MY_WELL
SUMMARY RPR : 8
SUMMARY F * -- Use of wildcards requires that you have entered a REFCASE .
The SUMMARY keyword has limited support for ‘*’ wildcards, if your key
contains one or more ‘*’ characters all matching variables from the refcase
are selected. Observe that if your summary key contains wildcards you must
supply a refcase with the REFCASE key - otherwise only fully expanded keywords will be used.
Note: Properties added using the SUMMARY keyword are only
diagnostic. I.e. they have no effect on the sensitivity analysis or
history match.
Analysis module
The term analysis module refers to the underlying algorithm used for the analysis,
or update step of data assimilation.
The keywords to load, select and modify the analysis modules are documented here.
ANALYSIS_SET_VAR
The analysis modules can have internal state, like e.g. truncation cutoff
values. These can be manipulated from the config file using the
ANALYSIS_SET_VAR keyword for either the STD_ENKF or IES_ENKF module.
ANALYSIS_SET_VAR < STD_ENKF | IES_ENKF > ENKF_TRUNCATION 0.98
INVERSION
The analysis modules can specify inversion algorithm used.
These can be manipulated from the config file using the
ANALYSIS_SET_VAR keyword for either the STD_ENKF or IES_ENKF module.
STD_ENKF
Table 2 Inversion Algorithms for Ensemble Smoother
Description
INVERSION
IES_INVERSION (deprecated)
Note
Exact inversion with diagonal R=I
EXACT
0
Subspace inversion with exact R
SUBSPACE_EXACT_R / SUBSPACE
1
Preferred name: SUBSPACE
Subspace inversion using R=EE’
SUBSPACE_EE_R
2
Deprecated, maps to: SUBSPACE
Subspace inversion using E
SUBSPACE_RE
3
Deprecated, maps to: SUBSPACE
IES_ENKF
Table 3 Inversion Algorithms for IES
Description
INVERSION
IES_INVERSION (deprecated)
Note
Exact inversion with diagonal R=I
EXACT / DIRECT
0
Preferred name: DIRECT
Subspace inversion with exact R
SUBSPACE_EXACT_R / SUBSPACE_EXACT
1
Preferred name: SUBSPACE_EXACT
Subspace inversion using R=EE’
SUBSPACE_EE_R / SUBSPACE_PROJECTED
2
Preferred name: SUBSPACE_PROJECTED
Subspace inversion using E
SUBSPACE_RE
3
Deprecated, maps to: SUBSPACE_PROJECTED
Setting the inversion method
IES_MAX_STEPLENGTH
The analysis modules can specify the Gauss-Newton maximum steplength
for the IES_ENKF 0.60 [0.1, 1.00]
ANALYSIS_SET_VAR IES_ENKF IES_MAX_STEPLENGTH 0.6
IES_MIN_STEPLENGTH
The analysis modules can specify the Gauss-Newton minimum steplength
for the IES_ENKF 0.30 [0.1, 1.00]
ANALYSIS_SET_VAR IES_ENKF IES_MIN_STEPLENGTH 0.3
IES_DEC_STEPLENGTH
The analysis modules can specify the Gauss-Newton steplength decline
for the IES_ENKF 2.5 [1.1, 10.0]
ANALYSIS_SET_VAR IES_ENKF IES_DEC_STEPLENGTH 2.5
LOCALIZATION
The analysis module has capability for enabling adaptive localization
correlation threshold.
This can be enabled from the config file using the
ANALYSIS_SET_VAR keyword but is valid for the STD_ENKF False
ANALYSIS_SET_VAR STD_ENKF LOCALIZATION True
LOCALIZATION_CORRELATION_THRESHOLD
The analysis module has capability for specifying the adaptive
localization correlation threshold value.
This can be specified from the config file using the
ANALYSIS_SET_VAR keyword but is valid for the STD_ENKF 0.30
ANALYSIS_SET_VAR STD_ENKF LOCALIZATION_CORRELATION_THRESHOLD 0.30
ENKF_TRUNCATION
Truncation factor for the SVD-based EnKF algorithm (see Evensen, 2007). In
this algorithm, the forecasted data will be projected into a low dimensional
subspace before assimilation. This can substantially improve on the results
obtained with the EnKF, especially if the data ensemble matrix is highly
collinear (Saetrom and Omre, 2010). The subspace dimension, p, is selected
such that
\(\frac{\sum_{i=1}^{p} s_i^2}{\sum_{i=1}^r s_i^2} \geq \mathrm{ENKF\_TRUNCATION}\)
where si is the ith singular value of the centered data ensemble matrix and r
is the rank of this matrix. This criterion is similar to the explained
variance criterion used in Principal Component Analysis (see e.g. Mardia et
al. 1979).
The default value of ENKF_TRUNCATION is 0.98. If ensemble collapse is a big
problem, a smaller value should be used (e.g 0.90 or smaller). However, this
does not guarantee that the problem of ensemble collapse will disappear. Note
that setting the truncation factor to 1.00, will recover the Standard-EnKF
algorithm if and only if the covariance matrix for the observation errors is
proportional to the identity matrix.
References
Evensen, G. (2007). “Data Assimilation, the Ensemble Kalman Filter”, Springer.
Mardia, K. V., Kent, J. T. and Bibby, J. M. (1979). “Multivariate Analysis”, Academic Press.
Saetrom, J. and Omre, H. (2010). “Ensemble Kalman filtering with shrinkage regression techniques”, Computational Geosciences (online first).