opm - User contributions [en]

Upscale simple statistics

2022-04-25T11:27:44Z

Alfbr: /* Usage */

{{DISPLAYTITLE:Cpchop}}
'''cpchop''' is a command line utility for doing subsampling and property analysis of Eclipse grid files, typically generated in SBED or ReservoirStudio, but can be used on all corner point grids with box shape and vertical pillars.

The progams picks (optionally random) subsamples from the model and analyzes these. There are a variety of different properties to analyze for each submodel, the most common being single phase permeability (flow based upscaling equivalent to the stand alone tool upscale_perm and bulk properties like porosity and ntg. Results from this kind of analysis can be outputted to a resultfile.

The program can also output the subsamples them selves into new stand alone corner point grids in grdecl format.

=Usage=
The program can currently only be run from a Linux command line. Follow [[Res:Binary_distribution_of_libraries_and_utilities#Users_of_executables_and_libraries|these instructions]] for access to the binary files.

$ cpchop gridfilename=cornerpointgrid.grdecl [option=value]
The gridfile must have a shoebox shape with vertical pillars.

{| class="wikitable" border=1 cellspacing=1
!align=left|Option
!align=left width=300pt| Description
!align=left| Default value
|-
|subsamples
|number of subsamples
|1
|-
|filebase
|If supplied, grdecl-files for each subsample will be written to files named using this filebase, it may include directory names
|
|-
|resultfile
|name of a textfile to output table of results pr. subsample to
|
|-
|ilen
|length in i-direction of subsample, specified in number of cells(!)
|all cells in i-direction
|-
|jlen
|length in j-direction of subsample, specified in number of cells(!)
|all cells in j-direction
|-
|zlen
|length in z-direction of subsample, specified in the grids length unit (typically cm or m)
|full height
|-
|imin
|can be used to limit the search area for random subsamples
|minimum i in inputgrid (full model)
|-
|imax
|can be used to limit the search area for random subsamples
|maximum i in inputgrid (full model)
|-
|jmin
|analog to imin, but in j-direction
|minimum j in inputgrid (full model)
|-
|jmax
|analog to imax, but in j-direction
|maximum j in inputgrid (full model)
|-
|zmin
|analog to imin, but in z-direction and specified in the grids length unit
|minimum in inputgrid
|-
|zmax
|analog to imax, but in z-direction and specified in the grids length unit
|maximum in inputgrid
|-
|upscale
|boolean for whether to do upscaling on the subsamples, either true or false. If the objective is to obtain a grdecl-file for the subsample, set to false for run time.
|true
|-
|bc
|boundary condition type for upscaling, either fixed or periodic
|fixed
|-
|resettoorigin
|If true, outputted grdecl-file will have its ZCORN-values and COORDS-values shifted so that the model is defined at the origin. If false, the outputted grdecl-file will be located in its original position.
|true
|-
|seed
|
|
|-
|minperm
|
|
|-
|dips
|
|
|-
|azimuthdisplacement
|
|
|-
|satnumvolumes
|
|
|-
|mincellvolume
|
|
|-
|endpoints
|
|
|-
|cappres
|
|
|-
|rock_list
|
|
|-
|anisotropicrocks
|
|
|}

Output:
* If wanted, each subsample is outputted to a grdecl-file that can be analyzed further
* A list of upscaled porosity and permeability for each subsample

==Example==
$ cpchop gridfilename=HugeReservoirStudioGrid.grdecl subsamples=100 ilen=5 jlen=5 zlen=5

==Command line options==
* ''gridfilename'' - grdecl filename to be analyzed
* ''subsamples'' - number of subsamples. Default 1.
* ''resultfile'' - name of a textfile to output table of results pr. subsample to
* ''filebase'' - If supplied, grdecl-files for each subsample will be written to files named using this filebase, it may include directory names.
* ''ilen'' - length in i-direction of subsample, specified in number of cells(!). Default is all cells in i-direction.
* ''jlen'' - length in j-direction of subsample, specified in number of cells. Default is all cells in j-direction.
* ''zlen'' - length in z-direction of subsample, specified in the grids length unit (typically cm or m). Default is full height.
* ''imin'' and ''imax'' - can be used to limit the search area for random subsamples.
* ''jmin'', ''jmax'', ''zmin'' and ''zmax'' - vice versa. These values default to the whole grid.
* ''upscale'' - a boolean for whether upscaling is to be done on the fly, either true or false. True by default. Set this to false if your objective is to obtain a grdecl-file for the subsample.
* ''bc'' - boundary condition type for upscaling, either fixed or periodic. Default is fixed.
* ''seed'' - an integer to be used for seed for random number generator. Default is to pick a seed from current time.
* ''resettoorigin'' - If true, outputted grdecl-file will have its ZCORN-values and COORDS-values shifted so that the model is defined at the origin. If false, the outputted grdecl-file will be located in its original position. Default is true.
* ''satnumvolumes'' - if true, relative volumes pr. SATNUM is also calculated.
* ''dips'' - if true, dips are also measured for subsamples, see [[Res:Grdecldips]]. Outputted values are dip and azimuth for each subsample.
* ''azimuthdisplacement'' - if ''dips'' are true, this can be used to add displament to the outputted azimuths. If left 0 (default), the azimuth will be relative to the grid.
* ''mincellvolume'', if ''dips'' are true, this is used to avoid cells within subsamples for the dip calculation. Default 1e-8.
* ''endpoints'' - if true, saturation endpoints are calculated. A list specifying input saturation data for each rock type must also be given.
* ''rock_list'' - A file with a list of one file per satnum specifying two phase properties for each rock type

NB: If bundary condition type (bc) is periodic, the subsample must be at least 3 cells in each direction, i.e. ilen and jlen must be 3 or larger and zlen must be set large enough to include at least 3 layers.

Upscale simple statistics

2022-04-25T11:26:59Z

Alfbr: /* Command line options */

{{DISPLAYTITLE:Cpchop}}
'''cpchop''' is a command line utility for doing subsampling and property analysis of Eclipse grid files, typically generated in SBED or ReservoirStudio, but can be used on all corner point grids with box shape and vertical pillars.

The progams picks (optionally random) subsamples from the model and analyzes these. There are a variety of different properties to analyze for each submodel, the most common being single phase permeability (flow based upscaling equivalent to the stand alone tool upscale_perm and bulk properties like porosity and ntg. Results from this kind of analysis can be outputted to a resultfile.

The program can also output the subsamples them selves into new stand alone corner point grids in grdecl format.

=Usage=
The program can currently only be run from a Linux command line. Follow [[Res:Binary_distribution_of_libraries_and_utilities#Users_of_executables_and_libraries|these instructions]] for access to the binary files.

$ cpchop gridfilename=cornerpointgrid.grdecl [option=value]
The gridfile must have a shoebox shape with vertical pillars.

{| class="wikitable" border=1 cellspacing=1
!align=left|Option
!align=left width=300pt| Description
!align=left| Default value
|-
|subsamples
|number of subsamples
|1
|-
|filebase
|If supplied, grdecl-files for each subsample will be written to files named using this filebase, it may include directory names
|
|-
|resultfile
|name of a textfile to output table of results pr. subsample to
|
|-
|ilen
|length in i-direction of subsample, specified in number of cells(!)
|all cells in i-direction
|-
|jlen
|length in j-direction of subsample, specified in number of cells(!)
|all cells in j-direction
|-
|zlen
|length in z-direction of subsample, specified in the grids length unit (typically cm or m)
|full height
|-
|imin
|can be used to limit the search area for random subsamples
|minimum i in inputgrid (full model)
|-
|imax
|can be used to limit the search area for random subsamples
|maximum i in inputgrid (full model)
|-
|jmin
|analog to imin, but in j-direction
|minimum j in inputgrid (full model)
|-
|jmax
|analog to imax, but in j-direction
|maximum j in inputgrid (full model)
|-
|zmin
|analog to imin, but in z-direction and specified in the grids length unit
|minimum in inputgrid
|-
|zmax
|analog to imax, but in z-direction and specified in the grids length unit
|maximum in inputgrid
|-
|upscale
|boolean for whether to do upscaling on the subsamples, either true or false. If the objective is to obtain a grdecl-file for the subsample, set to false for run time.
|true
|-
|bc
|boundary condition type for upscaling, either fixed or periodic
|fixed
|-
|resettoorigin
|If true, outputted grdecl-file will have its ZCORN-values and COORDS-values shifted so that the model is defined at the origin. If false, the outputted grdecl-file will be located in its original position.
|true
|-
|seed
|
|
|-
|z_tolerance
|
|
|-
|minperm
|
|
|-
|dips
|
|
|-
|azimuthdisplacement
|
|
|-
|satnumvolumes
|
|
|-
|mincellvolume
|
|
|-
|endpoints
|
|
|-
|cappres
|
|
|-
|rock_list
|
|
|-
|anisotropicrocks
|
|
|}

Output:
* If wanted, each subsample is outputted to a grdecl-file that can be analyzed further
* A list of upscaled porosity and permeability for each subsample

==Example==
$ cpchop gridfilename=HugeReservoirStudioGrid.grdecl subsamples=100 ilen=5 jlen=5 zlen=5

==Command line options==
* ''gridfilename'' - grdecl filename to be analyzed
* ''subsamples'' - number of subsamples. Default 1.
* ''resultfile'' - name of a textfile to output table of results pr. subsample to
* ''filebase'' - If supplied, grdecl-files for each subsample will be written to files named using this filebase, it may include directory names.
* ''ilen'' - length in i-direction of subsample, specified in number of cells(!). Default is all cells in i-direction.
* ''jlen'' - length in j-direction of subsample, specified in number of cells. Default is all cells in j-direction.
* ''zlen'' - length in z-direction of subsample, specified in the grids length unit (typically cm or m). Default is full height.
* ''imin'' and ''imax'' - can be used to limit the search area for random subsamples.
* ''jmin'', ''jmax'', ''zmin'' and ''zmax'' - vice versa. These values default to the whole grid.
* ''upscale'' - a boolean for whether upscaling is to be done on the fly, either true or false. True by default. Set this to false if your objective is to obtain a grdecl-file for the subsample.
* ''bc'' - boundary condition type for upscaling, either fixed or periodic. Default is fixed.
* ''seed'' - an integer to be used for seed for random number generator. Default is to pick a seed from current time.
* ''resettoorigin'' - If true, outputted grdecl-file will have its ZCORN-values and COORDS-values shifted so that the model is defined at the origin. If false, the outputted grdecl-file will be located in its original position. Default is true.
* ''satnumvolumes'' - if true, relative volumes pr. SATNUM is also calculated.
* ''dips'' - if true, dips are also measured for subsamples, see [[Res:Grdecldips]]. Outputted values are dip and azimuth for each subsample.
* ''azimuthdisplacement'' - if ''dips'' are true, this can be used to add displament to the outputted azimuths. If left 0 (default), the azimuth will be relative to the grid.
* ''mincellvolume'', if ''dips'' are true, this is used to avoid cells within subsamples for the dip calculation. Default 1e-8.
* ''endpoints'' - if true, saturation endpoints are calculated. A list specifying input saturation data for each rock type must also be given.
* ''rock_list'' - A file with a list of one file per satnum specifying two phase properties for each rock type

NB: If bundary condition type (bc) is periodic, the subsample must be at least 3 cells in each direction, i.e. ilen and jlen must be 3 or larger and zlen must be set large enough to include at least 3 layers.

Main Page

2022-02-08T14:43:43Z

Alfbr: /* Viewing ECLIPSE summary files */

= Getting started with OPM =

We have a [[Quick Installation]] guide, showing how to install the opm-core library.

The [[FPGA setup and building]] guide explains how to compile and use the ''bitstream'' for the FPGA-enabled Flow simulator.

The [//opm-project.org/?page_id=43 tutorials] section contain some tutorials for programmers using opm-core.

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

'''''Please note that the content of this wiki is in the process of being updated, many parts are not current!'''''

= User documentation for selected programs =
* Black-oil reservoir simulator Flow:
** [[Black-oil simulator|Black-oil simulator]]
** [[Thermal simulator|Thermal simulator]]
** [[Water evaporation|Water evaporation]]
** [[Salt precipitation|Salt precipitation]]
* [[CO2 sequestration]]
* [[Enhanced oil recovery]]
* [[Geothermal flow_onephase_energy]]
* [[Upscaling]]

= Developer Information =

=== How to contribute ===

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on [//github.com/OPM github]. The process of contributing changes is the following:
* Fork the module for which you want to propose a change on github
* Locally create a new branch of the module's repository which contains your changes
* Push this branch to your personal github fork
* [https://help.github.com/articles/using-pull-requests Create a pull request]
* To make a pull request (PR) easy to review (and likely to be merged):
** A PR should contain a single feature, preferably with a unit test.
** It should not be too large. If you change lots of lines in lots of files in an automatic refactoring, show the script/commands you used.
** If you change existing code, do not mix feature changes and (large amounts of) pure formatting changes (use a separate PR for that).
** [http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Some more tips on PRs]
* After some discussion, one of the module maintainers will either merge your changes, or your changes will be rejected with an explanation why they are a bad idea.
* Often, you will be asked to make some modification to the code in the PR. Do this locally, and push the changes to the same repo and branch that you used for the PR. It will be updated automatically (as a corollary, do not use this branch for unrelated development -- start a new one instead).

=== Coding standard ===

We do not at the moment mandate a specific coding standard, but in practice we try to have a
homogenous code base, and encourage all contributors to follow certain practices.

These are listed in the [[Suggested coding standard]].

=== List of module maintainers ===

The current module maintainers (and their github user names) are:

* '''opm-common''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Arne Morten Kvarving (@akva2), Joakim Hove (@joakim-hove), Markus Blatt (@blattms)
* '''opm-material''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms) and Robert Klöfkorn (@dr-robertk)
* '''opm-models''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
* '''opm-tests''': Alf Birger Rustad (@alfbr), Torbjørn Skille (@tskille) and Bård Skaflestad (@bksa).
* '''opm-upscaling''': Arne Morten Kvarving (@akva2)
* '''ResInsight''': Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)

=== Jenkins information ===

[https://ci.opm-project.org Jenkins dashboard].

Information about [[Jenkins triggers]].

=== Nightly binary packages for Ubuntu and Red Hat ===

List of available [https://opm-project.org/package/ nightly images] generated by Jenkins. Note that in order to use the Ubuntu binaries you must add the PPA containing these nightly binaries:
# NOTE: you may need to sudo some of these apt commands!
# Add gpg key for repository
wget -qO - https://opm-project.org/package/nightly-bionic/repokey.gpg | apt-key add -
# Add repo itself
apt-add-repository https://opm-project.org/package/nightly-bionic
# Look at available nightly versions
apt-cache show libopm-simulators1-bin

=== Static analysis tools ===

Information about [[static analysis tools]] available.

=== Help for release managers ===

[[Notes for managing release 2016.10]]

=== Data required for output and restarting ===

[[Data for output and restart]]

= Viewing ECLIPSE summary files =
[//resinsight.org/ Resinsight] provides a state-of-the art solution for all post-processing of reservoir simulation, including plotting functionality for summary files. Resinsight can be installed from [//opm-project.org/?page_id=245 packages or source].

== Through lightweight GUI ==
For those who like to keep clicking at a minimum, a lean plotting tool is found i qsummary. No binaries are available at the moment, so you will need to compile yourself from:
https://github.com/OPM/qsummary

== Through command-line ==
A command-line application named ''summary'' is distributed with OPM packages, and can be compiled from source in https://github.com/OPM/opm-common
It will give you direct access to any summary vectors, which subsequently can be handled through gnuplot, spreadsheet, or whatever you choose.

== Through Python script ==
The script is found in opm-utilities. The script in question is a Python script and some requirements must be satisifed:

<ol>
<li> You need the Python packages <tt>matplotlib</tt> and <tt>numpy</tt>.</li>
<li> You must compile/enable ERT Python packages when building ert. Then make sure that the path <tt>CMAKE_INSTALL_PREFIX/python</tt> is in your <tt>PYTHONPATH</tt>.
</ol>

When everything is installed the <tt>summaryplot</tt> application can be used, it can plot mulitple realisations:

<pre>
summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA
</pre>
[[File:Profile.png|border]]

== Plots ==
The full Norne model is run once a week, and PDF document with all the well results is generated: http://95.85.43.55/plots/

Main Page

2022-02-08T14:40:10Z

Alfbr: /* Viewing ECLIPSE summary files */

= Getting started with OPM =

We have a [[Quick Installation]] guide, showing how to install the opm-core library.

The [[FPGA setup and building]] guide explains how to compile and use the ''bitstream'' for the FPGA-enabled Flow simulator.

The [//opm-project.org/?page_id=43 tutorials] section contain some tutorials for programmers using opm-core.

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

'''''Please note that the content of this wiki is in the process of being updated, many parts are not current!'''''

= User documentation for selected programs =
* Black-oil reservoir simulator Flow:
** [[Black-oil simulator|Black-oil simulator]]
** [[Thermal simulator|Thermal simulator]]
** [[Water evaporation|Water evaporation]]
** [[Salt precipitation|Salt precipitation]]
* [[CO2 sequestration]]
* [[Enhanced oil recovery]]
* [[Geothermal flow_onephase_energy]]
* [[Upscaling]]

= Developer Information =

=== How to contribute ===

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on [//github.com/OPM github]. The process of contributing changes is the following:
* Fork the module for which you want to propose a change on github
* Locally create a new branch of the module's repository which contains your changes
* Push this branch to your personal github fork
* [https://help.github.com/articles/using-pull-requests Create a pull request]
* To make a pull request (PR) easy to review (and likely to be merged):
** A PR should contain a single feature, preferably with a unit test.
** It should not be too large. If you change lots of lines in lots of files in an automatic refactoring, show the script/commands you used.
** If you change existing code, do not mix feature changes and (large amounts of) pure formatting changes (use a separate PR for that).
** [http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Some more tips on PRs]
* After some discussion, one of the module maintainers will either merge your changes, or your changes will be rejected with an explanation why they are a bad idea.
* Often, you will be asked to make some modification to the code in the PR. Do this locally, and push the changes to the same repo and branch that you used for the PR. It will be updated automatically (as a corollary, do not use this branch for unrelated development -- start a new one instead).

=== Coding standard ===

We do not at the moment mandate a specific coding standard, but in practice we try to have a
homogenous code base, and encourage all contributors to follow certain practices.

These are listed in the [[Suggested coding standard]].

=== List of module maintainers ===

The current module maintainers (and their github user names) are:

* '''opm-common''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Arne Morten Kvarving (@akva2), Joakim Hove (@joakim-hove), Markus Blatt (@blattms)
* '''opm-material''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms) and Robert Klöfkorn (@dr-robertk)
* '''opm-models''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
* '''opm-tests''': Alf Birger Rustad (@alfbr), Torbjørn Skille (@tskille) and Bård Skaflestad (@bksa).
* '''opm-upscaling''': Arne Morten Kvarving (@akva2)
* '''ResInsight''': Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)

=== Jenkins information ===

[https://ci.opm-project.org Jenkins dashboard].

Information about [[Jenkins triggers]].

=== Nightly binary packages for Ubuntu and Red Hat ===

List of available [https://opm-project.org/package/ nightly images] generated by Jenkins. Note that in order to use the Ubuntu binaries you must add the PPA containing these nightly binaries:
# NOTE: you may need to sudo some of these apt commands!
# Add gpg key for repository
wget -qO - https://opm-project.org/package/nightly-bionic/repokey.gpg | apt-key add -
# Add repo itself
apt-add-repository https://opm-project.org/package/nightly-bionic
# Look at available nightly versions
apt-cache show libopm-simulators1-bin

=== Static analysis tools ===

Information about [[static analysis tools]] available.

=== Help for release managers ===

[[Notes for managing release 2016.10]]

=== Data required for output and restarting ===

[[Data for output and restart]]

= Viewing ECLIPSE summary files =
[//resinsight.org/ Resinsight] provides a state-of-the art solution for all post-processing of reservoir simulation, including plotting functionality for summary files. In addition, there is the summary application within opm-common that extracts summary vectors directly on the command line.

== Through lightweight GUI ==
For those who like to keep clicking at a minimum, a lean plotting tool is found i qsummary. No binaries are available at the moment, so you will need to compile yourself from:
https://github.com/OPM/qsummary

== Through command-line ==
A command-line application named ''summary'' is distributed with OPM packages, and can be compiled from source in https://github.com/OPM/opm-common
It will give you direct access to any summary vectors, which subsequently can be handled through gnuplot, spreadsheet, or whatever you choose.

== Through Python script ==
The script is found in opm-utilities. The script in question is a Python script and some requirements must be satisifed:

<ol>
<li> You need the Python packages <tt>matplotlib</tt> and <tt>numpy</tt>.</li>
<li> You must compile/enable ERT Python packages when building ert. Then make sure that the path <tt>CMAKE_INSTALL_PREFIX/python</tt> is in your <tt>PYTHONPATH</tt>.
</ol>

When everything is installed the <tt>summaryplot</tt> application can be used, it can plot mulitple realisations:

<pre>
summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA
</pre>
[[File:Profile.png|border]]

== Plots ==
The full Norne model is run once a week, and PDF document with all the well results is generated: http://95.85.43.55/plots/

Main Page

2022-02-08T14:36:46Z

Alfbr: /* User documentation for selected programs */

= Getting started with OPM =

We have a [[Quick Installation]] guide, showing how to install the opm-core library.

The [[FPGA setup and building]] guide explains how to compile and use the ''bitstream'' for the FPGA-enabled Flow simulator.

The [//opm-project.org/?page_id=43 tutorials] section contain some tutorials for programmers using opm-core.

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

'''''Please note that the content of this wiki is in the process of being updated, many parts are not current!'''''

= User documentation for selected programs =
* Black-oil reservoir simulator Flow:
** [[Black-oil simulator|Black-oil simulator]]
** [[Thermal simulator|Thermal simulator]]
** [[Water evaporation|Water evaporation]]
** [[Salt precipitation|Salt precipitation]]
* [[CO2 sequestration]]
* [[Enhanced oil recovery]]
* [[Geothermal flow_onephase_energy]]
* [[Upscaling]]

= Developer Information =

=== How to contribute ===

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on [//github.com/OPM github]. The process of contributing changes is the following:
* Fork the module for which you want to propose a change on github
* Locally create a new branch of the module's repository which contains your changes
* Push this branch to your personal github fork
* [https://help.github.com/articles/using-pull-requests Create a pull request]
* To make a pull request (PR) easy to review (and likely to be merged):
** A PR should contain a single feature, preferably with a unit test.
** It should not be too large. If you change lots of lines in lots of files in an automatic refactoring, show the script/commands you used.
** If you change existing code, do not mix feature changes and (large amounts of) pure formatting changes (use a separate PR for that).
** [http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Some more tips on PRs]
* After some discussion, one of the module maintainers will either merge your changes, or your changes will be rejected with an explanation why they are a bad idea.
* Often, you will be asked to make some modification to the code in the PR. Do this locally, and push the changes to the same repo and branch that you used for the PR. It will be updated automatically (as a corollary, do not use this branch for unrelated development -- start a new one instead).

=== Coding standard ===

We do not at the moment mandate a specific coding standard, but in practice we try to have a
homogenous code base, and encourage all contributors to follow certain practices.

These are listed in the [[Suggested coding standard]].

=== List of module maintainers ===

The current module maintainers (and their github user names) are:

* '''opm-common''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Arne Morten Kvarving (@akva2), Joakim Hove (@joakim-hove), Markus Blatt (@blattms)
* '''opm-material''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms) and Robert Klöfkorn (@dr-robertk)
* '''opm-models''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
* '''opm-tests''': Alf Birger Rustad (@alfbr), Torbjørn Skille (@tskille) and Bård Skaflestad (@bksa).
* '''opm-upscaling''': Arne Morten Kvarving (@akva2)
* '''ResInsight''': Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)

=== Jenkins information ===

[https://ci.opm-project.org Jenkins dashboard].

Information about [[Jenkins triggers]].

=== Nightly binary packages for Ubuntu and Red Hat ===

List of available [https://opm-project.org/package/ nightly images] generated by Jenkins. Note that in order to use the Ubuntu binaries you must add the PPA containing these nightly binaries:
# NOTE: you may need to sudo some of these apt commands!
# Add gpg key for repository
wget -qO - https://opm-project.org/package/nightly-bionic/repokey.gpg | apt-key add -
# Add repo itself
apt-add-repository https://opm-project.org/package/nightly-bionic
# Look at available nightly versions
apt-cache show libopm-simulators1-bin

=== Static analysis tools ===

Information about [[static analysis tools]] available.

=== Help for release managers ===

[[Notes for managing release 2016.10]]

=== Data required for output and restarting ===

[[Data for output and restart]]

= Viewing ECLIPSE summary files =
Resinsight provides a state-of-the art solution for all post-processing of reservoir simulation, including plotting functionality for summary files. In addition, there is the summary application within opm-common that extracts summary vectors directly on the command line.

== Through lightweight GUI ==
For those who like to keep clicking at a minimum, a lean plotting tool is found i qsummary. No binaries are available at the moment, so you will need to compile yourself from:
https://github.com/OPM/qsummary

== Through command-line ==
A command-line application named ''summary'' is distributed with OPM packages, and can be compiled from source in https://github.com/OPM/opm-common
It will give you direct access to any summary vectors, which subsequently can be handled through gnuplot, spreadsheet, or whatever you choose.

== Through Python script ==
The script is found in opm-utilities. The script in question is a Python script and some requirements must be satisifed:

<ol>
<li> You need the Python packages <tt>matplotlib</tt> and <tt>numpy</tt>.</li>
<li> You must compile/enable ERT Python packages when building ert. Then make sure that the path <tt>CMAKE_INSTALL_PREFIX/python</tt> is in your <tt>PYTHONPATH</tt>.
</ol>

When everything is installed the <tt>summaryplot</tt> application can be used, it can plot mulitple realisations:

<pre>
summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA
</pre>
[[File:Profile.png|border]]

== Plots ==
The full Norne model is run once a week, and PDF document with all the well results is generated: http://95.85.43.55/plots/

Main Page

2022-02-08T14:36:01Z

Alfbr:

= Getting started with OPM =

We have a [[Quick Installation]] guide, showing how to install the opm-core library.

The [[FPGA setup and building]] guide explains how to compile and use the ''bitstream'' for the FPGA-enabled Flow simulator.

The [//opm-project.org/?page_id=43 tutorials] section contain some tutorials for programmers using opm-core.

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

'''''Please note that the content of this wiki is in the process of being updated, many parts are not current!'''''

= User documentation for selected programs =
* Black-oil reservoir flow:
** [[Black-oil simulator|Black-oil simulator]]
** [[Thermal simulator|Thermal simulator]]
** [[Water evaporation|Water evaporation]]
** [[Salt precipitation|Salt precipitation]]
* [[CO2 sequestration]]
* [[Enhanced oil recovery]]
* [[Geothermal flow_onephase_energy]]
* [[Upscaling]]

= Developer Information =

=== How to contribute ===

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on [//github.com/OPM github]. The process of contributing changes is the following:
* Fork the module for which you want to propose a change on github
* Locally create a new branch of the module's repository which contains your changes
* Push this branch to your personal github fork
* [https://help.github.com/articles/using-pull-requests Create a pull request]
* To make a pull request (PR) easy to review (and likely to be merged):
** A PR should contain a single feature, preferably with a unit test.
** It should not be too large. If you change lots of lines in lots of files in an automatic refactoring, show the script/commands you used.
** If you change existing code, do not mix feature changes and (large amounts of) pure formatting changes (use a separate PR for that).
** [http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Some more tips on PRs]
* After some discussion, one of the module maintainers will either merge your changes, or your changes will be rejected with an explanation why they are a bad idea.
* Often, you will be asked to make some modification to the code in the PR. Do this locally, and push the changes to the same repo and branch that you used for the PR. It will be updated automatically (as a corollary, do not use this branch for unrelated development -- start a new one instead).

=== Coding standard ===

We do not at the moment mandate a specific coding standard, but in practice we try to have a
homogenous code base, and encourage all contributors to follow certain practices.

These are listed in the [[Suggested coding standard]].

=== List of module maintainers ===

The current module maintainers (and their github user names) are:

* '''opm-common''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Arne Morten Kvarving (@akva2), Joakim Hove (@joakim-hove), Markus Blatt (@blattms)
* '''opm-material''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms) and Robert Klöfkorn (@dr-robertk)
* '''opm-models''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
* '''opm-tests''': Alf Birger Rustad (@alfbr), Torbjørn Skille (@tskille) and Bård Skaflestad (@bksa).
* '''opm-upscaling''': Arne Morten Kvarving (@akva2)
* '''ResInsight''': Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)

=== Jenkins information ===

[https://ci.opm-project.org Jenkins dashboard].

Information about [[Jenkins triggers]].

=== Nightly binary packages for Ubuntu and Red Hat ===

List of available [https://opm-project.org/package/ nightly images] generated by Jenkins. Note that in order to use the Ubuntu binaries you must add the PPA containing these nightly binaries:
# NOTE: you may need to sudo some of these apt commands!
# Add gpg key for repository
wget -qO - https://opm-project.org/package/nightly-bionic/repokey.gpg | apt-key add -
# Add repo itself
apt-add-repository https://opm-project.org/package/nightly-bionic
# Look at available nightly versions
apt-cache show libopm-simulators1-bin

=== Static analysis tools ===

Information about [[static analysis tools]] available.

=== Help for release managers ===

[[Notes for managing release 2016.10]]

=== Data required for output and restarting ===

[[Data for output and restart]]

= Viewing ECLIPSE summary files =
Resinsight provides a state-of-the art solution for all post-processing of reservoir simulation, including plotting functionality for summary files. In addition, there is the summary application within opm-common that extracts summary vectors directly on the command line.

== Through lightweight GUI ==
For those who like to keep clicking at a minimum, a lean plotting tool is found i qsummary. No binaries are available at the moment, so you will need to compile yourself from:
https://github.com/OPM/qsummary

== Through command-line ==
A command-line application named ''summary'' is distributed with OPM packages, and can be compiled from source in https://github.com/OPM/opm-common
It will give you direct access to any summary vectors, which subsequently can be handled through gnuplot, spreadsheet, or whatever you choose.

== Through Python script ==
The script is found in opm-utilities. The script in question is a Python script and some requirements must be satisifed:

<ol>
<li> You need the Python packages <tt>matplotlib</tt> and <tt>numpy</tt>.</li>
<li> You must compile/enable ERT Python packages when building ert. Then make sure that the path <tt>CMAKE_INSTALL_PREFIX/python</tt> is in your <tt>PYTHONPATH</tt>.
</ol>

When everything is installed the <tt>summaryplot</tt> application can be used, it can plot mulitple realisations:

<pre>
summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA
</pre>
[[File:Profile.png|border]]

== Plots ==
The full Norne model is run once a week, and PDF document with all the well results is generated: http://95.85.43.55/plots/

Black-oil simulator

2022-02-08T14:35:46Z

Alfbr:

The black-oil simulator Flow is provided in the opm-simulators repository. It is very well documented (see the [//opm-project.org/?page_id=955 manual]), and available on the most popular linux distributions. It can also be compiled on Mac and Windows.

Black-oil simulator

2022-02-08T14:34:40Z

Alfbr: Created page with "The black-oil simulator Flow is provided in the opm-simulators repository. It is very well documented (see the [manual https://opm-project.org/?page_id=955]), and available on..."

The black-oil simulator Flow is provided in the opm-simulators repository. It is very well documented (see the [manual https://opm-project.org/?page_id=955]), and available on the most popular linux distributions. It can also be compiled on Mac and Windows.

Main Page

2022-02-08T14:30:59Z

Alfbr: /* Through lightweight GUI */

= Getting started with OPM =

We have a [[Quick Installation]] guide, showing how to install the opm-core library.

The [[FPGA setup and building]] guide explains how to compile and use the ''bitstream'' for the FPGA-enabled Flow simulator.

The [//opm-project.org/?page_id=43 tutorials] section contain some tutorials for programmers using opm-core.

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

'''''Please note that the content of this wiki is in the process of being updated, many parts are not current!'''''

= User documentation for selected programs =
* [[Aquifer flow_onephase]]
* Black-oil reservoir flow:
** [[Black-oil simulator|Black-oil simulator]]
** [[Thermal simulator|Thermal simulator]]
** [[Water evaporation|Water evaporation]]
** [[Salt precipitation|Salt precipitation]]
* [[CO2 sequestration]]
* [[Enhanced oil recovery]]
* [[Geothermal flow_onephase_energy]]
* [[Upscaling]]

= Developer Information =

=== How to contribute ===

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on [//github.com/OPM github]. The process of contributing changes is the following:
* Fork the module for which you want to propose a change on github
* Locally create a new branch of the module's repository which contains your changes
* Push this branch to your personal github fork
* [https://help.github.com/articles/using-pull-requests Create a pull request]
* To make a pull request (PR) easy to review (and likely to be merged):
** A PR should contain a single feature, preferably with a unit test.
** It should not be too large. If you change lots of lines in lots of files in an automatic refactoring, show the script/commands you used.
** If you change existing code, do not mix feature changes and (large amounts of) pure formatting changes (use a separate PR for that).
** [http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Some more tips on PRs]
* After some discussion, one of the module maintainers will either merge your changes, or your changes will be rejected with an explanation why they are a bad idea.
* Often, you will be asked to make some modification to the code in the PR. Do this locally, and push the changes to the same repo and branch that you used for the PR. It will be updated automatically (as a corollary, do not use this branch for unrelated development -- start a new one instead).

=== Coding standard ===

We do not at the moment mandate a specific coding standard, but in practice we try to have a
homogenous code base, and encourage all contributors to follow certain practices.

These are listed in the [[Suggested coding standard]].

=== List of module maintainers ===

The current module maintainers (and their github user names) are:

* '''opm-common''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Arne Morten Kvarving (@akva2), Joakim Hove (@joakim-hove), Markus Blatt (@blattms)
* '''opm-material''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms) and Robert Klöfkorn (@dr-robertk)
* '''opm-models''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
* '''opm-tests''': Alf Birger Rustad (@alfbr), Torbjørn Skille (@tskille) and Bård Skaflestad (@bksa).
* '''opm-upscaling''': Arne Morten Kvarving (@akva2)
* '''ResInsight''': Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)

=== Jenkins information ===

[https://ci.opm-project.org Jenkins dashboard].

Information about [[Jenkins triggers]].

=== Nightly binary packages for Ubuntu and Red Hat ===

List of available [https://opm-project.org/package/ nightly images] generated by Jenkins. Note that in order to use the Ubuntu binaries you must add the PPA containing these nightly binaries:
# NOTE: you may need to sudo some of these apt commands!
# Add gpg key for repository
wget -qO - https://opm-project.org/package/nightly-bionic/repokey.gpg | apt-key add -
# Add repo itself
apt-add-repository https://opm-project.org/package/nightly-bionic
# Look at available nightly versions
apt-cache show libopm-simulators1-bin

=== Static analysis tools ===

Information about [[static analysis tools]] available.

=== Help for release managers ===

[[Notes for managing release 2016.10]]

=== Data required for output and restarting ===

[[Data for output and restart]]

= Viewing ECLIPSE summary files =
Resinsight provides a state-of-the art solution for all post-processing of reservoir simulation, including plotting functionality for summary files. In addition, there is the summary application within opm-common that extracts summary vectors directly on the command line.

== Through lightweight GUI ==
For those who like to keep clicking at a minimum, a lean plotting tool is found i qsummary. No binaries are available at the moment, so you will need to compile yourself from:
https://github.com/OPM/qsummary

== Through command-line ==
A command-line application named ''summary'' is distributed with OPM packages, and can be compiled from source in https://github.com/OPM/opm-common
It will give you direct access to any summary vectors, which subsequently can be handled through gnuplot, spreadsheet, or whatever you choose.

== Through Python script ==
The script is found in opm-utilities. The script in question is a Python script and some requirements must be satisifed:

<ol>
<li> You need the Python packages <tt>matplotlib</tt> and <tt>numpy</tt>.</li>
<li> You must compile/enable ERT Python packages when building ert. Then make sure that the path <tt>CMAKE_INSTALL_PREFIX/python</tt> is in your <tt>PYTHONPATH</tt>.
</ol>

When everything is installed the <tt>summaryplot</tt> application can be used, it can plot mulitple realisations:

<pre>
summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA
</pre>
[[File:Profile.png|border]]

== Plots ==
The full Norne model is run once a week, and PDF document with all the well results is generated: http://95.85.43.55/plots/

Main Page

2022-02-08T14:30:09Z

Alfbr:

= Getting started with OPM =

We have a [[Quick Installation]] guide, showing how to install the opm-core library.

The [[FPGA setup and building]] guide explains how to compile and use the ''bitstream'' for the FPGA-enabled Flow simulator.

The [//opm-project.org/?page_id=43 tutorials] section contain some tutorials for programmers using opm-core.

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

'''''Please note that the content of this wiki is in the process of being updated, many parts are not current!'''''

= User documentation for selected programs =
* [[Aquifer flow_onephase]]
* Black-oil reservoir flow:
** [[Black-oil simulator|Black-oil simulator]]
** [[Thermal simulator|Thermal simulator]]
** [[Water evaporation|Water evaporation]]
** [[Salt precipitation|Salt precipitation]]
* [[CO2 sequestration]]
* [[Enhanced oil recovery]]
* [[Geothermal flow_onephase_energy]]
* [[Upscaling]]

= Developer Information =

=== How to contribute ===

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on [//github.com/OPM github]. The process of contributing changes is the following:
* Fork the module for which you want to propose a change on github
* Locally create a new branch of the module's repository which contains your changes
* Push this branch to your personal github fork
* [https://help.github.com/articles/using-pull-requests Create a pull request]
* To make a pull request (PR) easy to review (and likely to be merged):
** A PR should contain a single feature, preferably with a unit test.
** It should not be too large. If you change lots of lines in lots of files in an automatic refactoring, show the script/commands you used.
** If you change existing code, do not mix feature changes and (large amounts of) pure formatting changes (use a separate PR for that).
** [http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Some more tips on PRs]
* After some discussion, one of the module maintainers will either merge your changes, or your changes will be rejected with an explanation why they are a bad idea.
* Often, you will be asked to make some modification to the code in the PR. Do this locally, and push the changes to the same repo and branch that you used for the PR. It will be updated automatically (as a corollary, do not use this branch for unrelated development -- start a new one instead).

=== Coding standard ===

We do not at the moment mandate a specific coding standard, but in practice we try to have a
homogenous code base, and encourage all contributors to follow certain practices.

These are listed in the [[Suggested coding standard]].

=== List of module maintainers ===

The current module maintainers (and their github user names) are:

* '''opm-common''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Arne Morten Kvarving (@akva2), Joakim Hove (@joakim-hove), Markus Blatt (@blattms)
* '''opm-material''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms) and Robert Klöfkorn (@dr-robertk)
* '''opm-models''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
* '''opm-tests''': Alf Birger Rustad (@alfbr), Torbjørn Skille (@tskille) and Bård Skaflestad (@bksa).
* '''opm-upscaling''': Arne Morten Kvarving (@akva2)
* '''ResInsight''': Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)

=== Jenkins information ===

[https://ci.opm-project.org Jenkins dashboard].

Information about [[Jenkins triggers]].

=== Nightly binary packages for Ubuntu and Red Hat ===

List of available [https://opm-project.org/package/ nightly images] generated by Jenkins. Note that in order to use the Ubuntu binaries you must add the PPA containing these nightly binaries:
# NOTE: you may need to sudo some of these apt commands!
# Add gpg key for repository
wget -qO - https://opm-project.org/package/nightly-bionic/repokey.gpg | apt-key add -
# Add repo itself
apt-add-repository https://opm-project.org/package/nightly-bionic
# Look at available nightly versions
apt-cache show libopm-simulators1-bin

=== Static analysis tools ===

Information about [[static analysis tools]] available.

=== Help for release managers ===

[[Notes for managing release 2016.10]]

=== Data required for output and restarting ===

[[Data for output and restart]]

= Viewing ECLIPSE summary files =
Resinsight provides a state-of-the art solution for all post-processing of reservoir simulation, including plotting functionality for summary files. In addition, there is the summary application within opm-common that extracts summary vectors directly on the command line.

== Through lightweight GUI ==
For those who like to keep clicking at a minimum, a lean plotting tool is found i qsummary. Now binaries are available at the moment, so you will need to compile yourself from:
https://github.com/OPM/qsummary

== Through command-line ==
A command-line application named ''summary'' is distributed with OPM packages, and can be compiled from source in https://github.com/OPM/opm-common
It will give you direct access to any summary vectors, which subsequently can be handled through gnuplot, spreadsheet, or whatever you choose.

== Through Python script ==
The script is found in opm-utilities. The script in question is a Python script and some requirements must be satisifed:

<ol>
<li> You need the Python packages <tt>matplotlib</tt> and <tt>numpy</tt>.</li>
<li> You must compile/enable ERT Python packages when building ert. Then make sure that the path <tt>CMAKE_INSTALL_PREFIX/python</tt> is in your <tt>PYTHONPATH</tt>.
</ol>

When everything is installed the <tt>summaryplot</tt> application can be used, it can plot mulitple realisations:

<pre>
summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA
</pre>
[[File:Profile.png|border]]

== Plots ==
The full Norne model is run once a week, and PDF document with all the well results is generated: http://95.85.43.55/plots/

Upscaling relative permeability in capillary limit

2021-05-03T08:56:55Z

Alfbr:

Upscale two-phase [http://en.wikipedia.org/wiki/Relative_permeability relative permeability] in the capillary limit for lithofacies models described by Eclipse [[corner point grid]]s

Each cell in the grid is populated with phase-permeabilities for either oil or water, for automatically chosen capillary pressure points, using porosity and permeability from the corner-point file, and using relative permeability curves for each rock type supplied on the command line.

The upscaled phase permeability is compared with already upscaled single-phase permeability in order to produce a value for relative permeability. The code automatically finds out (using a heuristic algorithm) which capillary pressure values are necessary in order to produce a sufficiently (adjustable) smooth relative permeability curve as a function of (also upscaled) water saturation.

Boundary conditions can be either fixed, periodic or linear, providing diagonal, symmetric or full permeability matrices respectively. By default, fixed boundary conditions are used.

Gravity can be included by specifying a non-zero gravitational acceleration, e.g 9.8 (unit: m/s²). If gravitation is non-zero, the densities of oil and water become relevant and can be adjusted.

Assumptions
* without gravity <math>(g = 0)</math>: Capillary equilibrium, the capillary pressure, <math>p_c</math>, is spatially invariant throughout the geometry
* with gravity <math>(g \neq 0)</math>: Capillary-gravitational equilibrium, the capillary pressure is spatially invariant in the horizontal direction and adjusted according to pressure changes due to gravity forces in the vertical direction

Oil-gas systems can also be modeled with this code, just replace water with gas, and leave oil as it is. Resulting curves should thus be interpreted as functions of gas saturation.

== Usage ==

The program can currently only be run from a Linux command line.

$ upscale_relperm <option> <eclipsefile> rock1.txt rock2.txt rock3.txt ...

If only one rock-file is supplied, that file is used for all stone types defined in the model. If more than one, it corresponds to the SATNUM-values in the model.

Typing <tt>upscale_relperm</tt> will output a list of options.

{| class=wikitable cellspacing=1 border=1
!align=left|Option
!align=left width=400pt|Description
!align=left|Default value
|-
| -bc
|Which boundary conditions to use. Possible values are p (periodic), f (fixed) or l (linear)
|f (fixed)
|-
| -points
|Number of pressure points/saturation points to upscale for within the saturation endpoints. These will be uniformly distributed.
|30
|-
| -upscaleBothPhases
|Whether to upscale both phases or not
|true
|-
| -relPermCurve
|if upscaleBothPhases is false and input is isotropic, this specifies the column number in the rock-files to be upscaled. Typically 2 (default) for water and 3 for oil.
|2
|-
| -jFunctionCurve
|if upscaleBothPhases is false and input is isotropic,the column number in the stone-files that represent the Leverett J-function.
|4
|-
| -gravity
|gravitational acceleration, in m/s². Use 9.8 for standard gravity.
|0
|-
| -fluids
|which two-phase fluid system we are dealing with. Possible values are ow (oil/water-system) and go (gas/oil-system)
|ow
|-
| -surfaceTension
|Surface tension in dynes/cm to use in J-function/Pc conversion. Contact angle is not supported, and <math>\cos \theta=1</math> is effectively used. If you need another contact angle, incorporate it into the value for surface tension.
|11
|-
| -waterDensity
|density of water, in g/cm³. Only relevant for non-zero gravity. If fluids is set to go (gas/oil), this should be set to density of gas.
|1.0
|-
| -oilDensity
|density of oil, in g/cm³. Only relevant for non-zero gravity.
|0.6
|-
| -output
|filename for where to write upscaled values. If not supplied, output will only go to the terminal (standard out). If upscaleBothPhases is true, this will also be the basename for SWOF and SGOF files for use in Eclipse
|none
|-
| -doEclipseCheck
|Check that input curves includes critical saturation points, i.e. saturation points where relperms are 0. See critRelpermThresh.
|true
|-
| -critRelpermThresh
|If minimum relperm value is less than this value, it is set to 0. Only applicable if doEclipseCheck is true.
|1e-6
|-
| -interpolate
|If this option is used, the outputted values will be interpolated values using the supplied number of points (integer larger than 0). Monotone cubic interpolation is used, and will thus produce a smooth curve for a few number of saturation points, and the interpolated curve will be more correct to the true curve occuring in nature. Default value is not do to interpolation, suggested value for interpolation is 1000.
|none
|}
(some more advanced options can be found in the source code)

Note: With gravity, the length unit, <math>l</math>, in the model matters. In the code, this is assumed to be

<math>\left[ l \right] = cm</math>

The contribution to capillary pressure from gravity forces is given by <math>\left(\rho_{water}-\rho_{oil}\right) g h</math> where <math>h</math> is the height of the cell relative to the models midpoint. Thus if the length unit in the grid file is not cm, this can be adjusted by a different value of g. Example: <math>\left[ l \right] = m \rightarrow g=981</math>

== Steps in the code==
# Process command line options
# Read Eclipse file
# Read relperm- and [http://en.wikipedia.org/wiki/Leverett_J-function J-function] for each stone type
# Tesselate the grid (Sintef code)
# If gravity is included, compute gravity pressure contributions in each cell:
## Compute height of model by averaging z-values of top layer corners
## Calculate density difference between phases in SI-units
## Go through each cell and find the z-values of the eight corners of the cell. Set height of cell equal to average of z-values of the corners minus half of model height to get the cell height relative to model centre. Set pressure difference for the cell equal to density difference times gravity constant times cell height times factor 10^-7 to obtain bars (same as p_c)
# Find minimum and maximum capillary pressure from the [http://en.wikipedia.org/wiki/Leverett_J-function J-functions] in each cell
# Upscale water saturation as a function of capillary pressure
# Upscale single phase permeability
# Upscale phase permeability for capillary pressures that corresponds to a uniform saturation grid, and compute relative permeability.
## Find capillary pressure point to compute for
## Find saturation and phase permeability in each cell
## Upscale phase permeability for given capillary pressure
# Print output to screen and optionally to file

== Source code ==
Input link when ready

==Example rock files==
The input rock files specify relative permeability and J-function/capillary pressure data for each rock type in the model. If the model (given in grdecl-file) has isotropic permeability (only PERMX keyword present in grid file), the rock files must be given on the isotropic permeability input format. If the grid file has anisotropic permeability (PERMX, PERMY and PERMZ present), the rock files must be given on the anisotropic permeability input format.

===Isotropic permeability input===
This format has four columns. In the oil/water case, these are water saturation, relative permeability of water, relative permeability of oil and J-function. In the gas/oil case these columns represent gas saturation, relative permeability of gas, relative permeability of oil and J-function.

-- Stone 1
-- Sw Krw Kro J-func
1.42000E-01 0.00000E+00 1.00000E+00 2.25999E+00
2.20750E-01 4.85459E-04 7.70612E-01 9.66057E-02
2.79250E-01 1.93652E-03 5.03619E-01 5.76122E-02
3.16950E-01 3.28976E-03 3.96987E-01 4.56517E-02
4.14850E-01 1.09648E-02 2.36036E-01 -1.23421E-02
5.17700E-01 2.32991E-02 1.07830E-01 -6.47660E-02
6.14150E-01 4.10007E-02 3.95006E-02 -8.96693E-02
6.84300E-01 8.71209E-02 1.62730E-02 -1.08905E-01
7.26100E-01 1.41398E-01 9.30808E-03 -1.19849E-01
8.15150E-01 4.40215E-01 1.91211E-03 -1.71342E-01
9.48000E-01 8.40000E-01 0.00000E+00 -1.42553E+00

===Anisotropic permeaility input===

The code supports anisotropic permeability, and detects this automatically if PERMY and PERMZ is present.

In this case, J-function scaling is meaningless, so the file format for input relative permeability curves necessarily changes.

Unit of Pc must be in Pascal.

# Pc (Pa) Sw Krwxx Krwyy Krwzz Kroxx Kroyy Krozz
2.571e+12 0.3211 8.510e-08 7.133e-08 8.632e-08 0.9986 0.9986 0.9986
1.297e+09 0.4496 0.001017 0.0001684 0.001101 0.4932 0.5238 0.4809
2.096e+08 0.5782 0.01272 0.004576 0.01337 0.09749 0.1002 0.09424
-4.082e+08 0.6853 0.05311 0.05610 0.05190 0.01239 0.003922 0.01303
-1.476e+09 0.7710 0.1382 0.1396 0.1330 0.002607 0.0003292 0.002809
-4.591e+09 0.8567 0.3123 0.3316 0.3048 0.0001882 4.986e-06 0.0002085
-4.319e+11 0.9424 0.5642 0.5522 0.5657 1.102e-12 6.606e-13 1.200e-12

==Output==

The program outputs the data on the same format as the anisotropic input format. If the option "output" is specyfied, the output is written to this file.

Also, if upscaleBothPhases is true, output meant for use in Eclipse simulations are made. If the "output" option is "myoutputfile.txt", then the corresponding Eclipse file would be named "myoutputfile-x.SWOF" for x-direction relperm in the oil/water case. In the oil/water case, the columns in this file is
Sw Krwxx Kroxx Pc
where Pc (capillary pressure) is given in bars.

In a gas/oil system, one can specify "krowxswirr", "krowyswirr" and "krowzswirr" to include the following line on top of each of the the tables (each direction correspondingly)
0 0 "krow*swirr" 0

The Eclipse output for a run may look like this
-- This file is based on the results in
-- myrun.txt
-- for relperm in x-direction.
-- Pressure values (Pc) given in bars.
-- Sw Krwxx Krowxx Pc(bar)
--SWOF
0.3100 0.000 0.9990 2.727e+07
0.4700 0.003321 0.5406 5.773e+06
0.6300 0.03033 0.03947 -1.889e+05
0.7900 0.2642 0.004677 -2.293e+06
0.9500 0.5900 0.000 -4.476e+06
/
Then, to combine relative permeability tables for several runs into one include file for Eclipse, one can do
cat rock1-x.SWOF rock2-x.SWOF rock3-x.SWOF > myEclipseCaseWith3RockTypes.SWOF
and then uncomment the first SWOF, i.e. replace the first occurance of "--SWOF" to "SWOF"

==Implementation notes==

The upscaling code only handles a limited permeability contrast (ratio of highest phase-permeability value to lowest value). High contrast ratios lead to numerical instability. Thus, this contrast is limited to 1e7. Given the highest phase-permeability for each pressure point/saturation point, the lowest permissible phase-permeability is computed, and all cells are ensured to have at least this minimum phase-permeability. Additionally, there is a fixed lower limit on phase permeability as well, it is never allowed to be less than 1e-12, as a value of zero renders the problem singular (these values can be adjusted by command line options).

Main Page

2021-03-23T08:13:15Z

Alfbr: /* Jenkins information */

= Getting started with OPM =

We have a [[Quick Installation]] guide, showing how to install the opm-core library.

The [[FPGA setup and building]] guide explains how to compile and use the ''bitstream'' for the FPGA-enabled Flow simulator.

The [//opm-project.org/?page_id=43 tutorials] section contain some tutorials for programmers using opm-core.

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

'''''Please note that the content of this wiki is in the process of being updated, many parts are not current!'''''

= User documentation for selected programs =
* [[Upscaling]]
* [[Black oil reservoir flow]]
* [[Enhanced oil recovery]]
* [[CO2 sequestration]]

= Developer Information =

=== How to contribute ===

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on [//github.com/OPM github]. The process of contributing changes is the following:
* Fork the module for which you want to propose a change on github
* Locally create a new branch of the module's repository which contains your changes
* Push this branch to your personal github fork
* [https://help.github.com/articles/using-pull-requests Create a pull request]
* To make a pull request (PR) easy to review (and likely to be merged):
** A PR should contain a single feature, preferably with a unit test.
** It should not be too large. If you change lots of lines in lots of files in an automatic refactoring, show the script/commands you used.
** If you change existing code, do not mix feature changes and (large amounts of) pure formatting changes (use a separate PR for that).
** [http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Some more tips on PRs]
* After some discussion, one of the module maintainers will either merge your changes, or your changes will be rejected with an explanation why they are a bad idea.
* Often, you will be asked to make some modification to the code in the PR. Do this locally, and push the changes to the same repo and branch that you used for the PR. It will be updated automatically (as a corollary, do not use this branch for unrelated development -- start a new one instead).

=== Coding standard ===

We do not at the moment mandate a specific coding standard, but in practice we try to have a
homogenous code base, and encourage all contributors to follow certain practices.

These are listed in the [[Suggested coding standard]].

=== List of module maintainers ===

The current module maintainers (and their github user names) are:

* '''opm-common''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Arne Morten Kvarving (@akva2), Joakim Hove (@joakim-hove), Markus Blatt (@blattms)
* '''opm-material''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms) and Robert Klöfkorn (@dr-robertk)
* '''opm-models''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
* '''opm-tests''': Alf Birger Rustad (@alfbr), Torbjørn Skille (@tskille) and Bård Skaflestad (@bksa).
* '''opm-upscaling''': Arne Morten Kvarving (@akva2)
* '''ResInsight''': Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)

=== Jenkins information ===

[https://ci.opm-project.org Jenkins dashboard].

Information about [[Jenkins triggers]].

=== Nightly binary packages for Ubuntu and Red Hat ===

List of available [https://opm-project.org/package/ nightly images] generated by Jenkins. Note that in order to use the Ubuntu binaries you must add the PPA containing these nightly binaries:
# NOTE: you may need to sudo some of these apt commands!
# Add gpg key for repository
wget -qO - https://opm-project.org/package/nightly-bionic/repokey.gpg | apt-key add -
# Add repo itself
apt-add-repository https://opm-project.org/package/nightly-bionic
# Look at available nightly versions
apt-cache show libopm-simulators1-bin

=== Static analysis tools ===

Information about [[static analysis tools]] available.

=== Help for release managers ===

[[Notes for managing release 2016.10]]

=== Data required for output and restarting ===

[[Data for output and restart]]

= Viewing ECLIPSE summary files =
Resinsight provides a state-of-the art solution for all post-processing of reservoir simulation, including plotting functionality for summary files. In addition, there is the summary application within opm-common that extracts summary vectors directly on the command line.

== Through Python script ==
Håvard Berland from Statoil has contributed a Python script which can be used to display graphical plots. The script is found in opm-utilities. The script in question is a Python script and some requirements must be satisifed:

<ol>
<li> You need the Python packages <tt>matplotlib</tt> and <tt>numpy</tt>.</li>
<li> You must compile/enable ERT Python packages when building ert. Then make sure that the path <tt>CMAKE_INSTALL_PREFIX/python</tt> is in your <tt>PYTHONPATH</tt>.
</ol>

When everything is installed the <tt>summaryplot</tt> application can be used, it can plot mulitple realisations:

<pre>
summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA
</pre>
[[File:Profile.png|border]]

== Plots ==
The full Norne model is run once a week, and PDF document with all the well results is generated: http://95.85.43.55/plots/

Main Page

2021-03-23T08:06:55Z

Alfbr: /* Jenkins information */

= Getting started with OPM =

We have a [[Quick Installation]] guide, showing how to install the opm-core library.

The [[FPGA setup and building]] guide explains how to compile and use the ''bitstream'' for the FPGA-enabled Flow simulator.

The [//opm-project.org/?page_id=43 tutorials] section contain some tutorials for programmers using opm-core.

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

'''''Please note that the content of this wiki is in the process of being updated, many parts are not current!'''''

= User documentation for selected programs =
* [[Upscaling]]
* [[Black oil reservoir flow]]
* [[Enhanced oil recovery]]
* [[CO2 sequestration]]

= Developer Information =

=== How to contribute ===

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on [//github.com/OPM github]. The process of contributing changes is the following:
* Fork the module for which you want to propose a change on github
* Locally create a new branch of the module's repository which contains your changes
* Push this branch to your personal github fork
* [https://help.github.com/articles/using-pull-requests Create a pull request]
* To make a pull request (PR) easy to review (and likely to be merged):
** A PR should contain a single feature, preferably with a unit test.
** It should not be too large. If you change lots of lines in lots of files in an automatic refactoring, show the script/commands you used.
** If you change existing code, do not mix feature changes and (large amounts of) pure formatting changes (use a separate PR for that).
** [http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Some more tips on PRs]
* After some discussion, one of the module maintainers will either merge your changes, or your changes will be rejected with an explanation why they are a bad idea.
* Often, you will be asked to make some modification to the code in the PR. Do this locally, and push the changes to the same repo and branch that you used for the PR. It will be updated automatically (as a corollary, do not use this branch for unrelated development -- start a new one instead).

=== Coding standard ===

We do not at the moment mandate a specific coding standard, but in practice we try to have a
homogenous code base, and encourage all contributors to follow certain practices.

These are listed in the [[Suggested coding standard]].

=== List of module maintainers ===

The current module maintainers (and their github user names) are:

* '''opm-common''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Arne Morten Kvarving (@akva2), Joakim Hove (@joakim-hove), Markus Blatt (@blattms)
* '''opm-material''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms) and Robert Klöfkorn (@dr-robertk)
* '''opm-models''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
* '''opm-tests''': Alf Birger Rustad (@alfbr), Torbjørn Skille (@tskille) and Bård Skaflestad (@bksa).
* '''opm-upscaling''': Arne Morten Kvarving (@akva2)
* '''ResInsight''': Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)

=== Jenkins information ===

[https://ci.opm-project.org Jenkins dashboard].

Information about [[Jenkins triggers]].

List of available [https://opm-project.org/package/ nightly images] generated by Jenkins. Note that in order to use it you must add the PPA containing these nightly binaries:
# NOTE: you may need to sudo some of these apt commands!
# Add gpg key for repository
wget -qO - https://opm-project.org/package/nightly-bionic/repokey.gpg | apt-key add -
# Add repo itself
apt-add-repository https://opm-project.org/package/nightly-bionic
# Look at available nightly versions
apt-cache show libopm-simulators1-bin

=== Static analysis tools ===

Information about [[static analysis tools]] available.

=== Help for release managers ===

[[Notes for managing release 2016.10]]

=== Data required for output and restarting ===

[[Data for output and restart]]

= Viewing ECLIPSE summary files =
Resinsight provides a state-of-the art solution for all post-processing of reservoir simulation, including plotting functionality for summary files. In addition, there is the summary application within opm-common that extracts summary vectors directly on the command line.

== Through Python script ==
Håvard Berland from Statoil has contributed a Python script which can be used to display graphical plots. The script is found in opm-utilities. The script in question is a Python script and some requirements must be satisifed:

<ol>
<li> You need the Python packages <tt>matplotlib</tt> and <tt>numpy</tt>.</li>
<li> You must compile/enable ERT Python packages when building ert. Then make sure that the path <tt>CMAKE_INSTALL_PREFIX/python</tt> is in your <tt>PYTHONPATH</tt>.
</ol>

When everything is installed the <tt>summaryplot</tt> application can be used, it can plot mulitple realisations:

<pre>
summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA
</pre>
[[File:Profile.png|border]]

== Plots ==
The full Norne model is run once a week, and PDF document with all the well results is generated: http://95.85.43.55/plots/

Main Page

2021-03-23T08:03:23Z

Alfbr: /* Jenkins information */

= Getting started with OPM =

We have a [[Quick Installation]] guide, showing how to install the opm-core library.

The [[FPGA setup and building]] guide explains how to compile and use the ''bitstream'' for the FPGA-enabled Flow simulator.

The [//opm-project.org/?page_id=43 tutorials] section contain some tutorials for programmers using opm-core.

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

'''''Please note that the content of this wiki is in the process of being updated, many parts are not current!'''''

= User documentation for selected programs =
* [[Upscaling]]
* [[Black oil reservoir flow]]
* [[Enhanced oil recovery]]
* [[CO2 sequestration]]

= Developer Information =

=== How to contribute ===

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on [//github.com/OPM github]. The process of contributing changes is the following:
* Fork the module for which you want to propose a change on github
* Locally create a new branch of the module's repository which contains your changes
* Push this branch to your personal github fork
* [https://help.github.com/articles/using-pull-requests Create a pull request]
* To make a pull request (PR) easy to review (and likely to be merged):
** A PR should contain a single feature, preferably with a unit test.
** It should not be too large. If you change lots of lines in lots of files in an automatic refactoring, show the script/commands you used.
** If you change existing code, do not mix feature changes and (large amounts of) pure formatting changes (use a separate PR for that).
** [http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Some more tips on PRs]
* After some discussion, one of the module maintainers will either merge your changes, or your changes will be rejected with an explanation why they are a bad idea.
* Often, you will be asked to make some modification to the code in the PR. Do this locally, and push the changes to the same repo and branch that you used for the PR. It will be updated automatically (as a corollary, do not use this branch for unrelated development -- start a new one instead).

=== Coding standard ===

We do not at the moment mandate a specific coding standard, but in practice we try to have a
homogenous code base, and encourage all contributors to follow certain practices.

These are listed in the [[Suggested coding standard]].

=== List of module maintainers ===

The current module maintainers (and their github user names) are:

* '''opm-common''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Arne Morten Kvarving (@akva2), Joakim Hove (@joakim-hove), Markus Blatt (@blattms)
* '''opm-material''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms) and Robert Klöfkorn (@dr-robertk)
* '''opm-models''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
* '''opm-tests''': Alf Birger Rustad (@alfbr), Torbjørn Skille (@tskille) and Bård Skaflestad (@bksa).
* '''opm-upscaling''': Arne Morten Kvarving (@akva2)
* '''ResInsight''': Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)

=== Jenkins information ===

[https://ci.opm-project.org Jenkins dashboard].

Information about [[Jenkins triggers]].

List of available [https://opm-project.org/package/ nightly images] generated by Jenkins. Note that in order to use it you must add the PPA containing these nightly binaries:
# NOTE: you may need to sudo some of these apt commands!
# Add gpg key for repository
wget -qO - https://opm-project.org/package/nightly-xenial/repokey.gpg | apt-key add -
# Add repo itself
apt-add-repository https://opm-project.org/package/nightly-xenial
# Look at available nightly versions
apt-cache show libopm-simulators1-bin

=== Static analysis tools ===

Information about [[static analysis tools]] available.

=== Help for release managers ===

[[Notes for managing release 2016.10]]

=== Data required for output and restarting ===

[[Data for output and restart]]

= Viewing ECLIPSE summary files =
Resinsight provides a state-of-the art solution for all post-processing of reservoir simulation, including plotting functionality for summary files. In addition, there is the summary application within opm-common that extracts summary vectors directly on the command line.

== Through Python script ==
Håvard Berland from Statoil has contributed a Python script which can be used to display graphical plots. The script is found in opm-utilities. The script in question is a Python script and some requirements must be satisifed:

<ol>
<li> You need the Python packages <tt>matplotlib</tt> and <tt>numpy</tt>.</li>
<li> You must compile/enable ERT Python packages when building ert. Then make sure that the path <tt>CMAKE_INSTALL_PREFIX/python</tt> is in your <tt>PYTHONPATH</tt>.
</ol>

When everything is installed the <tt>summaryplot</tt> application can be used, it can plot mulitple realisations:

<pre>
summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA
</pre>
[[File:Profile.png|border]]

== Plots ==
The full Norne model is run once a week, and PDF document with all the well results is generated: http://95.85.43.55/plots/

Main Page

2021-03-23T08:02:19Z

Alfbr: /* List of module maintainers */

= Getting started with OPM =

We have a [[Quick Installation]] guide, showing how to install the opm-core library.

The [[FPGA setup and building]] guide explains how to compile and use the ''bitstream'' for the FPGA-enabled Flow simulator.

The [//opm-project.org/?page_id=43 tutorials] section contain some tutorials for programmers using opm-core.

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

'''''Please note that the content of this wiki is in the process of being updated, many parts are not current!'''''

= User documentation for selected programs =
* [[Upscaling]]
* [[Black oil reservoir flow]]
* [[Enhanced oil recovery]]
* [[CO2 sequestration]]

= Developer Information =

=== How to contribute ===

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on [//github.com/OPM github]. The process of contributing changes is the following:
* Fork the module for which you want to propose a change on github
* Locally create a new branch of the module's repository which contains your changes
* Push this branch to your personal github fork
* [https://help.github.com/articles/using-pull-requests Create a pull request]
* To make a pull request (PR) easy to review (and likely to be merged):
** A PR should contain a single feature, preferably with a unit test.
** It should not be too large. If you change lots of lines in lots of files in an automatic refactoring, show the script/commands you used.
** If you change existing code, do not mix feature changes and (large amounts of) pure formatting changes (use a separate PR for that).
** [http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Some more tips on PRs]
* After some discussion, one of the module maintainers will either merge your changes, or your changes will be rejected with an explanation why they are a bad idea.
* Often, you will be asked to make some modification to the code in the PR. Do this locally, and push the changes to the same repo and branch that you used for the PR. It will be updated automatically (as a corollary, do not use this branch for unrelated development -- start a new one instead).

=== Coding standard ===

We do not at the moment mandate a specific coding standard, but in practice we try to have a
homogenous code base, and encourage all contributors to follow certain practices.

These are listed in the [[Suggested coding standard]].

=== List of module maintainers ===

The current module maintainers (and their github user names) are:

* '''opm-common''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Arne Morten Kvarving (@akva2), Joakim Hove (@joakim-hove), Markus Blatt (@blattms)
* '''opm-material''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms) and Robert Klöfkorn (@dr-robertk)
* '''opm-models''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
* '''opm-tests''': Alf Birger Rustad (@alfbr), Torbjørn Skille (@tskille) and Bård Skaflestad (@bksa).
* '''opm-upscaling''': Arne Morten Kvarving (@akva2)
* '''ResInsight''': Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)

=== Jenkins information ===

[https://ci.opm-project.org Jenkins dashboard].

Information about [[Jenkins triggers]].

List of available [https://opm-project.org/package/nightly-xenial/pool/main/o/opm-simulators/ nightly images] generated by Jenkins. Note that in order to use it you must add the PPA containing these nightly binaries:
# NOTE: you may need to sudo some of these apt commands!
# Add gpg key for repository
wget -qO - https://opm-project.org/package/nightly-xenial/repokey.gpg | apt-key add -
# Add repo itself
apt-add-repository https://opm-project.org/package/nightly-xenial
# Look at available nightly versions
apt-cache show libopm-simulators1-bin

=== Static analysis tools ===

Information about [[static analysis tools]] available.

=== Help for release managers ===

[[Notes for managing release 2016.10]]

=== Data required for output and restarting ===

[[Data for output and restart]]

= Viewing ECLIPSE summary files =
Resinsight provides a state-of-the art solution for all post-processing of reservoir simulation, including plotting functionality for summary files. In addition, there is the summary application within opm-common that extracts summary vectors directly on the command line.

== Through Python script ==
Håvard Berland from Statoil has contributed a Python script which can be used to display graphical plots. The script is found in opm-utilities. The script in question is a Python script and some requirements must be satisifed:

<ol>
<li> You need the Python packages <tt>matplotlib</tt> and <tt>numpy</tt>.</li>
<li> You must compile/enable ERT Python packages when building ert. Then make sure that the path <tt>CMAKE_INSTALL_PREFIX/python</tt> is in your <tt>PYTHONPATH</tt>.
</ol>

When everything is installed the <tt>summaryplot</tt> application can be used, it can plot mulitple realisations:

<pre>
summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA
</pre>
[[File:Profile.png|border]]

== Plots ==
The full Norne model is run once a week, and PDF document with all the well results is generated: http://95.85.43.55/plots/

Main Page

2021-03-23T08:01:57Z

Alfbr: /* List of module maintainers */

= Getting started with OPM =

We have a [[Quick Installation]] guide, showing how to install the opm-core library.

The [[FPGA setup and building]] guide explains how to compile and use the ''bitstream'' for the FPGA-enabled Flow simulator.

The [//opm-project.org/?page_id=43 tutorials] section contain some tutorials for programmers using opm-core.

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

'''''Please note that the content of this wiki is in the process of being updated, many parts are not current!'''''

= User documentation for selected programs =
* [[Upscaling]]
* [[Black oil reservoir flow]]
* [[Enhanced oil recovery]]
* [[CO2 sequestration]]

= Developer Information =

=== How to contribute ===

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on [//github.com/OPM github]. The process of contributing changes is the following:
* Fork the module for which you want to propose a change on github
* Locally create a new branch of the module's repository which contains your changes
* Push this branch to your personal github fork
* [https://help.github.com/articles/using-pull-requests Create a pull request]
* To make a pull request (PR) easy to review (and likely to be merged):
** A PR should contain a single feature, preferably with a unit test.
** It should not be too large. If you change lots of lines in lots of files in an automatic refactoring, show the script/commands you used.
** If you change existing code, do not mix feature changes and (large amounts of) pure formatting changes (use a separate PR for that).
** [http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Some more tips on PRs]
* After some discussion, one of the module maintainers will either merge your changes, or your changes will be rejected with an explanation why they are a bad idea.
* Often, you will be asked to make some modification to the code in the PR. Do this locally, and push the changes to the same repo and branch that you used for the PR. It will be updated automatically (as a corollary, do not use this branch for unrelated development -- start a new one instead).

=== Coding standard ===

We do not at the moment mandate a specific coding standard, but in practice we try to have a
homogenous code base, and encourage all contributors to follow certain practices.

These are listed in the [[Suggested coding standard]].

=== List of module maintainers ===

The current module maintainers (and their github user names) are:

* '''opm-common''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Arne Morten Kvarving (@akva2), Joakim Hove (@joakim-hove), Markus Blatt (@blattms)
* '''opm-material''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms) and Robert Klöfkorn (@dr-robertk)
* '''opm-models''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
* '''opm-tests''': Alf Birger Rustad (@alfbr), Torbjørn Skille (@tskille] and Bård Skaflestad (@bksa).
* '''opm-upscaling''': Arne Morten Kvarving (@akva2)
* '''ResInsight''': Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)

=== Jenkins information ===

[https://ci.opm-project.org Jenkins dashboard].

Information about [[Jenkins triggers]].

List of available [https://opm-project.org/package/nightly-xenial/pool/main/o/opm-simulators/ nightly images] generated by Jenkins. Note that in order to use it you must add the PPA containing these nightly binaries:
# NOTE: you may need to sudo some of these apt commands!
# Add gpg key for repository
wget -qO - https://opm-project.org/package/nightly-xenial/repokey.gpg | apt-key add -
# Add repo itself
apt-add-repository https://opm-project.org/package/nightly-xenial
# Look at available nightly versions
apt-cache show libopm-simulators1-bin

=== Static analysis tools ===

Information about [[static analysis tools]] available.

=== Help for release managers ===

[[Notes for managing release 2016.10]]

=== Data required for output and restarting ===

[[Data for output and restart]]

= Viewing ECLIPSE summary files =
Resinsight provides a state-of-the art solution for all post-processing of reservoir simulation, including plotting functionality for summary files. In addition, there is the summary application within opm-common that extracts summary vectors directly on the command line.

== Through Python script ==
Håvard Berland from Statoil has contributed a Python script which can be used to display graphical plots. The script is found in opm-utilities. The script in question is a Python script and some requirements must be satisifed:

<ol>
<li> You need the Python packages <tt>matplotlib</tt> and <tt>numpy</tt>.</li>
<li> You must compile/enable ERT Python packages when building ert. Then make sure that the path <tt>CMAKE_INSTALL_PREFIX/python</tt> is in your <tt>PYTHONPATH</tt>.
</ol>

When everything is installed the <tt>summaryplot</tt> application can be used, it can plot mulitple realisations:

<pre>
summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA
</pre>
[[File:Profile.png|border]]

== Plots ==
The full Norne model is run once a week, and PDF document with all the well results is generated: http://95.85.43.55/plots/

User talk:Gmarchiori

2021-01-19T13:48:34Z

Alfbr: Welcome!

'''Welcome to ''opm''!'''
We hope you will contribute much and well.
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].
Again, welcome and have fun! [[User:Alfbr|Alfbr]] ([[User talk:Alfbr|talk]]) 13:48, 19 January 2021 (UTC)

Main Page

2020-11-09T17:27:14Z

Alfbr: /* Plots */

= Getting started with OPM =

We have a [[Quick Installation]] guide, showing how to install the opm-core library.

The [//opm-project.org/?page_id=43 tutorials] section contain some tutorials for programmers using opm-core.

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

'''''Please note that the content of this wiki is in the process of being updated, many parts are not current!'''''

= User documentation for selected programs =
* [[Upscaling]]
* [[Black oil reservoir flow]]
* [[Enhanced oil recovery]]
* [[CO2 sequestration]]

= Developer Information =

=== How to contribute ===

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on [//github.com/OPM github]. The process of contributing changes is the following:
* Fork the module for which you want to propose a change on github
* Locally create a new branch of the module's repository which contains your changes
* Push this branch to your personal github fork
* [https://help.github.com/articles/using-pull-requests Create a pull request]
* To make a pull request (PR) easy to review (and likely to be merged):
** A PR should contain a single feature, preferably with a unit test.
** It should not be too large. If you change lots of lines in lots of files in an automatic refactoring, show the script/commands you used.
** If you change existing code, do not mix feature changes and (large amounts of) pure formatting changes (use a separate PR for that).
** [http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Some more tips on PRs]
* After some discussion, one of the module maintainers will either merge your changes, or your changes will be rejected with an explanation why they are a bad idea.
* Often, you will be asked to make some modification to the code in the PR. Do this locally, and push the changes to the same repo and branch that you used for the PR. It will be updated automatically (as a corollary, do not use this branch for unrelated development -- start a new one instead).

=== Coding standard ===

We do not at the moment mandate a specific coding standard, but in practice we try to have a
homogenous code base, and encourage all contributors to follow certain practices.

These are listed in the [[Suggested coding standard]].

=== List of module maintainers ===

The current module maintainers (and their github user names) are:

* '''opm-common''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Arne Morten Kvarving (@akva2), Joakim Hove (@joakim-hove), Markus Blatt (@blattms)
* '''opm-material''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms) and Robert Klöfkorn (@dr-robertk)
* '''opm-models''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
* '''opm-tests''': Alf Birger Rustad (@alfbr)
* '''opm-upscaling''': Arne Morten Kvarving (@akva2)
* '''ResInsight''': Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)

=== Jenkins information ===

[https://ci.opm-project.org Jenkins dashboard].

Information about [[Jenkins triggers]].

List of available [https://opm-project.org/package/nightly-xenial/pool/main/o/opm-simulators/ nightly images] generated by Jenkins. Note that in order to use it you must add the PPA containing these nightly binaries:
# NOTE: you may need to sudo some of these apt commands!
# Add gpg key for repository
wget -qO - https://opm-project.org/package/nightly-xenial/repokey.gpg | apt-key add -
# Add repo itself
apt-add-repository https://opm-project.org/package/nightly-xenial
# Look at available nightly versions
apt-cache show libopm-simulators1-bin

=== Static analysis tools ===

Information about [[static analysis tools]] available.

=== Help for release managers ===

[[Notes for managing release 2016.10]]

=== Data required for output and restarting ===

[[Data for output and restart]]

= Viewing ECLIPSE summary files =
Resinsight provides a state-of-the art solution for all post-processing of reservoir simulation, including plotting functionality for summary files. In addition, there is the summary application within opm-common that extracts summary vectors directly on the command line.

== Through Python script ==
Håvard Berland from Statoil has contributed a Python script which can be used to display graphical plots. The script is found in opm-utilities. The script in question is a Python script and some requirements must be satisifed:

<ol>
<li> You need the Python packages <tt>matplotlib</tt> and <tt>numpy</tt>.</li>
<li> You must compile/enable ERT Python packages when building ert. Then make sure that the path <tt>CMAKE_INSTALL_PREFIX/python</tt> is in your <tt>PYTHONPATH</tt>.
</ol>

When everything is installed the <tt>summaryplot</tt> application can be used, it can plot mulitple realisations:

<pre>
summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA
</pre>
[[File:Profile.png|border]]

== Plots ==
The full Norne model is run once a week, and PDF document with all the well results is generated: http://95.85.43.55/plots/

Main Page

2020-11-09T17:26:38Z

Alfbr: /* Internal stuff */

= Getting started with OPM =

We have a [[Quick Installation]] guide, showing how to install the opm-core library.

The [//opm-project.org/?page_id=43 tutorials] section contain some tutorials for programmers using opm-core.

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

'''''Please note that the content of this wiki is in the process of being updated, many parts are not current!'''''

= User documentation for selected programs =
* [[Upscaling]]
* [[Black oil reservoir flow]]
* [[Enhanced oil recovery]]
* [[CO2 sequestration]]

= Developer Information =

=== How to contribute ===

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on [//github.com/OPM github]. The process of contributing changes is the following:
* Fork the module for which you want to propose a change on github
* Locally create a new branch of the module's repository which contains your changes
* Push this branch to your personal github fork
* [https://help.github.com/articles/using-pull-requests Create a pull request]
* To make a pull request (PR) easy to review (and likely to be merged):
** A PR should contain a single feature, preferably with a unit test.
** It should not be too large. If you change lots of lines in lots of files in an automatic refactoring, show the script/commands you used.
** If you change existing code, do not mix feature changes and (large amounts of) pure formatting changes (use a separate PR for that).
** [http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Some more tips on PRs]
* After some discussion, one of the module maintainers will either merge your changes, or your changes will be rejected with an explanation why they are a bad idea.
* Often, you will be asked to make some modification to the code in the PR. Do this locally, and push the changes to the same repo and branch that you used for the PR. It will be updated automatically (as a corollary, do not use this branch for unrelated development -- start a new one instead).

=== Coding standard ===

We do not at the moment mandate a specific coding standard, but in practice we try to have a
homogenous code base, and encourage all contributors to follow certain practices.

These are listed in the [[Suggested coding standard]].

=== List of module maintainers ===

The current module maintainers (and their github user names) are:

* '''opm-common''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Arne Morten Kvarving (@akva2), Joakim Hove (@joakim-hove), Markus Blatt (@blattms)
* '''opm-material''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms) and Robert Klöfkorn (@dr-robertk)
* '''opm-models''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
* '''opm-tests''': Alf Birger Rustad (@alfbr)
* '''opm-upscaling''': Arne Morten Kvarving (@akva2)
* '''ResInsight''': Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)

=== Jenkins information ===

[https://ci.opm-project.org Jenkins dashboard].

Information about [[Jenkins triggers]].

List of available [https://opm-project.org/package/nightly-xenial/pool/main/o/opm-simulators/ nightly images] generated by Jenkins. Note that in order to use it you must add the PPA containing these nightly binaries:
# NOTE: you may need to sudo some of these apt commands!
# Add gpg key for repository
wget -qO - https://opm-project.org/package/nightly-xenial/repokey.gpg | apt-key add -
# Add repo itself
apt-add-repository https://opm-project.org/package/nightly-xenial
# Look at available nightly versions
apt-cache show libopm-simulators1-bin

=== Static analysis tools ===

Information about [[static analysis tools]] available.

=== Help for release managers ===

[[Notes for managing release 2016.10]]

=== Data required for output and restarting ===

[[Data for output and restart]]

= Viewing ECLIPSE summary files =
Resinsight provides a state-of-the art solution for all post-processing of reservoir simulation, including plotting functionality for summary files. In addition, there is the summary application within opm-common that extracts summary vectors directly on the command line.

== Through Python script ==
Håvard Berland from Statoil has contributed a Python script which can be used to display graphical plots. The script is found in opm-utilities. The script in question is a Python script and some requirements must be satisifed:

<ol>
<li> You need the Python packages <tt>matplotlib</tt> and <tt>numpy</tt>.</li>
<li> You must compile/enable ERT Python packages when building ert. Then make sure that the path <tt>CMAKE_INSTALL_PREFIX/python</tt> is in your <tt>PYTHONPATH</tt>.
</ol>

When everything is installed the <tt>summaryplot</tt> application can be used, it can plot mulitple realisations:

<pre>
summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA
</pre>
[[File:Profile.png|border]]

= Plots =
The full Norne model is run once a week, and PDF document with all the well results is generated: http://95.85.43.55/plots/

Main Page

2020-11-09T17:26:20Z

Alfbr: /* Viewing ECLIPSE summary files */

= Getting started with OPM =

We have a [[Quick Installation]] guide, showing how to install the opm-core library.

The [//opm-project.org/?page_id=43 tutorials] section contain some tutorials for programmers using opm-core.

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

'''''Please note that the content of this wiki is in the process of being updated, many parts are not current!'''''

= User documentation for selected programs =
* [[Upscaling]]
* [[Black oil reservoir flow]]
* [[Enhanced oil recovery]]
* [[CO2 sequestration]]

= Developer Information =

=== How to contribute ===

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on [//github.com/OPM github]. The process of contributing changes is the following:
* Fork the module for which you want to propose a change on github
* Locally create a new branch of the module's repository which contains your changes
* Push this branch to your personal github fork
* [https://help.github.com/articles/using-pull-requests Create a pull request]
* To make a pull request (PR) easy to review (and likely to be merged):
** A PR should contain a single feature, preferably with a unit test.
** It should not be too large. If you change lots of lines in lots of files in an automatic refactoring, show the script/commands you used.
** If you change existing code, do not mix feature changes and (large amounts of) pure formatting changes (use a separate PR for that).
** [http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Some more tips on PRs]
* After some discussion, one of the module maintainers will either merge your changes, or your changes will be rejected with an explanation why they are a bad idea.
* Often, you will be asked to make some modification to the code in the PR. Do this locally, and push the changes to the same repo and branch that you used for the PR. It will be updated automatically (as a corollary, do not use this branch for unrelated development -- start a new one instead).

=== Coding standard ===

We do not at the moment mandate a specific coding standard, but in practice we try to have a
homogenous code base, and encourage all contributors to follow certain practices.

These are listed in the [[Suggested coding standard]].

=== List of module maintainers ===

The current module maintainers (and their github user names) are:

* '''opm-common''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Arne Morten Kvarving (@akva2), Joakim Hove (@joakim-hove), Markus Blatt (@blattms)
* '''opm-material''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms) and Robert Klöfkorn (@dr-robertk)
* '''opm-models''': Tor Harald Sandve (@totto82), Atgeirr Rasmussen (@atgeirr)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
* '''opm-tests''': Alf Birger Rustad (@alfbr)
* '''opm-upscaling''': Arne Morten Kvarving (@akva2)
* '''ResInsight''': Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)

=== Jenkins information ===

[https://ci.opm-project.org Jenkins dashboard].

Information about [[Jenkins triggers]].

List of available [https://opm-project.org/package/nightly-xenial/pool/main/o/opm-simulators/ nightly images] generated by Jenkins. Note that in order to use it you must add the PPA containing these nightly binaries:
# NOTE: you may need to sudo some of these apt commands!
# Add gpg key for repository
wget -qO - https://opm-project.org/package/nightly-xenial/repokey.gpg | apt-key add -
# Add repo itself
apt-add-repository https://opm-project.org/package/nightly-xenial
# Look at available nightly versions
apt-cache show libopm-simulators1-bin

=== Static analysis tools ===

Information about [[static analysis tools]] available.

=== Help for release managers ===

[[Notes for managing release 2016.10]]

=== Data required for output and restarting ===

[[Data for output and restart]]

= Viewing ECLIPSE summary files =
Resinsight provides a state-of-the art solution for all post-processing of reservoir simulation, including plotting functionality for summary files. In addition, there is the summary application within opm-common that extracts summary vectors directly on the command line.

== Through Python script ==
Håvard Berland from Statoil has contributed a Python script which can be used to display graphical plots. The script is found in opm-utilities. The script in question is a Python script and some requirements must be satisifed:

<ol>
<li> You need the Python packages <tt>matplotlib</tt> and <tt>numpy</tt>.</li>
<li> You must compile/enable ERT Python packages when building ert. Then make sure that the path <tt>CMAKE_INSTALL_PREFIX/python</tt> is in your <tt>PYTHONPATH</tt>.
</ol>

When everything is installed the <tt>summaryplot</tt> application can be used, it can plot mulitple realisations:

<pre>
summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA
</pre>
[[File:Profile.png|border]]

= Internal stuff =
This section contains links to topic mostly of interest to active OPM developers.
<ol>
<li> Module reorganization: [[ OPM_reorg_2015]] </li>
<li> Tasks required for 2015 field case: [[ Tasks_for_new_case_2015 ]] </li>
<li> [[ 2020 group control effort ]]</li>
</ol>

= Plots =
The full Norne model is run once a week, and PDF document with all the well results is generated: http://95.85.43.55/plots/