Forward model jobs¶

Some of the forward models are connected and often the output of one is the input to another. However, they maintain the same format, and thus a subset of the jobs can be run independently. For example, if well_constraints is not necessary, it can be omitted, and if well_order is not a concern, the input to the well_constraints can be setup and copied (in the everest configuration, rather than using the drill_planner every time). Some of them are however mandatory, e.g. the add_templates is a prerequisite for the schmerge job.

Example

forward_model:
  - fm_drill_planner -i well.json
                     -c drill_planner_config.yaml
                     -opt optimizer_values.yml
                     -o wells_dp_result.json
  - fm_well_constraints -i wells_dp_result.json
                        -c well_constraint_config.yml
                        -rc rate_input.json
                        -pc phase_input.json
                        -dc duration_input.json
                        -o wells_wc_result.json
  - fm_add_templates -c template_config.yml
                     -i wells_wc_result.json
                     -o wells_tmpl_result.json
  - fm_schmerge  -s raw_schedule.sch
                 -i wells_tmpl_result.json
                 -o result_schedule.sch

Drill date planner¶

Calculate and write drill times from scaled controls.

usage: fm_drill_date_planner [-h] -i INPUT -o OUTPUT -opt OPTIMIZER [--lint]
                             [--schema]

Named Arguments¶

--lint

Optional argument to activate verification of validity of all given input (file) arguments without actually executing the forward model (i.e., no data transformation, no output calculation).

Default: False

--schema

Optional argument to generate schemas of the configuration file with its expected structure to facilitate its setting up by the user.

required named arguments¶

-i, --input: Wells file generated by Everest (wells.json).
-o, --output: Output file: input for drill planner job.
-opt, --optimizer: File containing information related to wells. The format is consistent with the wells.json file when running everest and can be used directly.

Interpret well drill¶

This module transforms dakota well_drill output to a json object.This object contains a list of well names to keep.

usage: fm_interpret_well_drill [-h] -i INPUT [--lint] -o OUTPUT

Named Arguments¶

--lint

Optional argument to activate verification of validity of all given input (file) arguments without actually executing the forward model (i.e., no data transformation, no output calculation).

Default: False

required named arguments¶

-i, --input: Yaml file that contains optimizer output, this should consist of a list of well names, with their associated value between 0 and 1
-o, --output: File path to write the resulting json file to.

Drill planner¶

A module that given a well priority list and a set of constraints, creates a list of dates for each well to be completed. Any well may have multiple options as to where it can be drilled, both for different slots and rigs. The module will try to find the optimum event combinations that allows for the wells to be completed as quickly as possible, and at the same time make sure that the dates that are output will be a valid drill plan.

usage: fm_drill_planner [-h] -i INPUT -o OUTPUT -c CONFIG -opt OPTIMIZER
                        [-tl TIME_LIMIT] [--ignore-end-date] [--lint]
                        [--schema]

Named Arguments¶

-tl, --time-limit

Maximum time limit for the solver in seconds.If a solution has not been reached within this time, a greedyapproach will be used instead.

Default: 3600

--ignore-end-date

Ignore the end date in the config file.

Default: False

--lint

Optional argument to activate verification of validity of all given input (file) arguments without actually executing the forward model (i.e., no data transformation, no output calculation).

Default: False

--schema

Optional argument to generate schemas of the configuration file with its expected structure to facilitate its setting up by the user.

required named arguments¶

-i, --input: File containing information related to wells. The format is consistent with the wells.json file when running everest and can be used directly.
-o, --output: Name of the output-file. The output-file (json) will contain the same information as the input-file, including the results from the drill_planner. Please note that it is highly recommended to not use the same filename as the input-file. In cases where the same workflow is run twice, it is generally advised that the input-file for each job is consistent
-c, --config: Configuration file in yaml format describing the constraints of the field development. The file must contain information about rigs and slots that the wells can be drilled through. Additional information, such as when rigs and slots are available is also added here.
-opt, --optimizer: The optimizer file is generated from everest it contains the well priority values - a float for each well.

Argument examples¶

-input example

[
    {
        "name": "w1",
        "drill_time": 20
    },
    {
        "name": "w2",
        "drill_time": 25
    },
    {
        "name": "w3",
        "drill_time": 43
    },
    {
        "name": "w4",
        "drill_time": 23
    },
    {
        "name": "w5",
        "drill_time": 36
    }
]

-config example

start_date: 2000-01-01
end_date: 2001-01-01
rigs:
 -
    name: 'A'
    wells: ['w1', 'w2', 'w3']
    slots: ['S1', 'S2', 'S3']
    unavailability:
     -
        start: 2000-01-01
        stop: 2000-02-02
     -
        start: 2000-03-14
        stop: 2000-03-19
 -
    name: 'B'
    wells: ['w3', 'w4', 'w5']
    slots: ['S3', 'S4', 'S5']
    unavailability:
     -
        start: 2000-02-01
        stop: 2000-02-02
     -
        start: 2000-02-14
        stop: 2000-02-15
slots:
 -
    name: 'S1'
    wells: ['w1', 'w2', 'w3']
    unavailability:
     -
        start: 2000-02-01
        stop: 2000-02-03
 -
    name: 'S2'
    wells: ['w1', 'w2', 'w3']
 -
    name: 'S3'
    wells: ['w1', 'w2', 'w3']
 -
    name: 'S4'
    wells: ['w3', 'w4', 'w5']
 -
    name: 'S5'
    wells: ['w3', 'w4', 'w5']

-optimizer example

w1: 5
w2: 4
w3: 3
w4: 2
w5: 1

Well swapping¶

Swaps well operation state over multiple time intervals according to multiple sets of priority values, state quota constraints and allowed state changing actions.

usage: fm_well_swapping [-h] -c CONFIG [-cr CONSTRAINTS] [-p PRIORITIES]
                        [-il ITERATION_LIMIT] [-cs CASES] [-o OUTPUT] [--lint]
                        [--schema]

Named Arguments¶

-cr, --constraints

EVEREST-generated JSON file containing the values defining each swapping time interval to be optimized

-p, --priorities

EVEREST-generated JSON file containing the sets of priority values to be optimized

-il, --iteration-limit

Limit the number of iteration, this value is capped by available iterations.

Default: 0

-cs, --cases

EVEREST-generated wells.json file

-o, --output

Path to generated output JSON file

--lint

Optional argument to activate verification of validity of all given input (file) arguments without actually executing the forward model (i.e., no data transformation, no output calculation).

Default: False

--schema

Optional argument to generate schemas of the configuration file with its expected structure to facilitate its setting up by the user.

required named arguments¶

-c, --config: Configuration file containing additional information defining allowed swapping actions, quotas and starting time to determine the swapping schedule.

Argument examples¶

Example of a well swapping configuration file (-c, --config) for a case with 4 wells, 3 time intervals and 3 possible statuses:

start_date: 2025-01-01

state:
    hierarchy:
        - label: open
          quotas: 3
        - label: closed
          quotas: [1, 1, 0, _]
        - label: shut
    initial:
        WELL-1: open
        WELL-2: closed
        WELL-3: closed
        WELL-4: open
    targets: [open, open, open]
    actions:
        - [open, closed]
        - [closed, open]
        - [open, shut]
        - [closed, shut]
    allow_inactions: true
    forbiden_actions: false

case_file: ./wells.json

Example of swapping constraints controls for a case with 3 time intervals defined in controls section of EVEREST configuration file:

controls:
    -
        name: swapping_constraints
        type: generic_control
        min: 0.0
        max: 500.0
        perturbation_magnitude: 25.0
        variables:
            - { name: state_duration, initial_guess: [250, 250, 250] }

These controls result in an EVEREST-generated JSON file with the following content (-cr, --constraints):

{
    "state_duration": {
        "1": 250,
        "2": 250,
        "3": 250
    }
}

Example of priority controls for a case with 4 wells and 3 time intervals defined in controls section of EVEREST configuration file:

-
    name: well_order
    type: well_control
    min: 0.0
    max: 1.0
    perturbation_magnitude: 0.05
    variables:
        - { name: WELL-1, initial_guess: [0.55, 0.51, 0.53] }
        - { name: WELL-2, initial_guess: [0.53, 0.55, 0.51] }
        - { name: WELL-3, initial_guess: [0.51, 0.53, 0.55] }
        - { name: WELL-4, initial_guess: [0.50, 0.50, 0.50] }

These controls result in an EVEREST-generated JSON file with the following content (-p, --priorities):

{
    "WELL-1": {
        "1": 0.55,
        "2": 0.51,
        "3": 0.53
    },
    "WELL-2": {
        "1": 0.53,
        "2": 0.55,
        "3": 0.51
    },
    "WELL-3": {
        "1": 0.51,
        "2": 0.53,
        "3": 0.55
    },
    "WELL-4": {
        "1": 0.5,
        "2": 0.5,
        "3": 0.5
    }
}

-cs, --cases example for a case with 4 wells:

[
    {
        "name": "WELL-1"
    },
    {
        "name": "WELL-2"
    },
    {
        "name": "WELL-3"
    },
    {
        "name": "WELL-4"
    }
]

Net present value¶

Module to calculate the NPV based on an eclipse simulation. All optional args, except: lint, schemas, input and output, is also configurable through the config file.

usage: fm_npv [-h] -s SUMMARY [-i INPUT] [-o OUTPUT] -c CONFIG
              [-sd START_DATE] [-ed END_DATE] [-rd REF_DATE]
              [-ddr DEFAULT_DISCOUNT_RATE] [-der DEFAULT_EXCHANGE_RATE]
              [--multiplier MULTIPLIER] [--lint] [--schema]

Named Arguments¶

-i, --input

Path to input file containing information related to wells. The format is consistent with the wells.json file when running everest. It must contain a ‘readydate’ key for each well for when it is considered completed and ready for production.

-o, --output

Path to output-file where the NPV result is written to.

Default: npv

-sd, --start-date

Start point of NPV calculation as ISO8601 formatted date (YYYY-MM-DD).

-ed, --end-date

End point of NPV calculation as ISO8601 formatted date (YYYY-MM-DD).

-rd, --ref-date

Ref point of NPV calculation as ISO8601 formatted date (YYYY-MM-DD).

-ddr, --default-discount-rate

Default discount rate you want to use.

-der, --default-exchange-rate

Default exchange rate you want to use.

--multiplier

Multiplier you want to use.

--lint

Optional argument to activate verification of validity of all given input (file) arguments without actually executing the forward model (i.e., no data transformation, no output calculation).

Default: False

--schema

Optional argument to generate schemas of the configuration file with its expected structure to facilitate its setting up by the user.

required named arguments¶

-s, --summary: Eclipse summary file
-c, --config: Path to config file containing at least prices

Argument examples¶

-config example

prices:
    FOPT:
        - { date: 1999-01-01, value: 60, currency: USD }
    FWPT:
        - { date: 1999-01-01, value: -5, currency: USD }
        - { date: 2002-01-01, value: -2 }
    FGPT:
        - { date: 1999-01-01, value: 1, currency: USD }
        - { date: 2002-01-01, value: 0.1 }
    FWIT:
        - { date: 1999-01-01, value: -10, currency: USD }
        - { date: 2002-01-01, value: -20 }
    FGIT:
        - { date: 1999-01-01, value: -0.02, currency: USD }
        - { date: 2002-01-01, value: -0.1 }
    GOPT:OP:
        - { date: 1999-12-10, value: 555 }

dates:
    start_date: 2000-12-06
    end_date: 2002-12-23
    ref_date: 2000-12-06

summary_keys: ['FWIT', 'FOPT']

exchange_rates:
    USD:
        - { date: 1997-01-01, value: 5 }
        - { date: 2000-02-01, value: 7 }
        - { date: 2001-05-01, value: 6 }
        - { date: 2002-02-01, value: 9 }

discount_rates:
    - { date: 1999-01-01, value: 0.02 }
    - { date: 2002-01-01, value: 0.05 }

costs:
    - { date: 1999-01-01, value: 10000000, currency: USD }
    - { date: 1999-10-01, value: 20000000 }
    - { date: 1999-10-05, value: 5000000, currency: USD }
    - { date: 2000-01-07, value: 100000000, currency: GBP }
    - { date: 2000-07-25, value: 5000000, currency: NOK }

well_costs:
    - { well: OP_1, value: 10000000, currency: USD }
    - { well: OP_2, value: 20000000 }
    - { well: OP_3, value: 5000000, currency: USD }
    - { well: OP_4, value: 100000000, currency: GBP }
    - { well: OP_5, value: 1000000 }
    - { well: WI_1, value: 100000, currency: USD }
    - { well: WI_2, value: 20000000, currency: USD }
    - { well: WI_3, value: 5000000, currency: NOK }

-input example

This argument uses output of the drill_planner job, or a similar output.

[
    {
        "name": "OP_4",
        "readydate": "2000-02-23"
    },
    {
        "name": "OP_5",
        "readydate": "2000-06-14"
    },
    {
        "name": "OP_1",
        "readydate": "2000-07-19"
    }
]

Select wells¶

Select the first wells from a drill planner output file.

usage: fm_select_wells [-h] -i INPUT -o OUTPUT [-m MAX_DATE] [--lint]
                       [--schema]
                       {value,file} ...

Named Arguments¶

-m, --max-date

Maximum allowed date

--lint

Optional argument to activate verification of validity of all given input (file) arguments without actually executing the forward model (i.e., no data transformation, no output calculation).

Default: False

--schema

Optional argument to generate schemas of the configuration file with its expected structure to facilitate its setting up by the user.

required named arguments¶

-i, --input: Input file: a drill planner output file.
-o, --output: Output file: updated drill planner output file

Sub-commands¶

value¶

The number of wells as a value

fm_select_wells value [-h] well_number

Positional Arguments¶

well_number: A positive integer for the number of wells to be selected.

file¶

Everest control file containing the number of wells.

fm_select_wells file [-h] file_path

Positional Arguments¶

file_path

Add templates¶

Inserts template file paths for all well operations in the given input file where the config keys match the operation information. If key sets associated with multiple template files match a well operation the template with the most keys matching will be the one inserted

usage: fm_add_templates [-h] -i INPUT -o OUTPUT -c CONFIG [--lint] [--schema]

Named Arguments¶

--lint

Optional argument to activate verification of validity of all given input (file) arguments without actually executing the forward model (i.e., no data transformation, no output calculation).

Default: False

--schema

Optional argument to generate schemas of the configuration file with its expected structure to facilitate its setting up by the user.

required named arguments¶

-i, --input: Input file that requires template paths. Json file expected ex: wells.json
-o, --output: Output file
-c, --config: Config file containing list of template file paths to be injected.

STEA¶

STEA is a powerful economic analysis tool used for complex economic analysis and portfolio optimization. STEA helps you analyze single projects, large and small portfolios and complex decision trees. As output, for each of the entries in the result section of the yaml config file, STEA will create result files ex: Res1, Res2, .. Res#

usage: fm_stea [-h] [--lint] -c CONFIG

Named Arguments¶

--lint

Optional argument to activate verification of validity of all given input (file) arguments without actually executing the forward model (i.e., no data transformation, no output calculation).

Default: False

required named arguments¶

-c, --config: STEA (yaml) config file

Argument examples¶

-config example

# The id of the project, which must already exist and be available in
# the stea database. In the Stea documentation this is called "AlternativeId".
project-id: 4782
project-version: 1


# All information in stea is versioned with a timestamp. When we request a
# calculation we must specify wich date we wish to use to fetch configuration
# information for assumptions like e.g. the oil price.
config-date: 2018-07-01 12:00:00


# The stea web client works by *adjusting* the profiles in an existing
# stea project which has already been defined. That implies that all
# profiles added in this configuration file should already be part of
# the project. To match the profiles specified here with the profiles in
# the project we must give a id for the profiles.

# The profiles keyword is used to enter profile data explicitly in the
# configuration file. Each profile is identified with an id from the
# existing stea project, a start date and the actual data.

profiles:
    <ecl_profile_id>:
       start-year: 2018
       data: [100, 200, 300]

# Profiles which are calculated directly from an eclipse simulation are
# listed with the ecl-profiles key. Each profile is identified with an id
# from the stea project and an eclipe key like 'FOPT'. By default the stea
# client will calculate a profile from the full time range of the simulated
# data, but you can optionally use the keywords start-year and end-year to
# limit the time range.
ecl-profiles:
  <ecl_profile_id>:
     ecl-key: FOPT

  <ecl_profile_id>:
     ecl-key: FGPT
     start-year: 2020
     end-year: 2030

  profile_comment_in_stea:
     ecl-key: FWPT
     glob_mult: 1.1

  another_profile_comment_in_stea:
     ecl-key: FWPT
     mult: [ 1.1, 2, 0 ]

# What do you want stea to calculate
results:
   - NPV

Well filter¶

This module filters out wells using a json string.Either the –keep or the –remove flag needs to be set to a json file namecontaining a list of well names that are in the keep/remove file, but not in the input file will be ignored.If both or none of the flags are set, the job give an error.

usage: fm_well_filter [-h] -i INPUT -o OUTPUT (-k KEEP | -r REMOVE) [--lint]
                      [--schema]

Named Arguments¶

--lint

Optional argument to activate verification of validity of all given input (file) arguments without actually executing the forward model (i.e., no data transformation, no output calculation).

Default: False

--schema

Optional argument to generate schemas of the configuration file with its expected structure to facilitate its setting up by the user.

required named arguments¶

-i, --input: Json file that contains a list of dictionaries containing well information.
-o, --output: File path to write the resulting wells file to.
-k, --keep: JSON/Y(A)ML file that contains a list of well names to keep.
-r, --remove: JSON/Y(A)ML file that contains a list of well names to remove.

Argument examples¶

-input example

[
  {
    "name": "w1",
    "drill_time": 20
  },
  {
    "name": "w2",
    "drill_time": 25
  },
  {
    "name": "w3",
    "drill_time": 43
  },
  {
    "name": "w4",
    "drill_time": 23
  },
  {
    "name": "w5",
    "drill_time": 36
  }
 ]

-keep example

["w1", "w3", "w5"]

Well trajectory¶

Design a well trajectory based on provided parametrized guide points.The guide points are interpolated in order to obtain a smooth well trajectory.Then, inputs for the reservoir simulator are created in form of completion data consisting of grid cells that trajectory interjects, well-to-cell connection factors, well diameter, skin, etc. Optionally, only perforated intervals are created for which provided perforation criteria are satisfied based on information, such as geological formation or any static or dynamic property in the grid cell of a reservoir simulation model.

usage: fm_well_trajectory [-h] -c CONFIG [-E ECLIPSE_MODEL] [--lint]
                          [--schema]

Named Arguments¶

-E, --eclipse-model

Path to simulation model: ‘/path/to/model’; extension not required. GRID and INIT files always expected. If dynamic perforations defined in CONFIG file then UNRST file expected.

--lint

Optional argument to activate verification of validity of all given input (file) arguments without actually executing the forward model (i.e., no data transformation, no output calculation).

Default: False

--schema

Optional argument to generate schemas of the configuration file with its expected structure to facilitate its setting up by the user.

required named arguments¶

-c, --config: Forward model configuration file in YAML format.

Argument examples¶

-c, --config example

interpolation:
    type: resinsight
    measured_depth_step: 5.0

connections:
    type: resinsight
    formations_file: ./formations.lyr
    perforations:
        - well: INJ
          formations: [3, 4]
        - well: PROD
          formations: [1, 2, 3, 4]
          static:
            - key: PORO
              min: 0
              max: 1
          dynamic:
            - key: SWAT
              min: 0
              max: 0.5
              date: 2015-01-02

wells:
    - name: INJ
      group: G1
      phase: GAS
      platform: PLATFORM1
      dogleg: 4
      skin: 0
      radius: 0.15
    - name: PROD
      group: G1
      phase: OIL
      platform: PLATFORM2
      dogleg: 4
      skin: 0
      radius: 0.15

platforms:
    - name: PLATFORM1
      x: 6000
      y: 4000
      k: 50
    - name: PLATFORM2
      x: 5000
      y: 5000
      k: 50

Formation layer file example

'formation1' 1-1
'formation2' 2-2
'formation3' 3-4
'formation4' 5-5

Output file examples¶

PROD.dev Part of well trajectory deviation file (interpolated well trajectory)

WELLNAME: 'PROD'
#       X           Y      TVDMSL       MDMSL
  5000.00     5000.00        0.00        0.00
  5000.00     5000.00        4.98        5.00
  5000.00     5000.00        9.96       10.00
...
  5920.02     6079.98     8516.36     8640.00
  5920.03     6079.99     8521.36     8645.00
  5920.04     6080.00     8525.00     8648.64
-999

PROD.SCH Well completion information

-- WELL  GROUP        BHP    PHASE  DRAIN  INFLOW  OPEN  CROSS  PVT    HYDS  FIP
-- NAME  NAME   I  J  DEPTH  FLUID  AREA   EQUANS  SHUT  FLOW   TABLE  DENS  REGN
WELSPECS
   PROD  G1     6  7  1*     OIL    0.0    STD     STOP  YES    0      SEG   0    /
/
-- WELL                     OPEN   SAT   CONN           WELL      KH             SKIN      D      DIR
-- NAME   I   J   K1   K2   SHUT   TAB   FACT           DIA       FACT           FACT      FACT   PEN
COMPDAT
   PROD   6   7   1    1    OPEN   1*    7.462625E+01   0.30000   1.000757E+04   0.00000   1*     'Z' /
   PROD   6   7   2    2    OPEN   1*    1.118596E+01   0.30000   1.500165E+03   0.00000   1*     'Z' /
   PROD   6   7   3    3    OPEN   1*    7.456390E+01   0.30000   9.999988E+03   0.00000   1*     'Z' /
/

Strip dates¶

Makes sure a given summary file contains only report steps at the list of dates given as an argument

usage: fm_strip_dates [-h] -s SUMMARY [--lint] [-d DATE1 [DATE2 ...]]
                      [--allow-missing-dates]

Named Arguments¶

--lint

Optional argument to activate verification of validity of all given input (file) arguments without actually executing the forward model (i.e., no data transformation, no output calculation).

Default: False

-d, --dates

List of date to remain in the summary file

Default: []

--allow-missing-dates

Do not fail if any requested dates are missing in the file

Default: False

required named arguments¶

-s, --summary: Eclipse summary file

Well constraints¶

A module that given a list of boundaries and well constraints creates a list of well events. Varying phase, rate and time of each event is supported. Rate and duration can be provided as constant values if the optimizer does not provide them, and phase as a list of possibilities to choose from.

usage: fm_well_constraints [-h] -i INPUT [--schema] [--lint] -o OUTPUT -c
                           CONFIG [-rc RATE_CONSTRAINTS]
                           [-pc PHASE_CONSTRAINTS] [-dc DURATION_CONSTRAINTS]

Named Arguments¶

--schema

Optional argument to generate schemas of the configuration file with its expected structure to facilitate its setting up by the user.

--lint

Optional argument to activate verification of validity of all given input (file) arguments without actually executing the forward model (i.e., no data transformation, no output calculation).

Default: False

-rc, --rate-constraints

Rate constraints file in json format, from controls section of Everest config, must be indexed format.

-pc, --phase-constraints

Phase constraints file in json format, from controls section of Everest config, must be indexed format. Values must be in the interval [0,1], i.e in a two phase case [“water”, “gas”], any control value in the interval [0, 0.5] will be attributed to “water” and any control value in the interval (0.5, 1] will be attributed to “gas”.

-dc, --duration-constraints

Duration constraints file in json format, from controls section of Everest config, must be indexed format.

required named arguments¶

-i, --input: File in json format containing well names and well opening times, should be specified in Everest config (wells.json).
-o, --output: Name of the output file. The format will be yaml.
-c, --config: Configuration file in yaml format with names, events and values

Argument examples¶

If there is an entry in e.g. the rate-constraint file for INJECT1, 1, then no rate value needs to be provided in the configuration file under index 1 for INJECT1. The optimizer values from the rate-constraint and duration-constraint files will overwrite any value provided in the configuration file for the same well and index. If the optimizer provides no rate or duration input files then any values in the configuration files will be considered as constants.

-phase-constraint example

{
"INJECT1" : {
  "1": 0.49,
  "2": 0.51,
  "3": 0.8
},
"INJECT2" : {
  "1": 0.3,
  "2": 0.1
}}

-config example

INJECT1:
    1:
      phase:
        options: [water, gas]
    2:
      phase:
        options: [water, gas]
    3:
      phase:
        options: [water, gas]

INJECT2:
    1:
      phase:
        options: [water, gas]
    2:
      phase:
        options: [water, gas]

-rate-constraint example

{
"INJECT1" : {
  "1": 600,
  "2": 400,
  "3": 200
},
"INJECT2" : {
  "1": 650,
  "2": 525
}}

-config example

INJECT1:
    1:
      phase:
        value: WATER
      duration:
        value 30
    2:
      phase:
        value: WATER
      duration:
        value 40
    3:
      phase:
        value: GAS
      duration:
        value: 70
    4:
      phase:
        value: GAS
      rate:
        value: 333 # Will be considered a constat rate
      duration:
        value: 100

INJECT2:
    1:
      phase:
        value: WATER
      duration:
        value: 50
    2:
      phase:
        value: GAS
      duration:
        value: 60

-duration-constraint example

{
"INJECT1" : {
  "1": 60,
  "2": 40,
}}

-config example

INJECT1:
    1:
      phase:
        value: WATER
    2:
      phase:
        value: WATER
    3:
      phase:
        value: GAS
      duration:
        value: 70

-input example

[
  {
    "name": "INJECT1",
    "readydate": "2019-05-12",
    "ops": [
        {"opname": "open", "date": "2019-05-12"}
    ]
  },
  {
    "name": "INJECT2",
    "readydate": "2019-09-15",
    "ops": [
        {"opname": "open", "date": "2019-09-15"}
    ]
  }
]

Schedule merge¶

This module works on a schedule file intended for reservoir simulation(e.g. eclipse or flow), and injects templates at given dates. If the reportdate does not exist in advance it will be added as an independent step. The templates will further be filled in with the given parameter values.

usage: fm_schmerge [-h] -s SCHEDULE -i INPUT -o OUTPUT [--lint] [--schema]

Named Arguments¶

--lint

Optional argument to activate verification of validity of all given input (file) arguments without actually executing the forward model (i.e., no data transformation, no output calculation).

Default: False

--schema

Optional argument to generate schemas of the configuration file with its expected structure to facilitate its setting up by the user.

required named arguments¶

-s, --schedule: Schedule file to inject templates into. The only currently accepted date format is the following: one line consisting of the DATES keyword, followed by a date in the format of ‘1 JAN 2000’ terminated by a slash. The final line consists of a slash. An empty line should be in between the date format and anything below.
-i, --input: Json file that specifies which templates to inject where.The file is structured as a list of dictionaries, each containing information regarding one well. The name defines the name of the well, and the ops is a list of operations to be performed on the well. The operations are defined within a dict with the required keys template, date and any parameter values that are to be injected into the given template
-o, --output: File path to write the resulting schedule file to.

Compute economics¶

Module to calculate economical indicators based on an eclipse simulation. All optional args, except: lint, schemas, input and output, is also configurable through the config file.

usage: fm_compute_economics [-h] --calculation {npv,bep} -c CONFIG [-o OUTPUT]
                            [--output-currency OUTPUT_CURRENCY]
                            [-sd START_DATE] [-ed END_DATE] [-rd REF_DATE]
                            [-ddr DEFAULT_DISCOUNT_RATE]
                            [-der DEFAULT_EXCHANGE_RATE]
                            [--multiplier MULTIPLIER] [--lint] [--schema]

Named Arguments¶

--calculation

Possible choices: npv, bep

selected economic indicator

-o, --output

Path to output-file where the economical indicators result is written to.

--output-currency

Name of the output currency. Should be either default or defined in the exchange rate.

-sd, --start-date

Start point of economical indicators calculation as ISO8601 formatted date (YYYY-MM-DD).

-ed, --end-date

End point of economical indicators calculation as ISO8601 formatted date (YYYY-MM-DD).

-rd, --ref-date

Ref point of economical indicators calculation as ISO8601 formatted date (YYYY-MM-DD).

-ddr, --default-discount-rate

Default discount rate you want to use.

-der, --default-exchange-rate

Default exchange rate you want to use.

--multiplier

Multiplier you want to use.

--lint

Optional argument to activate verification of validity of all given input (file) arguments without actually executing the forward model (i.e., no data transformation, no output calculation).

Default: False

--schema

Optional argument to generate schemas of the configuration file with its expected structure to facilitate its setting up by the user.

required named arguments¶

-c, --config: Path to config file containing at least prices

Extract summary data¶

Module to extract Eclipse Summary keyword data for single date or date interval

usage: fm_extract_summary_data [-h] -s SUMMARY -o OUTPUT [--lint]
                               [-sd START_DATE] -ed END_DATE -k KEY
                               [-t {max,diff}] [-m MULTIPLIER]

Named Arguments¶

--lint

Optional argument to activate verification of validity of all given input (file) arguments without actually executing the forward model (i.e., no data transformation, no output calculation).

Default: False

-sd, --start-date

Start date, if not specified the module will write to the output file a single summary key value for the specified end date

-t, --type

Possible choices: max, diff

Range calculation type to use

Default: diff

-m, --multiplier

Result multiplier

Default: 1

required named arguments¶

-s, --summary: Eclipse summary file
-o, --output: Output file
-ed, --end-date, --date: End date for the summary key interval or date for which to extract a summary key value
-k, --key: Eclipse summary key

Recovery factor¶

Calculates the recovery factor given summary keys and dates. Requires a Summary instance to retrieve the volumes from. The summary keys requested must be in the Summary instance. If the dates are outside the simulation range, they will be clamped to nearest. Will throw an error if the entire date range is outside the simulation range.

usage: fm_rf [-h] -s SUMMARY [--lint] [-o OUTPUT] [-pk PRODUCTION_KEY]
             [-tvk TOTAL_VOLUME_KEY] [-sd START_DATE] [-ed END_DATE]

Named Arguments¶

--lint

Optional argument to activate verification of validity of all given input (file) arguments without actually executing the forward model (i.e., no data transformation, no output calculation).

Default: False

-o, --output

Filename of the output file.

-pk, --production_key

Production key - a valid summary key

Default: 'FOPT'

-tvk, --total_volume_key

Total volume key - a valid summary key

Default: 'FOIP'

-sd, --start_date

Start date - As ISO8601 formatted date (YYYY-MM-DD)

-ed, --end_date

Start date - As ISO8601 formatted date (YYYY-MM-DD)

required named arguments¶

-s, --summary: Eclipse summary file

Template rendering¶

This forward model loads the data from each input file and exposes it as the variable filename. It then loads the given Jinja2 template and dumps the rendered result to the output file.

usage: template_render [-h] --output_file OUTPUT_FILE --template_file
                       TEMPLATE_FILE
                       [--input_files INPUT_FILES [INPUT_FILES ...]]

Named Arguments¶

--output_file, -o: The output file
--template_file, -t: The jinja2 template file
--input_files, -i: One or more json and yaml input files

Example¶

Given an input file my_input.json:

{
    "my_variable": "my_value"
}

And a template file tmpl.jinja:

This is written in my file together with {{my_input.my_variable}}

Run the script with:

template_render -i my_input.json -t tmpl.jinja -o my_output.txt

This will produce an output file with the content:

This is written in my file together with my_value

Eclipse simulator¶

eclipse100 <eclbase> --version <version_number>

Running eclipse with parallel option¶

It is possible to run eclipse with multiple CPUs on clusters. This requires the eclipse data file to have the parallel option and the everest config needs to specify the number of CPUs per node:

simulator:
  cores_per_realization: x

where x is an int giving the number of cores. The eclipse100 forward model also needs to be given the argument to use multiple cores:

eclipse100 <eclbase> --version <version_number> --num-cpu x

where x is the number of cores.

Everest usage example¶

The following illustrates an example of a forward model section of an Everest config file:

forward_model:
  - well_constraints  -i files/well_readydate.json -c files/wc_config.yml -rc well_rate.json -o wc_wells.json
  - add_templates     -i wc_wells.json -c files/at_config.yml -o at_wells.json
  - schmerge          -s eclipse/include/schedule/schedule.tmpl -i at_wells.json -o eclipse/include/schedule/schedule.sch
  - job: eclipse100   r{{ eclbase }} --version 2020.2
    results:
      file_name: r{{eclbase}}
      type: summary
      keys: ['FOPR', 'WOPR']
  - rf                -s r{{ eclbase }} -o rf

The add_templates job does NOT need to be installed it is already part of the default everest jobs. In the example above all files present in the files folder need to be provided by the user. The files folder should have the following structure:

files/
   |- well_readydate.json
   |- wc_config.yml
   |- at_config.yml
   |- templates/
       |- wconinje.j2.html
       |- wconprod.j2.html

and should be installed in the everest config file:

install_data:
  -
    source: r{{ configpath }}/../input/files
    target: files
    link: true

well_readydate.json

[
   {
     "name": "PROD1",
     "readydate": "2000-01-01",
   },
   {
     "name": "PROD2",
     "readydate": "2000-01-01",
   },
   {
     "name": "INJECT1",
     "readydate": "2000-01-01",
   },
   {
     "name": "INJECT2",
     "readydate": "2000-01-01",
   }
]

wc_config.yml

PROD1:
  1:
    phase:
      value: OIL
    duration:
      value: 50
PROD2:
  1:
    phase:
      value: OIL
    duration:
      value: 50
INJECT1:
  1:
    phase:
      value: WATER
    duration:
      value: 50
INJECT2:
  1:
    phase:
      value: WATER
    duration:
      value: 50

at_config.yml

templates:
  -
    file: './files/templates/wconinje.j2.html'
    keys:
        opname: rate
        phase: WATER
  -
    file: './files/templates/wconprod.j2.html'
    keys:
        opname: rate
        phase: OIL

wconprod.j2.html

WCONPROD
  '{{ name }}'  'OPEN'  'ORAT' {{ rate }}   4* 100   /
/

wconinje.j2.html

WCONINJE
  '{{ name }}'  '{{ phase }}'  'OPEN'  'RATE' {{ rate }}   1* 320  1*  1*    1*   /
/

In the above example of the forward model section of the config file:

The file wc_wells.json is a direct output of the well_constraint job.
The add_templates job uses the same file wc_wells.json as an input for the job.
The wc_wells.json file is not modified by the user. Any modification to this file should be done using a custom job (see the section Custom forward model jobs for more information on how to do that).

If the file is to be modified by a custom job, the everest config should contain:

install_jobs:
  -
    name: custom_job
    executable: jobs/custom_job.exe

forward_model:
  - well_constraints  -i files/well_readydate.json -c files/wc_config.yml -rc well_rate.json -o wc_wells.json
  - custom_job        -i wc_wells.json -o wc_wells_custom.json
  - add_templates     -i wc_wells_custom.json -c files/at_config.yml -o at_wells.json
  - schmerge          -s eclipse/include/schedule/schedule.tmpl -i at_wells.json -o eclipse/include/schedule/schedule.sch
  - job: eclipse100   r{{ eclbase }} --version 2020.2
    results:
      file_name: r{{eclbase}}
      type: summary
      keys: ['FOPR', 'WOPR']
  - rf                -s r{{ eclbase }} -o rf

wc_wells.json

[
  {
    "name": "PROD1",
    "readydate": "2000-01-01",
    "ops": [
      {
        "phase": "OIL",
        "rate": 550.0015,
        "date": "2000-01-01",
        "opname": "rate"
      }
    ]
  },
  {
    "name": "PROD2",
    "readydate": "2000-01-01",
    "ops": [
      {
        "phase": "OIL",
        "rate": 860.0048,
        "date": "2000-01-01",
        "opname": "rate"
      }
    ]
  },
  {
    "name": "INJECT1",
    "readydate": "2000-01-01",
    "ops": [
      {
        "phase": "WATER",
        "rate": 5499.93,
        "date": "2000-01-01",
        "opname": "rate"
      }
    ]
  },
  {
    "name": "INJECT2",
    "readydate": "2000-01-01",
    "ops": [
      {
        "phase": "WATER",
        "rate": 5500.075,
        "date": "2000-01-01",
        "opname": "rate"
      }
    ]
  }
]

The add_templates job will search in the file wc_wells.json for the keys defined by the user in the config file at_config.yml and where the keys are present the job will add the corresponding template file. The resulting output at_wells.json has the following form:

at_wells.json

[
  {
    "name": "PROD1",
    "readydate": "2000-01-01",
    "ops": [
      {
        "phase": "OIL",
        "rate": 550.0015,
        "date": "2000-01-01",
        "opname": "rate",
        "template": "./files/templates/wconprod.j2.html"
      }
    ]
  },
  {
    "name": "PROD2",
    "readydate": "2000-01-01",
    "ops": [
      {
        "phase": "OIL",
        "rate": 860.0048,
        "date": "2000-01-01",
        "opname": "rate",
        "template": "./files/templates/wconprod.j2.html"
      }
    ]
  },
  {
    "name": "INJECT1",
    "readydate": "2000-01-01",
    "ops": [
      {
        "phase": "WATER",
        "rate": 5499.93,
        "date": "2000-01-01",
        "opname": "rate",
        "template": "./files/templates/wconinje.j2.html"
      }
    ]
  },
  {
    "name": "INJECT2",
    "readydate": "2000-01-01",
    "ops": [
      {
        "phase": "WATER",
        "rate": 5500.075,
        "date": "2000-01-01",
        "opname": "rate",
        "template": "./files/templates/wconinje.j2.html"
      }
    ]
  }
]

Next, the at_wells.json file is used as an input for the schedule merge job schmerge together with the initial schedule template schedule.tmpl file, which will result in the new schedule file schedule.sch used for the simulation.

For the following entry in the at_wells.json:

{
  "name": "PROD1",
  "readydate": "2000-01-01",
  "ops": [
    {
      "phase": "OIL",
      "rate": 550.0015,
      "date": "2000-01-01",
      "opname": "rate",
      "template": "./files/templates/wconprod.j2.html"
    }
  ]
}

and the template wconprod.j2.html:

WCONPROD
  '{{ name }}'  'OPEN'  'ORAT' {{ rate }}   4* 100   /
/

the resulting entry in schedule.sch is as follows:

DATES
 01 JAN 2000 / --ADDED
/

--start ./files/templates/wconprod.j2.html
WCONPROD
  'PROD1'  'OPEN'  'ORAT' 550.0015   4* 100   /
/

--end ./files/templates/wconprod.j2.html

where "--" marks the beginning of a comment line and will be ignored by the simulator.

Other template examples¶

The jinja2 templating language is supported by the schedule merge job, and can be used to write the templates. Below a few default examples can be found:

Water injection template

WCONINJE
  '{{ name }}' '{{ phase }}' 'OPEN' 'RATE' {{ rate }} 5*   /
/

Gas production template

WCONPROD
  '{{ name }}' 'OPEN' 'GRAT' {{ rate }}  5*   /
/

Oil production template

WCONPROD
  '{{ name }}' 'OPEN' 'ORAT' {{ rate }}  5*  /
/

Well open template

WELOPEN
  '{{ name }}' 'OPEN' /
/

More information regarding template design and usage can be found here.