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¶
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
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
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
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
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"}
]
}
]
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 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.
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.
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' /
/
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"]
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
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"
}
]
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¶
- -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.
- -tl, --time-limit
Maximum time limit for the solver in seconds. If a solution has not been reached within this time, a greedy approach 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¶
- -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
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.
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
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"
}
]