- 1 Getting started with OPM
- 2 User documentation for selected programs
- 3 Developer Information
- 4 Viewing ECLIPSE summary files
- 5 Internal stuff
- 6 Plots
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
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).
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)
- opm-parser: Joakim Hove (@joakim-hove)
- opm-output: Joakim Hove (@joakim-hove)
- opm-material: Andreas Lauser (@andlaus)
- opm-core: Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
- opm-grid: Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
- opm-upscaling: Arne Morten Kvarving (@akva2)
- opm-simulators: Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska) and Robert Klöfkorn (@dr-robertk)
- ewoms: Andreas Lauser (@andlaus)
- ResInsight: Magne Sjaastad (@magnesj) and Jacob Støren (@JacobStoren)
Jenkins triggers for GitHub
Information about Jenkins triggers.
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:
- To get the ecl_summary application you must set the BUILD_ECL_SUMMARY switch to on in the CMake configuration.
- 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 .....
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:
- You need the Python packages matplotlib and numpy.
- 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
This section contains links to topic mostly of interest to active OPM developers.
The full Norne model is run once a week, and PDF document with all the well results is generated: http://22.214.171.124/plots/