Everest models

The everest-models plugin for Everest adds a number of forward model jobs for devising optimal field development and reservoir management strategies. It can be found here: https://github.com/equinor/everest-models.

Reference

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
    date: 2015-01-02
    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

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