opm - User contributions [en]

Thermal simulator

2021-05-06T08:45:50Z

Cintiamachado:

Thermal flow is a fully-implicit thermal simulator with a black-oil formulation.

Reported temperature of a producer is a weighted sum of the well blocks' temperatures by the energy rate density of each phase.

Thermal simulator

2021-05-06T08:45:08Z

Cintiamachado:

Thermal simulator

2021-05-06T08:05:37Z

Cintiamachado:

Thermal simulator

2021-05-06T08:01:53Z

Cintiamachado: Created page with "Thermal flow is a fully-implicit thermal simulator with a black-oil formulation."

Thermal flow is a fully-implicit thermal simulator with a black-oil formulation.

Main Page

2021-05-06T08:00:25Z

Cintiamachado: /* 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 =
* [[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 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/

Black-oil reservoir flow

2021-05-06T07:59:01Z

Cintiamachado: /* Black-oil reservoir simulators */

Main Page

2021-05-06T07:58:16Z

Cintiamachado: /* 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 =
* [[Aquifer flow_onephase]]
* [[Black-oil reservoir flow]]
** [[Black-oil simulator|Black-oil simulator]]
** [[Thermal simulator|Thermal reservoir 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 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-05-06T07:55:24Z

Cintiamachado: /* 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 =
* [[Aquifer flow_onephase]]
* [[Black-oil reservoir flow]]
* [[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 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/

Black-oil reservoir flow

2021-05-06T07:52:55Z

Cintiamachado: Created page with "=Black-oil reservoir simulators= * Black-oil simulator * Thermal reservoir simulator * Water evaporation *..."

=Black-oil reservoir simulators=
* [[Black-oil simulator|Black-oil simulator]]
* [[Thermal simulator|Thermal reservoir simulator]]
* [[Water evaporation|Water evaporation]]
* [[Salt precipitation|Salt precipitation]]

Main Page

2021-05-06T07:49:41Z

Cintiamachado: /* 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 =
* [[Aquifer flow]]
* [[Black-oil reservoir flow]]
* [[CO2 sequestration]]
* [[Enhanced oil recovery]]
* [[Geothermal flow]]
* [[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 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/

Black oil reservoir flow

2021-05-06T07:46:03Z

Cintiamachado: /* Available black oil reservoir flow programs */

=Available black oil reservoir flow programs=
* [[Black oil simulator|Black oil simulator]]

Black oil reservoir flow

2021-05-06T07:45:11Z

Cintiamachado: /* Available black oil reservoir flow programs */

=Available black oil reservoir flow programs=
* [[Black oil simulator|Black oil simulator]]
* [[Thermal simulator|Thermal simulator]]
* [[Water evaporation|Water evaporation]]
* [[Salt precipitation|Salt precipitation]]

Main Page

2021-05-06T07:44:04Z

Cintiamachado: /* 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 flow]]
* [[CO2 sequestration]]
* [[Enhanced oil recovery]]
* [[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 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/

Corner point grid

2020-11-12T20:33:32Z

Cintiamachado:

:''See also [http://en.wikipedia.org/wiki/Corner-point_grid Wikipedias page on corner-point grids]''

The dune-cornerpoint module provides an interface to dune-grid.

Corner-point grid is a grid format for 3D-geometries. The grid format is sometimes referred to as a pillar grid, because it is based on a set of pillars/coordinate lines running from the top to the bottom of the model. Grid cells are defined by eight corners/nodes which lay pairwise on four neighbouring pillars. The corners of neighbouring grid blocks are specified independently, enabling the specification of grids with faults and gaps. Cornerpoint grids can be read by most reservoir simulators.

The grid blocks in a corner-point grid is ordered in a logically Cartesian fashion. Each grid block is indexed by an <math>ijk</math>-triplet, where the integers <math>i</math>, <math>j</math>, and <math>k</math> are associated with the three spatial dimmensions <math>x</math>, <math>y</math>, and <math>z</math>, respectively. Therefore, a corner-point grid relates to three coordinate systems; the logical (integer <math>i</math>,<math>j</math>,<math>k</math> indicies), the local (<math>x</math>,<math>y</math>,<math>z</math> coordinates), and the global (<math>x</math>,<math>y</math>,<math>z</math> coordinates) coordinate system. The positive <math>z</math> direction is always downwards (depth). Properties in the grid are specified with the <math>i</math>-index varying fastest, then <math>j</math>, and finally <math>k</math>.

For the corner-point grids non-neighboring connections are supported, meaning that grid blocks that are not neighboring in <math>ijk</math>-space can be defined as neighboring. This feature allows for representation of faults with significant throws.

== Keywords specifying grid ==

In the ECLIPSE implementation, which is the "standard", the grid is defined by the following keywords (see the [[Res:Eclipse_related_utilities#Reading_the_ECLIPSE_manuals|ECLIPSE manual]] for details):
* '''SPECGRID''': Three numbers separated by spaces, nx ny nz, number of cells in each direction. Two additional optional items are ignored by the upscaling codes.
* '''MAPAXES''': Six numbers (map points in global x,y coordinates) defining the transformation from global to local coordinates (ignored by the upscaling codes)
* '''COORD''': 6 numbers for each of the pillars, x, y and z in local coordinates for top and bottom point of pillars. (nx+1)*(ny+1)*6 numbers
* '''ZCORN''': For all the eight corners of each cell, the z-values are specified, in a peculiar way (see ECLIPSE manual for details)

== Keywords for properties ==

Grid properties are defined by a number of keywords, the following are used by the upscaling code:
* '''ACTNUM''': Either 0 or 1 to denote if the cell is to be treated as active or not. Ignored by Sintef upscaling code.
* '''SATNUM''': Integer specifying the rock type.
* '''PERMX''': Float specifying the absolute permeability (in x-direction) for each cell
* '''PORO''': Float specifying porosity for each cell

== Locally defined keywords for elastic properties ==

The [[Upscaling elastic moduli|code for upscaling of elastic moduli]] allows the user to provide cell-level elastic properties in the eclipse files. To accomplish this, the following locally defined additional keywords are supported. The keywords must come in pairs as listed here:
* YOUNGMOD and POISSONMOD
* LAMEMOD and SHEARMOD
* PWAVEMOD and SHEARMOD
* BULKMOD and SHEARMOD

Black oil simulator

2020-10-16T16:17:30Z

Cintiamachado: Added black-oil equations

The black-oil simulator is based on the premise that system has three different fluid phases (aqueous, oleic, and gaseous) and three (pseudo)components: water, oil, and gas.

== Model Equations ==

Black oil reservoir flow

2020-10-16T12:31:51Z

Cintiamachado: /* Available black oil reservoir flow programs */

=Available black oil reservoir flow programs=
* [[Black oil simulator|Black oil simulator]]
* [[Water evaporation|Water evaporation]]

Main Page

2020-10-15T08:08:11Z

Cintiamachado: Update opm modules names

= 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 =
We do not have any polished and complete solution for viewing the content of ECLIPSE summary files, but based on ERT it is quite simple to get a usable solution.

== Text based solution: ecl_summary ==
As part of the ert distribution there is an application <tt>devel/libecl/applications/view_summary.c</tt> which loads an ECLIPSE summary dataset and prints the selected vectors on standard out:

<pre>
ecl_summary /path/to/eclipse/case KEY1 KEY2 KEY3 .... KEYN
</pre>

Where the <tt>/path/to/eclipse/case</tt> is the datafile (extension is optional) and the keys are summary keys on the form <tt>FOPT</tt> and <tt>WWCT:OP_2</tt>. If you just print <tt>ecl_summary</tt> without any arguments you should get usage documentation on standard out.

Observe that there are two quirks with the ERT build system you should be aware of:
<ol>
<li> To get the <tt>ecl_summary</tt> application you must set the <tt>BUILD_ECL_SUMMARY</tt> switch to on in the CMake configuration. </li>
<li> If you set the <tt>BUILD_APPLICATIONS</tt> switch to on you will get many small utility applications, including <tt>summary.x</tt> which is just another name for the <tt>ecl_summary</tt> application. </li>
</ol>

An example of using ecl_summary/summary.x is here:
<pre>
bash% summary.x ECL_0014 FOPT BPR:10,5,5 WWCT:OP_3 WOPT:OP_1
-- Days dd/mm/yyyy FOPT BPR:10,5,5 WWCT:OP_3 WOPT:OP_1
-------------------------------------------------------------------------------------------
0.00 01/01/2000 0 313.656 0 0
1.00 02/01/2000 19997 313.656 0.00019418 4000
2.46 03/01/2000 49248.3 313.653 0.000238967 9851.13
4.89 05/01/2000 97760.8 313.626 0.000252414 19555.1
7.82 08/01/2000 156373 313.547 0.000243964 31279.4
11.08 12/01/2000 221530 313.391 0.00022476 44312.6
14.81 15/01/2000 296109 313.124 0.000200324 59230.8
18.93 19/01/2000 378478 312.727 0.000175366 75707
24.53 25/01/2000 490428 312.031 0.000148221 98100.4
31.00 01/02/2000 619907 311.061 0.000125331 124000
36.04 06/02/2000 740619 310.383 0.000102394 164191
39.11 09/02/2000 814406 310.027 8.8114e-05 188749
41.70 11/02/2000 876463 309.776 7.70594e-05 209399
45.84 15/02/2000 975873 309.483 6.34081e-05 242515
.....
</pre>

== Graphical solution ==
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> solution is used in much the same way as the text based solutions, but with the added improvement that 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/