Notes for managing release (since 2026.04)

2026-04-14T15:01:48Z

Michaltoth: Detailed manual for the release managers (incomplete).

The responsibility of the release manager is to
* Create release branch and tag release candidates for testing
* Build binary packages for testing
* Backport bugfixes and other high-priority pull requests
* Update the version of the modules

Note that all steps have to be repeated for modules ''opm-common'', ''opm-grid'', ''opm-simulators'', and ''opm-upscaling''

==Creation of the first release candidate==
# Create a new branch for the first release candidate.
## The branch naming convention is ''year.month'', e.g. 2026.04, and we currently have releases in months 04 and 10.
## Open the ''dune.module'' change the Version and Label to the release candidate 1, e.g. change 2026.04-pre to 2026.04-rc1.
## Add and commit the changes to the ''dune.module''.
## Give the branch the tag of the release candidate: ''branch_name''/rc1. Make sure the tag is placed after the version change was committed. If it was placed before, delete the tag and create it again after the commit.
##: git tag 2026.04/rc1
# Push the branch into the OPM github remote.
#: Push the tag as well.
# Update the version of the master branch.
#: This is done via a normal pull request from your forked repository. Update the Version and Label in ''dune.module'', e.g. from 2026.04-pre to 2026.10-pre. Note that master is always ahead of release.
# Update the release version in the shell scripts in ''opm-utilities''.
#: Relevant files are ''release-scripts/opm-backport-pr.sh'' and '' release-scripts/opm-release-install-test.sh''.
#: This is done via a normal pull request like the version-updating of the master branch.

Main Page

2026-04-14T13:58:03Z

Michaltoth: Update the link for release managers. The page will follow.

= 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), Markus Blatt (@blattms), Tor Harald Sandve (@totto82)
* '''opm-grid''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Markus Blatt (@blattms), Arne Morten Kvarving (@akva2)
* '''opm-simulators''': Atgeirr Rasmussen (@atgeirr), Bård Skaflestad (@bska), Tor Harald Sandve (@totto82), Arne Morten Kvarving (@akva2)
* '''opm-tests''': Alf Birger Rustad (@alfbr), Torbjørn Skille (@tskille), Bård Skaflestad (@bksa), Arne Morten Kvarving (@akva2)
* '''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 (since 2026.04)]]

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

[[Data for output and restart]]

=== Notes on Debian Packages ===

[[Debian Packaging Workflow]]

= 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/

opm - User contributions [en]

Notes for managing release (since 2026.04)

Main Page