Main Page

From opm
Revision as of 08:08, 15 October 2020 by Cintiamachado (talk | contribs) (Update opm modules names)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Getting started with OPM

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

The tutorials section contain some tutorials for programmers using opm-core.

Consult the 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

Developer Information

How to contribute

OPM tries to follow a development model which is as open as possible. Therefore, all development happens on 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
  • 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).
    • 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

Jenkins dashboard.

Information about Jenkins triggers.

List of available 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 devel/libecl/applications/view_summary.c which loads an ECLIPSE summary dataset and prints the selected vectors on standard out:

ecl_summary /path/to/eclipse/case  KEY1 KEY2 KEY3 .... KEYN

Where the /path/to/eclipse/case is the datafile (extension is optional) and the keys are summary keys on the form FOPT and WWCT:OP_2. If you just print ecl_summary 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:

  1. To get the ecl_summary application you must set the BUILD_ECL_SUMMARY switch to on in the CMake configuration.
  2. If you set the BUILD_APPLICATIONS switch to on you will get many small utility applications, including summary.x which is just another name for the ecl_summary application.

An example of using ecl_summary/summary.x is here:

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 
 .....

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:

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

When everything is installed the summaryplot solution is used in much the same way as the text based solutions, but with the added improvement that it can plot mulitple realisations:

summaryplot WWCT:OP_1 CASE1.DATA CASE2.DATA

File:Profile.png

Internal stuff

This section contains links to topic mostly of interest to active OPM developers.

  1. Module reorganization: OPM_reorg_2015
  2. Tasks required for 2015 field case: Tasks_for_new_case_2015
  3. 2020 group control effort

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/