We require a number of libraries and frameworks that are not part of OPM itself to be installed before you can build. For instructions see the prerequisites page. Note in particular that to build the current master branch of OPM you will typically need to also have the current master branch of libecl, all other prerequisites usually have installable packages available (depending on your OS or distro).
Also, while it is possible to have installed binary package versions of OPM modules on your system at the same time that you build/use OPM from source, it is a typical source of hard-to-find errors. We therefore recommend that you uninstall the opm binary packages (and libecl, see above) before you start building from source.
Build the opm modules in the following order:
Not every item depends on everything above it, but all depend on at least one item above it. ResInsight is quite independent, and can be built without any of the other modules. For more information, there is a module overview.
This structure is subject to change: it is likely that new modules will appear, and existing modules will be combined or restructured. We are currently working on reducing the number of modules to simplify the structure.
- Added a new module, opm-output.
- Renamed dune-cornerpoint to opm-grid.
- Renamed opm-autodiff to opm-simulators.
- Combined the opm-porsol module with the opm-upscaling module (all is in opm-upscaling now).
- Ceased maintaining the opm-verteq module, removing it from the set of modules that will be part of releases. Its repository remains available and you can still use earlier release branches.
- Removed the opm-core module, moving most of the contents to opm-simulators but some to opm-grid or opm-common.
- Folded the opm-parser and opm-output modules into the opm-common module.
- Changed the dependency relationships between the modules (several times). This means that the order above is good for the current master branch on GitHub, but if you want to build an older release the order is different, and found here.
First, you should use git to clone the source repositories, like this:
git clone https://github.com/OPM/[modulename].git
Alternatively, you can download the release tarballs. We recommend that you put all the modules in a single directory. Then, to build any module,
mkdir [modulename]/build cd [modulename]/build cmake .. make
Since some modules depend on others, you may save yourself trouble by building the modules in the order given above, starting with opm-common.
Tips and tweaks
To do all of this in one go, you can try this bash script:
#!/bin/bash for repo in opm-common opm-material opm-grid ewoms opm-simulators opm-upscaling do echo "=== Cloning and building module: $repo" git clone https://github.com/OPM/$repo.git mkdir $repo/build cd $repo/build cmake .. make cd ../.. done
To speed up compilation on a multicore machine, you may want to use for example on a 8-core machine:
make -j 7
This will start 7 parallel compilation jobs, leaving one core for other things.
You may need to customize the build process in order to specify compiler options, nonstandard library locations, build type and more. Then replace the cmake command with:
cmake -C options.cmake ..
The options.cmake file contains your customization. CMake syntax must be used, an example of such an options file is given below. It specifies the compilers to use, a nonstandard location for SuperLU and that you want a Debug build (the default is Release).
set(CMAKE_C_COMPILER "/usr/local/bin/gcc-5.1" CACHE STRING "C compiler") set(CMAKE_CXX_COMPILER "/usr/local/bin/g++-5.1" CACHE STRING "C++ compiler") set(SUPERLU_ROOT "/work/local/SuperLU_4.3" CACHE STRING "Path to SuperLU") set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "Build type")
Finally, if you want to build with MPI support, you must turn it on in the call to cmake. Do this by adding the “-DUSE_MPI=1” option to the cmake calls, or if using an options.cmake file add the line
set(USE_MPI ON CACHE BOOL "Use MPI")
to your options.cmake file.