mirror of
https://github.com/OPM/ResInsight.git
synced 2025-02-25 18:55:39 -06:00
Updated ERT to 315ceeee250808ea6a6530233dd5125f9f76f06c
Support of reading LGR dimensions Close file handles between access to files, keep ERT file-related cache to speed up reading of many files multiple times p4#: 21477
This commit is contained in:
Magne Sjaastad
@@ -1,70 +0,0 @@
|
||||
ERTGUI core documentation
|
||||
|
||||
Codebase in C Codebase in Python
|
||||
|
||||
+--------------------+ +-------------------------+
|
||||
| ERT |/------------\| ErtWrapper |
|
||||
| shared C library |\------------/| ctypes wrapper |
|
||||
+--------------------+ | (C <-> Python comm.) |
|
||||
+-------------------------+
|
||||
/\
|
||||
||
|
||||
||
|
||||
\/
|
||||
+-------------------------+
|
||||
| ContentModel |
|
||||
| Class for fetching and |
|
||||
| updating data in ERT |
|
||||
+-------------------------+
|
||||
/\
|
||||
||
|
||||
||
|
||||
\/
|
||||
+-------------------------+
|
||||
| Widgets |
|
||||
| GUI components that |
|
||||
| enables presentation |
|
||||
| and modification of |
|
||||
| data in ERT |
|
||||
+-------------------------+
|
||||
|
||||
|
||||
ERT:
|
||||
the base software which the GUI controls.
|
||||
|
||||
ErtWrapper:
|
||||
this class simplifies the link between Python code and the exposed
|
||||
functions of the shared library of ERT.
|
||||
All communication between ERT and the GUI is performed through this
|
||||
class and type safety of the functions in the shared library are
|
||||
provided through a prototyping functionality.
|
||||
|
||||
ContentModel:
|
||||
This class is a base class for all widgets and algorithms that need
|
||||
to communicate with ERT. Several abstract functions are defined that
|
||||
must/can be implemented:
|
||||
* initialize(model): typically used for prototyping of functions
|
||||
* getter(model): used to fetch data from ERT
|
||||
* setter(model, value): used for updating data values
|
||||
* insert(model, value): used for adding data values
|
||||
* remove(model, value): used for removing data values
|
||||
|
||||
The program should never call these functions directly but use:
|
||||
* getFromModel(): which will call the getter automatically
|
||||
* updateContent(value, operation = UPDATE|INSERT|REMOVE):
|
||||
which will call setter/insert/remove respectively automatically.
|
||||
|
||||
A final function that must be implemented is fetchContent(). This function
|
||||
will automatically be called when the model (ERT) is ready or has been
|
||||
changed. This is also safe to be called by the program. Typical use of this
|
||||
function is to call getFromModel() which returns the data generated by the
|
||||
implemented getter function and then populate the widgets with the data.
|
||||
|
||||
Whenever changes are made to the GUI ERT should be updated by calls
|
||||
to updateContent().
|
||||
|
||||
Widgets:
|
||||
Several widgets have been implemented. Most of these subclass HelpedWidget
|
||||
which subclass ContentModel and provide built-in help functionality.
|
||||
|
||||
|
||||
@@ -1,244 +0,0 @@
|
||||
forward_model:
|
||||
--------------
|
||||
|
||||
get:
|
||||
----
|
||||
model_config = enkf_main_get_model_config( enkf_main )
|
||||
forward_model = model_config_get_forward_model( model_config )
|
||||
names = forward_model_alloc_joblist( forward_model ) <- Allokerer en stringlist() med navnene p<> jobbene.
|
||||
|
||||
|
||||
|
||||
set
|
||||
---
|
||||
forward_model_clear( forward_model )
|
||||
|
||||
forward_model_add_job( forward_model , job_name );
|
||||
forward_model_iset_job_arg( forward_model , job_nr , key , value); <- Set argument - observe that the jobs are identified with the index in
|
||||
the forward model, and not by name.
|
||||
|
||||
more
|
||||
----
|
||||
s = enkf_main_get_site_config( enkf_main )
|
||||
joblist = site_config_get_installed_jobs( s );
|
||||
job_names = ext_joblist_alloc_list( joblist ); <- Stringlist
|
||||
|
||||
|
||||
|
||||
forward_model_get_job( forward_model , ?NAME?)
|
||||
ext_joblist_get_job( joblist , ?NAME?)
|
||||
|
||||
ext_job = forward_model_iget_job( forward_model , job_nr )
|
||||
arg_string = ext_job_get_private_args_as_string( ext_job );
|
||||
ext_job_set_private_args_from_string( ext_job , "KEY1=Value1 , Key2=value2" )
|
||||
|
||||
|
||||
ext_job_get_help_text( job );
|
||||
|
||||
|
||||
--------------------------------------
|
||||
|
||||
|
||||
LOG:
|
||||
|
||||
Get
|
||||
---
|
||||
log_file = enkf_main_get_log_file( enkf_main )
|
||||
log_level = enkf_main_get_log_level( enkf_main )
|
||||
|
||||
|
||||
Set
|
||||
---
|
||||
enkf_main_set_log_file( enkf_main , "log_file" )
|
||||
enkf_main_set_log_level( enkf_main , log_level )
|
||||
|
||||
|
||||
analysis_config = enkf_main_get_analysis_config( enkf_main )
|
||||
log_path = analysis_config_get_log_path( analysis_config );
|
||||
analysis_config_set_log_path( analysis_config , log_path );
|
||||
|
||||
|
||||
|
||||
|
||||
INITIALIZED
|
||||
-----------
|
||||
|
||||
enkf_main_is_initialized(enkf_main , active_mask);
|
||||
|
||||
active_mask er n<> en vector av typen: bool_vector som er implementert i
|
||||
libutil. Dersom alle elemementene er aktive kan du sende inn None /
|
||||
NULL, ellers m<> allokere og initialisere en active_mask instans:
|
||||
|
||||
mask = bool_vector_alloc(0 , false)
|
||||
for index in selectedMembers:
|
||||
bool_vector_iset( mask , index , true )
|
||||
|
||||
enkf_main_is_initialized( enkf_main , mask )
|
||||
bool_vector_free( mask )
|
||||
|
||||
|
||||
|
||||
|
||||
TEMPLATES:
|
||||
----------
|
||||
Get:
|
||||
----
|
||||
templates = enkf_main_get_templates( enkf_main );
|
||||
s = ert_templates_alloc_list( templates ); <- Returnerer en stringlist med navn
|
||||
template = ert_templates_get_template( templates , "Navn")
|
||||
template_file = ert_template_get_template_file( template );
|
||||
target_file = ert_template_get_target_file( template );
|
||||
arg_string = ert_template_get_args_as_string( template )
|
||||
|
||||
|
||||
Set: (kan enten gj<67>res med manuelle add / del eller ved hjelp av clear og add).
|
||||
----
|
||||
templates = enkf_main_get_templates( enkf_main );
|
||||
ert_templates_clear( templates );
|
||||
ert_templates_del_template( templates , "Key");
|
||||
template = ert_templates_add_template( templates , "Key", "Template_file" , "target_file" , arg_string /* Can be None / NULL */);
|
||||
|
||||
template = ert_templates_get_template( templates , Key)
|
||||
ert_template_set_target_file(template , target_file );
|
||||
ert_template_set_template_file(template , template_file );
|
||||
ert_template_set_args_as_string(template , arg_string);
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
INITIALIZATION
|
||||
--------------
|
||||
|
||||
enkf_main_initialize_from_existing__( enkf_main , source_case , source_step , source_state ,
|
||||
iens_mask , ranking_key /* Will be NULL*/ ,
|
||||
node_list);
|
||||
|
||||
|
||||
|
||||
node_list ~ stringlist med de valgt nodene.
|
||||
|
||||
iens_mask = bool_vector_alloc(0 , false); <- Allokereres med false som default.
|
||||
iens_mask ~ bool_vector hvor alle de aktive indeksene er satt til true
|
||||
|
||||
|
||||
|
||||
SCHEDULE_PREDICTION_FILE
|
||||
------------------------
|
||||
Get: enkf_main_get_schedule_prediction_file( enkf_main )
|
||||
Set: enkf_main_set_schedule_prediction_file( enkf_main , filename )
|
||||
|
||||
|
||||
REFCASE
|
||||
-------
|
||||
Get:
|
||||
ecle_config = enkf_main_get_ecl_config( enkf_main );
|
||||
refacse = ecl_config_get_refcase_name( ecl_config )
|
||||
|
||||
Set:
|
||||
enkf_main_set_refcase( enkf_main , refcase ) ???????????????????? Ikkje load?
|
||||
|
||||
|
||||
|
||||
HISTORY_SOURCE
|
||||
--------------
|
||||
Get:
|
||||
m = enkf_main_get_model_config( enkf_main )
|
||||
history_source = model_config_get_history_source( m ) <- History_source ~ enum history_source_type fra libsched/src/history.y
|
||||
|
||||
|
||||
Set:
|
||||
m = enkf_main_get_model_config( enkf_main )
|
||||
model_config_get_history_source( m , source) <- NB Hvis source har en av verdiene REFCASE_HISTORY / REFCASE_SMULATED du maa satt ett REFACSE forst.
|
||||
|
||||
|
||||
|
||||
PRE_CLEAR_RUNPATH:
|
||||
-----------------
|
||||
Get: enkf_main_get_pre_clear_runpath( enkf_main ) <- Return value: true | false
|
||||
Set: enkf_main_set_pre_clear_runpath( enkf_main , true | false )
|
||||
|
||||
|
||||
|
||||
|
||||
CASE_TABLE
|
||||
----------
|
||||
model_config = enkf_main_get_model_config( enkf_main );
|
||||
|
||||
get: model_config_get_case_table_file( model_config )
|
||||
set: enkf_main_set_case_table( model_config , filename ); <- File must exist
|
||||
|
||||
|
||||
|
||||
REFCASE - Plotting:
|
||||
------------------
|
||||
Get:
|
||||
|
||||
ecl_config = enkf_main_get_ecl_config( enkf_main )
|
||||
ecl_sum = ecl_config_get_refcase( ecl_config )
|
||||
|
||||
Plotting:
|
||||
|
||||
1. Sjekk om refcase har variabel:
|
||||
|
||||
ecl_sum_has_general_var( ecl_sum , key)
|
||||
|
||||
hvor 'key' er en summary key, som for eksempel "WWCT:OP_1". Dersom denne funksjonen returnerer true, maa du
|
||||
sporre ecl_sum som en "oversettelse" fra key til en integer index, og siden bruke den indeksen:
|
||||
|
||||
key_index = ecl_sum_get_general_var_index( ecl_sum , key );
|
||||
|
||||
|
||||
2. Alloker en tidsakse:
|
||||
|
||||
time_vector = ecl_sum_alloc_time_vector( ecl_sum , true /* Report_only kan vre true */);
|
||||
|
||||
Denne kan selvflgelig gjenbrukes mellom flere summary plott.
|
||||
|
||||
3. Alloker datavektor
|
||||
|
||||
data_vektor1 = ecl_sum_alloc_data_vector( ecl_sum , key_index1 , true );
|
||||
|
||||
|
||||
Da har du x og y i en hhv time_t_vector og double_vector - en av joakims hjemmelade datastrukturer:
|
||||
|
||||
size: xxx_vector_get_size( )
|
||||
get1: xxx_vector_iget( )
|
||||
get2: xxx_vector_get_ptr() <- Returnerer en peker til underliggende data.
|
||||
|
||||
|
||||
4. xxx_vector_free () naar du er ferdi.
|
||||
|
||||
|
||||
5. (Ekstraoppgave:) en ecl_sum instans kan ogs<67> loades fra filsystemet (helt utenfor ERT sin database) med
|
||||
|
||||
ecl_sum = ecl_sum_fread_alloc_case( "Navn p<> en ECLIPSE.DATA fil" )
|
||||
|
||||
---------------------
|
||||
|
||||
Gen_data:
|
||||
size:
|
||||
-----
|
||||
ensemble_config = enkf_main_get_ensemble_config( enkf_main )
|
||||
config_node = ensemble_config_get_node( ensemble_config , "KEY")
|
||||
gen_data_config = enkf_config_node_get_ref( config_node )
|
||||
|
||||
size = gen_date_config_get_initial_size( gen_data_config )
|
||||
|
||||
Value:
|
||||
-----
|
||||
value = enkf_node_user_get( enkf_node , "KEY:tall" , &valid) <----- NB Det er helt avgj<67>rende <20> sjekke at valid returnerer true,
|
||||
gen_data typen er (altfor) fleksibel, og kan endre st<73>rrelse runtime.
|
||||
At du har sjekket initiell st<73>rrelse er derfor desverre ikke tilstrekkelig
|
||||
til <20> validere input.
|
||||
|
||||
|
||||
----------------
|
||||
Saving:
|
||||
|
||||
1. Sette config file: enkf_main_set_user_config_file( enkf_main , "config_file" ) [Denne trengs for "Save AS"]
|
||||
2. enkf_main_fprintf_config( enkf_main );
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,201 +0,0 @@
|
||||
|
||||
mask = util.bool_vector_alloc(ens_size , false)
|
||||
# F<>rste arg: st<73>rrelse
|
||||
# Andre arg: init verdi.
|
||||
|
||||
util.bool_vector_iset( mask , 67 , true )
|
||||
# bool_ptr = util.bool_vector_get_ptr( mask )
|
||||
# Send inn int_ptr
|
||||
....
|
||||
#util.bool_vector_free( mask )
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#Missing initializer: job_script
|
||||
# s = enkf_main_get_site_config( enkf_main )
|
||||
# site_config_get_job_script( s );
|
||||
# site_config_set_job_script( s , EXECUTABLE_FILE );
|
||||
|
||||
|
||||
|
||||
|
||||
Missing initializer: install_job
|
||||
s = enkf_main_get_site_config( enkf_main );
|
||||
site_config_install_job( s , JOB_KEY , EXISTING_FILE ); <- Should have a GUI option for creating the
|
||||
config file EXISTING_FILE
|
||||
|
||||
INSTALL_JOB:
|
||||
-----------
|
||||
1. Denne b<>r endre navn til "Private jobs"
|
||||
|
||||
2. Her blir get/set ganske komplisert - det er to grunner til det:
|
||||
|
||||
a) Listen over installerte jobber inneholder b<>de globale jobber,
|
||||
som brukeren ikke har anledning til <20> manipulere, og "Private"
|
||||
jobber som brukeren har installert og s<>ledes m<> f<> lov til <20>
|
||||
manipulere.
|
||||
|
||||
b) Forel<65>pig er det bare basert en config_file, men n<>r vi f<>rst
|
||||
lager GUI ville det v<>re veldig naturlig <20> lage mulighet for <20>
|
||||
konfigurere en jobb via GUI.
|
||||
|
||||
3. Det opprinnelige GUI panelet best<73>r av to felt. Kutt ut det ene
|
||||
feltet, men la det sprette opp ett vindu n<>r man legger til en
|
||||
jobb.
|
||||
|
||||
|
||||
Get:
|
||||
s = enkf_main_get_site_config( enkf_main )
|
||||
jl = site_config_get_installed_jobs( s )
|
||||
h = ext_joblist_get_jobs( jl ) <- N<> er h en hash tabell.
|
||||
|
||||
#Itererer over hash_tabellen:
|
||||
python_joblist = []
|
||||
job = hash_get( h , job_name );
|
||||
if ext_job_is_private( job ): <- Denne funksjonen er i libjob_queue
|
||||
python_joblist.append( job_name )
|
||||
|
||||
OK : python_joblist skal inneholde de job_navnene som skal
|
||||
vises i GUI.
|
||||
|
||||
|
||||
|
||||
Set: Her tror jeg det er enklest <20> respondere eksplisitt p<> add_job og
|
||||
del_job events, istedet for <20> ta en batch prosess til slutt
|
||||
|
||||
add_job:
|
||||
--------
|
||||
job = ext_job_fscanf_alloc( job_name , site_config_get_license_root_path__( s ) , job_config_file ) # job_name and job_config_file from GUI.
|
||||
ext_joblist_add_job( jl , job )
|
||||
|
||||
|
||||
del_job
|
||||
-------
|
||||
ext_joblist_del_job( jl , job_name )
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#Missing initializer: num_realizations
|
||||
# enkf_main_get_ensemble_size( enkf_main );
|
||||
# enkf_main_resize_ensemble( enkf_main ); <- Denne kan potensielt ta en del tid, og
|
||||
b<>r v<>re beskyttet av en APPLY knapp.
|
||||
|
||||
|
||||
Missing initializer: parameters
|
||||
Missing initializer: param_type
|
||||
Missing initializer: param_min
|
||||
Missing initializer: param_max
|
||||
Missing initializer: param_init
|
||||
Missing initializer: param_output
|
||||
Missing initializer: param_init_files
|
||||
Missing initializer: param_file_generated_by_enkf
|
||||
Missing initializer: param_file_loaded_by_enkf
|
||||
Missing initializer: history_source
|
||||
Missing initializer: obs_config
|
||||
|
||||
|
||||
|
||||
#Missing initializer: max_submit
|
||||
# s = enkf_main_get_site_config( enkf_main );
|
||||
# site_config_get_max_submit( s );
|
||||
# site_config_set_max_submit( s , max_submit );
|
||||
|
||||
|
||||
|
||||
|
||||
#Missing initializer: max_resample
|
||||
# m = enkf_main_get_model_config( enkf_main );
|
||||
# model_config_get_max_resample( m );
|
||||
# model_config_set_max_resample( m , max_resample );
|
||||
|
||||
|
||||
|
||||
Missing initializer: forward_model
|
||||
Missing initializer: case_table
|
||||
Missing initializer: license_path
|
||||
|
||||
Missing initializer: runpath
|
||||
# m = enkf_main_get_model_config( enkf_main )
|
||||
# model_config_get_runpath_fmt( m )
|
||||
# model_config_set_runpath_fmt( m , "/path/to/run%d" )
|
||||
|
||||
|
||||
|
||||
Missing initializer: pre_clear_runpath
|
||||
Missing initializer: delete_runpath
|
||||
Missing initializer: keep_runpath
|
||||
Missing initializer: run_template
|
||||
Missing initializer: dbase_type
|
||||
Missing initializer: enspath
|
||||
Missing initializer: select_case
|
||||
|
||||
|
||||
#Missing initializer: log_file
|
||||
#Missing initializer: log_level
|
||||
# lg = enkf_main_get_logh( enkf_main );
|
||||
# log_reset_filename( lg , "/some/path/to/FILENAME" );
|
||||
# log_get_filename( lg );
|
||||
#
|
||||
# log_get_level( lg );
|
||||
# log_set_level( lg , LOG_LEVEL)
|
||||
|
||||
|
||||
|
||||
Missing initializer: update_log_path
|
||||
|
||||
|
||||
|
||||
|
||||
#Get: s = enkf_main_get_data_kw( enkf_main )
|
||||
# subst_list_get_size( s )
|
||||
# subst_list_iget_key( s )
|
||||
# subst_list_iget_value( s )
|
||||
#Set: enkf_main_clear_data_kw( enkf_main )
|
||||
# enkf_main_add_data_kw( enkf_main , key , value )
|
||||
|
||||
#Get: m = enkf_main_get_model_config( enkf_main )
|
||||
# model_config_get_enkf_sched_file( m )
|
||||
#Set: model_config_set_enkf_sched_file( m , "FILENAME" )
|
||||
|
||||
#Get l = enkf_main_get_local_config( enkf_main );
|
||||
# s = local_config_get_config_files( l ) # Stringlist
|
||||
#Set local_config_clear_config_files( l )
|
||||
# local_config_add_config_file(l , "FILENAME")
|
||||
|
||||
#Get s = enkf_main_get_site_config( enkf_main )
|
||||
# site_config_get_max_running_(lsf|rsh|local)( s )
|
||||
#Set site_config_get_max_running_(lsf|rsh|local)( s , value )
|
||||
|
||||
#Get s = enkf_main_get_site_config( enkf_main )
|
||||
# h = site_config_get_rsh_host_list( s )
|
||||
# Iterer over hash - men bruk hash_get_int() for aa faa antall jobber en host kan ta.
|
||||
#Set site_config_clear_rsh_host_list( s )
|
||||
# site_config_add_rsh_host( s , host_name , max_running )
|
||||
|
||||
#Get s = enkf_main_get_site_config( enkf_main )
|
||||
# queue_name = site_config_get_lsf_queue( s )
|
||||
#Set site_config_set_lsf_queue( s , "NORMAL" )
|
||||
|
||||
# site_config_set_job_queue( s , "LOCAL|LSF|RSH" );
|
||||
# site_config_get_job_queue_name( s );
|
||||
|
||||
#self.job_script = "..."
|
||||
#self.setenv = [["LSF_BINDIR", "/prog/LSF/7.0/linux2.6-glibc2.3-x86_64/bin"], ["LSF_LIBDIR", "/prog/LSF/7.0/linux2.6-glibc2.3-x86_64/lib"]]
|
||||
#Get: s = enkf_main_get_site_config( enkf_main )
|
||||
# h = site_config_get_env_hash( s )
|
||||
#Set site_config_clear_env( s )
|
||||
# site_config_setenv( s , var , value )
|
||||
|
||||
#self.update_path = [["PATH", "/prog/LSF/7.0/linux2.6-glibc2.3-x86_64/bin"], ["LD_LIBRARY_PATH", "/prog/LSF/7.0/linux2.6-glibc2.3-x86_64/lib"]]
|
||||
#Get: s = enkf_main_get_site_config( enkf_main )
|
||||
# pathlist = site_config_get_path_variables( s )
|
||||
# valuelist = site_config_get_path_values( s )
|
||||
#Set: site_config_clear_pathvar( s )
|
||||
# site_config_update_pathvar( s , path , value );
|
||||
@@ -1,36 +0,0 @@
|
||||
state = enkf_main_iget_state( enkf_main , iens );
|
||||
status = enkf_state_get_run_status( state );
|
||||
sim_start = enkf_state_get_start_time( state );
|
||||
submit_time = enkf_state_get_submit_time( state );
|
||||
|
||||
|
||||
Queue running:
|
||||
-------------
|
||||
s = enkf_main_get_site_config( enkf_main )
|
||||
site_config_queue_is_running( s )
|
||||
|
||||
|
||||
Kill simulation
|
||||
---------------
|
||||
enkf_state_kill_simulation( state )
|
||||
|
||||
|
||||
Restart simulation
|
||||
------------------
|
||||
enkf_state_restart_simulation( state , resample ) /* Resample er en bool - True: Kj<4B>r ny initialisering */
|
||||
|
||||
|
||||
|
||||
|
||||
Main queue pausing:
|
||||
-------------------
|
||||
job_queue_get_pause( jq )
|
||||
|
||||
job_queue_set_pause_on( jq )
|
||||
|
||||
job_queue_set_pause_off( jp )
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,69 +0,0 @@
|
||||
GEN_DATA (Det er ikke skille p GEN_DATA og GEN_PARAM - alt er GEN_DATA)
|
||||
--------
|
||||
|
||||
1. Opprette en ny: ensemble_config_add_gen_data( ensemble_config , new_key );
|
||||
|
||||
|
||||
2 Get:
|
||||
|
||||
gen_data_config = enkf_config_node_get_ref( config_node );
|
||||
|
||||
output_format = gen_data_config_get_output_format( gen_data_config ); <- Returverdien her er en enum: gen_data_file_format_type,
|
||||
input_format = gen_data_config_get_input_format( gen_data_config ); definert i gen_data_config.h
|
||||
template_file = gen_data_config_get_template_file( gen_data_config );
|
||||
template_key = gen_data_config_get_template_key( gen_data_config );
|
||||
init_file_fmt = gen_data_config_get_init_file_fmt( gen_data_config );
|
||||
.....
|
||||
enkf_config_node_get_enkf_outfile( config_node ) -> Include file (parameter/general)
|
||||
enkf_config_node_get_min_std_file( config_node ) -> Min. std. (parameter/general)
|
||||
enkf_config_node_get_enkf_infile( config_node ) -> File loaded by EnKF (general)
|
||||
|
||||
|
||||
|
||||
3. Update:
|
||||
|
||||
enkf_config_node_update_gen_data( config_node , input_format , output_format , /* Enum: gen_data_file_format_type */
|
||||
init_file_format ,
|
||||
template_file ,
|
||||
template_key ,
|
||||
enkf_outfile_fmt ,
|
||||
enkf_infile_fmt ,
|
||||
min_std_file );
|
||||
|
||||
Legg merke til at det er ganske MAANGE innbyrdes krav mellom de
|
||||
forskjellige variablene som maa vaere tilfredsstilt; dette er
|
||||
"dokumentert" i funksjonene enkf_config_node_update_gen_data() og
|
||||
gen_data_config_update().
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
OBS_CONFIG:
|
||||
----------
|
||||
|
||||
Get:
|
||||
----
|
||||
obs = enkf_main_get_obs( enkf_main );
|
||||
enkf_obs_get_config_file( obs );
|
||||
|
||||
|
||||
Set:
|
||||
enkf_main_load_obs( enkf_main , obs_config_file );
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
KEEP_RUNPATH / DELETE_RUNPATH
|
||||
-----------------------------
|
||||
|
||||
Denne variabelen er definert som en streng i tui - jeg foreslaar at du
|
||||
heller bruker en tilsvarende tilnaerming som naar vi skal velge hvilke
|
||||
realisasjoner som skal simuleres paa, hver av de smaa boksene skal ha
|
||||
tre mulige verdier, tilsvarende enum keep_runpath_type i enkf_types.h.
|
||||
|
||||
Deretter:
|
||||
|
||||
enkf_main_iget_keep_runpath( enkf_main , index );
|
||||
enkf_main_iset_keep_runpath( enkf_main , index , enum_value );
|
||||
@@ -1 +0,0 @@
|
||||
A parameter controlling outlier behaviour in the EnKF algorithm. The default value is 1.50.
|
||||
@@ -1 +0,0 @@
|
||||
If you use the <b>ENKF schedule file</b> option to jump over several dates at a time you can choose whether you want to use all the observations in between, or just the final. Select <b>Perform merge</b> if you want all observations to be used, unselect to use only the final observation.
|
||||
@@ -1 +0,0 @@
|
||||
Here you select which EnKF algorithm to use. Use <b>ENKF_STANDARD</b> for the original EnKF algorithm, or <b>ENKF_SQRT</b> for the square root scheme.
|
||||
@@ -1 +0,0 @@
|
||||
Select if the simulation should be started from time zero after each update.
|
||||
@@ -1 +0,0 @@
|
||||
When the ERT application runs the EnKF algorithm, it will use ECLIPSE to simulate one report step at a time, and do an update after each step. However, in some cases it will be beneficial to turn off the EnKF update for some report steps or to skip some steps completely. <b>ENKF schedule file</b> can point to a file with a more advanced schedule for when to perform the updates. This is optional.
|
||||
@@ -1 +0,0 @@
|
||||
Cutoff used on singular value spectrum. Default value: 0.99.
|
||||
@@ -1 +0,0 @@
|
||||
This can point to a file with configuration information for local analysis.
|
||||
@@ -1 +0,0 @@
|
||||
If using EnKF rerun, select here which time step to start from after each update.
|
||||
@@ -1 +0,0 @@
|
||||
A summary of the data used for updates is stored in this directory.
|
||||
@@ -1,15 +0,0 @@
|
||||
The restart files from ECLIPSE are organized by <b>keywords</b>, which are of three different types:
|
||||
<ol>
|
||||
<li> Keywords containing the dynamic solution, e.g. pressure and saturations. </li>
|
||||
<li> Keywords containing various types of header information which is needed for a restart. </li>
|
||||
<li> Keywords containing various types of diagnostic information which is <i>not</i> needed for a restart.</li>
|
||||
</ol>
|
||||
|
||||
Keywords in category 2 and 3 are referred to as <b>static keywords</b>. To be able to restart ECLIPSE, the ERT application has to store the keywords in category 2, whereas keywords in category 3 can safely be dropped. To determine whether a particular keyword is in category 2 or 3 ERT considers an internal list of keywords. The current list contains the keywords:
|
||||
<code>
|
||||
<br/> INTEHEAD LOGIHEAD DOUBHEAD IGRP SGRP XGRP ZGRP IWEL SWEL XWEL ZWEL <br/>
|
||||
ICON SCON XCON HIDDEN STARTSOL PRESSURE SWAT SGAS RS RV ENDSOL ICAQNUM ICAQ IAAQ <br/>
|
||||
SCAQNUM SCAQ SAAQ ACAQNUM ACAQ XAAQ <br/>
|
||||
ISEG ILBS ILBR RSEG ISTHW ISTHG <br/>
|
||||
</code>
|
||||
Here you can dynamically add to this list. The magic string <code>__ALL__</code> will add all static keywords, but use of this option is <b>strongly</b> discouraged, as it wastes a lot of disk space.
|
||||
@@ -1 +0,0 @@
|
||||
The ECLIPSE data file used to control the simulations. The standard ECLIPSE data file needs to be modified in some ways in order to work with ERT.
|
||||
@@ -1 +0,0 @@
|
||||
Using <b>Data keywords</b> you can assign arbitrary (Keyword , Value) pairs where all occurences of <code><Keyword></code> in the ECLIPSE Data file will be replaced by <code>Value</code>.
|
||||
@@ -1,5 +0,0 @@
|
||||
The basename used for the ECLIPSE simulations. The name should contain a %d-specifier, which will be replazed by the realization number when running ECLIPSE. <br/>
|
||||
|
||||
Example: <b>BASE_%04d</b> will be replaced by <b>BASE_0007</b> for realization number 7. <br/>
|
||||
|
||||
Note that due to limitations in ECLIPSE, the basename <b>must</b> be in strictly upper or lower case.
|
||||
@@ -1 +0,0 @@
|
||||
This should point to an existing <b>GRID/EGRID</b>-file belonging to your ECLIPSE-model.
|
||||
@@ -1,6 +0,0 @@
|
||||
The <b>Init section</b> is used to handle initialization of the ECLIPSE run.
|
||||
This can be used in two different ways:
|
||||
<ul>
|
||||
<li>If it is set to the name of an existing file, the contents of this file will be used for the initialization.
|
||||
<li>If it is set to the name of a non-existing file, it will be assumed that a file with this name in the simulation folder will be generated when simulations are submitted, either by the ERT application itself, or by some job installed by the user. This generated file will then be used by ECLIPSE for initialization.
|
||||
</ul>
|
||||
@@ -1 +0,0 @@
|
||||
Here you may supply ERT with a <b>reference case</b>, i.e an existing ECLIPSE data file, which can be used as observations.
|
||||
@@ -1 +0,0 @@
|
||||
A text file containing the <b>SCHEDULE</b> section of the ECLIPSE data file. The Schedule file is used to control the ECLIPSE simulations.
|
||||
@@ -1 +0,0 @@
|
||||
This is the name of a schedule prediction file. It may contain a <code>%d</code>-specifier to get different files for different members. Observe that the ECLIPSE datafile should include <b>only one</b> schedule file, even if you are doing predictions.
|
||||
@@ -1 +0,0 @@
|
||||
The name of the file ERT will export the field to when running simulations. Note that there should be an <code>IMPORT</code> statement in the ECLIPSE data file corresponding to the name given here.
|
||||
@@ -1 +0,0 @@
|
||||
This if the name of the file generated by the forward model and read by ERT.
|
||||
@@ -1 +0,0 @@
|
||||
Here you may select a mathematical function to be applied to the field <b>when it is loaded.</b>
|
||||
@@ -1 +0,0 @@
|
||||
The <b>Init files</b> are the filenames (filename with an embedded %d) to load the initial field from. This can be in RMS ROFF format, ECLIPSE restart format or ECLIPSE GRDECL format.
|
||||
@@ -1 +0,0 @@
|
||||
Here you can specify a maximum value for the selected field. This is optional.
|
||||
@@ -1 +0,0 @@
|
||||
Here you can specify a minimum value for the selected field. This is optional.
|
||||
@@ -1 +0,0 @@
|
||||
A file containing the minimum variance used in post analysis inflation.
|
||||
@@ -1 +0,0 @@
|
||||
Here you may select a mathematical function to be applied to the field <b>before it is exported.</b>
|
||||
@@ -1,9 +0,0 @@
|
||||
The <b>Fields</b> are parametrizations of quantities which have extent over the full grid. The fields can represent both dynamic properties (e.g pressure or saturations), and static properties (e.g porosity). </br>
|
||||
<dl>
|
||||
<dt><b>Dynamic:</b>
|
||||
<dd>The name of a dynamic field must coincide with the name found in the ECLIPSE restart file, e.g <code>PRESSURE</code>.
|
||||
<dt><b>Parameter:</b>
|
||||
<dd>A parameter field represents a static property (e.g porosity or permeability). Here the name can be an arbitrary string.
|
||||
<dt><b>General:</b>
|
||||
<dd>Using a general field, you have fine-grained control over input/output. This is only relevant for advanced features.
|
||||
</dl>
|
||||
@@ -1 +0,0 @@
|
||||
This is the name of the file written by ERT to be read by the forward model.
|
||||
@@ -1 +0,0 @@
|
||||
This if the name of the file generated by the forward model and read by ERT (i.e. the <code>RESULT_FILE</code>).
|
||||
@@ -1 +0,0 @@
|
||||
Format string with <code>%d</code> of files to load the initial data from.
|
||||
@@ -1 +0,0 @@
|
||||
A file containing the minimum variance used in post analysis inflation.
|
||||
@@ -1,10 +0,0 @@
|
||||
The format of the file written by the forward model (i.e.the <code>RESULT_FILE</code>) and read by ERT.
|
||||
The alternatives are:
|
||||
<dl>
|
||||
<dt>ASCII
|
||||
<dd>A text file with formatted numbers.
|
||||
<dt>BINARY_FLOAT
|
||||
<dd>A vector of binary float numbers.
|
||||
<dt>BINARY_DOUBLE
|
||||
<dd>A vector of binary double numbers.
|
||||
</dl>
|
||||
@@ -1,12 +0,0 @@
|
||||
The format of the files ERT writes for the forward model.
|
||||
The alternatives are:
|
||||
<dl>
|
||||
<dt>ASCII
|
||||
<dd>A text file with formatted numbers.
|
||||
<dt>ASCII_TEMPLATE
|
||||
<dd>A plain text file with formatted numbers, and an arbitrary header/footer.
|
||||
<dt>BINARY_FLOAT
|
||||
<dd>A vector of binary float numbers.
|
||||
<dt>BINARY_DOUBLE
|
||||
<dd>A vector of binary double numbers.
|
||||
</dl>
|
||||
@@ -1 +0,0 @@
|
||||
If you use ASCII_TEMPLATE in <b>Output</b> you must also supply a <b>Template file</b>.
|
||||
@@ -1 +0,0 @@
|
||||
If you use ASCII_TEMPLATE in <b>Output</b> you must also supply a <b>Template key</b>.
|
||||
@@ -1 +0,0 @@
|
||||
This is the name of the file ERT creates for each ensemble member based on the <b>Template</b> file. Note that the <b>Include file</b> must be included manually with a statement in the ECLIPSE data file.
|
||||
@@ -1 +0,0 @@
|
||||
Format string with <code>%d</code> of files to load the initial data from.
|
||||
@@ -1 +0,0 @@
|
||||
A file containing the minimum variance used in post analysis inflation.
|
||||
@@ -1 +0,0 @@
|
||||
The <b>Parameter file</b> is the input file which defines the names of the parameters you want to estimate, and their initial distribution.
|
||||
@@ -1 +0,0 @@
|
||||
The <b>Template</b> file contains some parametrized ECLIPSE statements. The file should contain <code><xxxx></code>-keywords instead of values. ERT will then for each realization replace the keywords in the Template file with values from the distributions defined in the <b>Parameter file</b>.
|
||||
@@ -1 +0,0 @@
|
||||
The number of members/realizations in your ensemble, i.e the ensemble size.
|
||||
@@ -1,9 +0,0 @@
|
||||
ERT will read the historic rates from the <b>Schedule file</b>, but it is also possible to use historic data from another ECLIPSE run (e.g if historic data do not exist in the Schedule file).
|
||||
<dl>
|
||||
<dt><b>SCHEDULE</b>
|
||||
<dd>ERT will use the historic data provided in the Schedule file.
|
||||
<dt><b>REFCASE_SIMULATED</b>
|
||||
<dd>ERT will use simulated values from another ECLIPSE run (a Reference case) as historic data.
|
||||
<dt><b>REFCASE_HISTORY</b>
|
||||
<dd>ERT will use historic data from a reference case.
|
||||
</dl>
|
||||
@@ -1 +0,0 @@
|
||||
This should point to an <b>observation file</b>, a file defining observations and associated uncertainties. It is optional, but strongly recommended to provide an observation file.
|
||||
@@ -1 +0,0 @@
|
||||
In which format should the plots created by PLPLOT be saved (default: png).
|
||||
@@ -1,5 +0,0 @@
|
||||
Here you may decide which application to use to view the plots. The default is a program called <code>/usr/bin/display</code>.
|
||||
<br/>
|
||||
<br/>
|
||||
In order to avoid the plots from flashing in your face as they are created, set Image viewer to <code>/d/proj/bg/enkf/bin/noplot.sh
|
||||
</code>.
|
||||
@@ -1,3 +0,0 @@
|
||||
The plotting engine creates <i>files</i> with plots, they are stored in a directory.
|
||||
You can tell what that directory should be.
|
||||
Observe that the current <i>casename</i> automatically will be appended to the plot path.
|
||||
@@ -1,7 +0,0 @@
|
||||
The <b>Plot Driver</b> is the sub system used for creating plots.
|
||||
<dl>
|
||||
<dt><b>PLPLOT:</b>
|
||||
<dd>This is the default system. All the other options regarding plotting are sub options which are only relevant when you are using this.
|
||||
<dt><b>TEXT:</b>
|
||||
<dd>This will not produce any plots, just textfiles which can be used for plotting with your favorite plotting program. This is particularly relevant if you have some special requirements to the plots.
|
||||
</dl>
|
||||
@@ -1,5 +0,0 @@
|
||||
When plotting summary vectors for which observations have been 'installed' with the <b>Observation config</b>, ERT will plot the observed values. If the number of observations is less than <b>Errorbar max</b>, ERT will use errorbars to show the observed values, otherwise it will use two dashed lines indicating +/- one standard deviation.
|
||||
<br/>
|
||||
To ensure that you always get errorbars you can set <b>Errorbar max</b> to a very large value. On the other hand, setting <b>Errorbar max</b> to zero will ensure that ERT always plots observation uncertainty using dashed lines of +/- one standard deviation.
|
||||
<br/>
|
||||
The setting here will also affect the output when you are using the TEXT driver to plot.
|
||||
@@ -1,2 +0,0 @@
|
||||
When the <b>PLPLOT</b> driver creates a plot file, it will have the height (in pixels) given by the <b>PLOT_HEIGHT</b> keyword.
|
||||
The default value for <b>PLOT_HEIGHT</b> is 1024 pixels.
|
||||
@@ -1,2 +0,0 @@
|
||||
When the <b>PLPLOT</b> driver creates a plot file, it will have the width (in pixels) given by the <b>PLOT_WIDTH</b> keyword.
|
||||
The default value for <b>PLOT_WIDTH</b> is 1024 pixels.
|
||||
@@ -1,2 +0,0 @@
|
||||
Select which LSF queue to use.
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
Specify special LSF requirements here.
|
||||
@@ -1 +0,0 @@
|
||||
Controls the maximum number of simultaneous jobs running when using the LOCAL option. It is strongly recommended to not let this number exceed the number of processors on the workstation used.
|
||||
@@ -1 +0,0 @@
|
||||
Controls the maximum number of simultaneous jobs submitted to the LSF queue when using the LSF option.
|
||||
@@ -1 +0,0 @@
|
||||
Controls the maximum number of simultaneous jobs running when using the RSH option. If this number exceeds the total capacity defined in the <b>RSH Host List</b>, it will automatically be truncated to that capacity.
|
||||
@@ -1,6 +0,0 @@
|
||||
Controls where the simulation jobs are executed.
|
||||
<dl>
|
||||
<dt><b>LSF:</b> Submits the jobs to the LSF cluster at your location.
|
||||
<dt><b>RSH:</b> Submits the jobs to a defined set of workstations.
|
||||
<dt><b>LOCAL:</b> Submits the jobs to your local workstation.
|
||||
</dl>
|
||||
@@ -1 +0,0 @@
|
||||
The name of the executable used to invoke remote shell operations. Will typically be either <code>rsh</code> or <code>ssh</code>. The command given to RSH Command must either be in PATH or an absolute path.
|
||||
@@ -1,6 +0,0 @@
|
||||
To use the RSH queue system you must first set a list of computers which ERT can use for running jobs. The first column takes the computer names, the second takes the number of jobs for each computer. <br/>
|
||||
|
||||
When using the RSH option, note the following: <ol>
|
||||
<li> You <i>must</i> have passwordless login to the computers listed in the <b>Host List</b>. </li>
|
||||
<li> ERT will not consider the total load on the various computers; if having said a computer can take two jobs, it will get two jobs, irrespective of the existing load. </li>
|
||||
</ol>
|
||||
@@ -1 +0,0 @@
|
||||
For running sensitivies you can give the cases descriptive names.
|
||||
@@ -1 +0,0 @@
|
||||
The <b>Forward model</b> defines how the simulations are executed. E.g., which version of ECLIPSE to use, which rel.perm script to run, which rock physics model to use etc.
|
||||
@@ -1 +0,0 @@
|
||||
Specify here if you have special requirements to a job.
|
||||
@@ -1 +0,0 @@
|
||||
The path where the ERT-licenses for the different programs (such as RMS) are stored.
|
||||
@@ -1 +0,0 @@
|
||||
How many times ERT should resample & retry a simulation.
|
||||
@@ -1 +0,0 @@
|
||||
How many times the queue system should retry a simulation.
|
||||
@@ -1 +0,0 @@
|
||||
Select <b>Perform pre clear</b> if you would like the runpath to be cleared before initilaizing.
|
||||
@@ -1 +0,0 @@
|
||||
You may use this option to install arbitrary files in the runpath directory.
|
||||
@@ -1 +0,0 @@
|
||||
config/simulation/run_template_arguments
|
||||
@@ -1 +0,0 @@
|
||||
config/simulation/run_template_file
|
||||
@@ -1 +0,0 @@
|
||||
config/simulation/run_template_target
|
||||
@@ -1,12 +0,0 @@
|
||||
The <b>Runpath</b> should give the name of the folders where the
|
||||
ECLIPSE simulations are to be executed. It should contain at least one
|
||||
%d-specifier, which will be replaced by the realization number when
|
||||
ERT creates the folders. <br/> <br/>
|
||||
|
||||
Optionally, the Runpath can contain two more %d specifers, which will
|
||||
be replaced by the first and last report step of the simulation. By
|
||||
default, Runpath is set to "simulations/realization%d". <br/> <br/>
|
||||
|
||||
When running with LSF it is essential that the <b>Runpath</b> points
|
||||
to a network disk which is accessible with the same path from all the
|
||||
nodes in the cluster.
|
||||
@@ -1,3 +0,0 @@
|
||||
When the ERT application is running it creates directories for the ECLIPSE simulations, one for each realization. Here you can choose which of these realization directories to keep and which to delete.
|
||||
<br/>
|
||||
Note that if you are using the ERT application to run the EnKF algorithm (i.e. <i>EnKF assimilation</i>), the default behavior is to delete these directories after the simulation results have been internalized. When running the ERT application as a convenient way to start many simulations (i.e. <i>Ensemble experiment</i>), the default behavior is to keep these directories.
|
||||
@@ -1 +0,0 @@
|
||||
config/systemenv/install_job_arglist
|
||||
@@ -1 +0,0 @@
|
||||
config/systemenv/install_job_env
|
||||
@@ -1 +0,0 @@
|
||||
config/systemenv/install_job_executable
|
||||
@@ -1 +0,0 @@
|
||||
config/systemenv/install_job_lsf_resources
|
||||
@@ -1 +0,0 @@
|
||||
config/systemenv/install_job_max_running
|
||||
@@ -1 +0,0 @@
|
||||
config/systemenv/install_job_max_running_minutes
|
||||
@@ -1 +0,0 @@
|
||||
config/systemenv/install_job_path
|
||||
@@ -1 +0,0 @@
|
||||
config/systemenv/install_job_stderr
|
||||
@@ -1 +0,0 @@
|
||||
config/systemenv/install_job_stdin
|
||||
@@ -1 +0,0 @@
|
||||
config/systemenv/install_job_stdout
|
||||
@@ -1 +0,0 @@
|
||||
config/systemenv/install_job_target_file
|
||||
@@ -1 +0,0 @@
|
||||
config/systemenv/install_jobs
|
||||
@@ -1,7 +0,0 @@
|
||||
Running the forward model from enkf is a multi-level process which can be summarized as follows:
|
||||
<ol>
|
||||
<li> A Python module called <code>jobs.py</code> is written and stored in the directory where the forward simulation is run. This module contains a list of job-elements, where each element is a Python representation of the code entered when installing the job. </li>
|
||||
<li> The ERT application submits a Python script to the EnKF queue system, this script then loads the <code>jobs.py</code> module to find out which programs to run, and how to run them. </li>
|
||||
<li> The Job script starts and monitors the individual jobs in the <code>jobs.py</code> module. </li>
|
||||
</ol>
|
||||
<b>Job script</b> should point at the Python script which is managing the forward model.
|
||||
@@ -1 +0,0 @@
|
||||
The name of the log file.
|
||||
@@ -1 +0,0 @@
|
||||
The amount of logging.
|
||||
@@ -1,4 +0,0 @@
|
||||
You can use <b>setenv</b> to alter the unix environment ERT is running
|
||||
in. This is probably most relevant for setting up the environment for
|
||||
the external jobs invoked by ERT. It is possible to use $VAR to refer
|
||||
to an existing environment variable.
|
||||
@@ -1 +0,0 @@
|
||||
The <b>Update path</b> option will <i>prepend</i> a new element to an existing <code>PATH</code> variable.
|
||||
@@ -1 +0,0 @@
|
||||
List of available cases.
|
||||
@@ -1 +0,0 @@
|
||||
The case to initialize.
|
||||
@@ -1 +0,0 @@
|
||||
<html>%s</html>
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 394 B |
Binary file not shown.
|
Before Width: | Height: | Size: 516 B |
Binary file not shown.
|
Before Width: | Height: | Size: 497 B |
Binary file not shown.
|
Before Width: | Height: | Size: 514 B |
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user