opm/opm-common

Common components for OPM, in particular build system (cmake).

opm-common's Issues

dune-common of Debian jessie not found using dunecontrol

I just wanted to test my code on another server and used jessie's stock dune packages (version 2.3.1) to save time.

Unfortunately, in opm-material dune-common is not found:

-- dune-common_ROOT = /usr/lib/x86_64-linux-gnu/cmake/dune-common
CMake Error at /usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:136 (message):
  Could NOT find dune-common (missing: dune-common_INCLUDE_DIR
  dune-common_LIBRARY)
Call Stack (most recent call first):
  /usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:343 (_FPHSA_FAILURE_MESSAGE)
  /home/mblatt/DUNE/opm-common/cmake/Modules/OpmPackage.cmake:358 (find_package_handle_standard_args)
  /home/mblatt/DUNE/opm-common/cmake/Modules/Finddune-common.cmake:14 (find_opm_package)
  /home/mblatt/DUNE/opm-common/cmake/Modules/OpmFind.cmake:147 (find_package)
  /home/mblatt/DUNE/opm-common/cmake/Modules/OpmFind.cmake:211 (find_and_append_package_to)
  /home/mblatt/DUNE/opm-common/cmake/Modules/OpmLibMain.cmake:104 (find_and_append_package_list_to)
  CMakeLists.txt:95 (include)


-- Configuring incomplete, errors occurred!

The problem is that dunecontrol defines dune-common_ROOT and opm then always uses NO_DEFAULT_PATH in its find_... calls

OPM modules cannot be used as upstreams for dune modules

... or more precisely "All OPM modules except opm-parser cannot easily be used as upstreams for dune modules". I think this is a functionality which is a hard prerequisite if the OPM project is supposed to appeal to users who do want to use parts of the project in non-reservoir engineering contexts. To test this, check out e.g. dune-fem and add opm-grid to the dependencies of its dune.module file. With this I got

CMake Error at /home/and/src/dune-common/cmake/modules/DuneMacros.cmake:256 (message):
  Could not find dune.module file for module opm-grid in ,
  /lib/dunecontrol/opm-grid/, /lib64/dunecontrol/opm-grid/dune.module
Call Stack (most recent call first):
  /home/and/src/dune-common/cmake/modules/DuneMacros.cmake:421 (find_dune_package)
  /home/and/src/dune-common/cmake/modules/DuneMacros.cmake:464 (dune_process_dependency_leafs)
  /home/and/src/dune-common/cmake/modules/DuneMacros.cmake:488 (dune_create_dependency_leafs)
  /home/and/src/dune-common/cmake/modules/DuneMacros.cmake:634 (dune_create_dependency_tree)
  CMakeLists.txt:25 (dune_project)

needless to say, that this works without a hitch if the dune buildsystem is used for the opm dependencies.

Summary output does not includes all the time steps

I think some changes between May 12th (not exactly) and previous release causes the problem.

Basically, you will not get the results from all the time steps. For example, you specifies 300 days in the deck, you can only read out 280 or 250 days of result from the summary files. And it is a little random.

I am not sure changes in which module cause this problem, so I just put here.

Please help to confirm and fix it if verified.

Path for libecl library not correctly set when linking flow

Took me some time to figure this out. Default build type for libecl seems to be RELWITHDEBINFO while the
genuine opm modules use RELEASE. This means that if I do not set the build type manually, I run into the
following troubles:

After updating all my modules, I cannot run not-installed flow anymore as libecl is not found.

$ ldd bin/flow| grep ecl
	libecl.so.2 => not found

I build all my modules in module-name/opm-parallel Using cmake -C ../../opts.cmake ... Same for libecl (libecl/parallel).

$ cat ../../opts.cmake| grep -v -e "^#"
set(USE_MPI ON         CACHE STRING "Use mpi")
set(BUILD_TESTING OFF CACHE BOOL "Build tests")
set(CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY 1 CACHE BOOL "" FORCE)
set(BUILD_ECL_SUMMARY ON CACHE BOOL "Build summary.x")
set(BUILD_APPLICATIONS OFF CACHE BOOL "Build applications")

The resean is there is no imported target for build type RELEASE in libecl.

$ grep -B5 libecl.so ../..libecl/opm-parallel/eclConfig.cmake
)

# Import target "ecl" for configuration "RelWithDebInfo"
set_property(TARGET ecl APPEND PROPERTY IMPORTED_CONFIGURATIONS RELWITHDEBINFO)
set_target_properties(ecl PROPERTIES
  IMPORTED_LOCATION_RELWITHDEBINFO "/home/mblatt/src/dune/opm-2.6/libecl/opm-parallel/lib/libecl.so.2.3"
  IMPORTED_SONAME_RELWITHDEBINFO "libecl.so.2"

but we are using this one for opm-simulators:

$ grep BUILD_TYPE CMakeCache.txt 
CMAKE_BUILD_TYPE:STRING=Release

Edit: Turns out I have the same problem when explicitly setting CMAKE_BUILD_TYPE=Release. Therefore this seems to be not related to the build type.

Use of .cpp files in opm-common

I would like to add classes with .cpp files to opm-common. Is this possible currently (i.e. files will be compiled, put in a library, and linked to by downstream modules)? Separately: what about unit tests?

Also: if anyone is strongly opposed to this, please tell us why!

opm-grid-config.cmake always warns about dune-istl version incompatibility in opm-simulators

When I run CMake I get these warnings:

-- Finding package opm-grid using config mode
CMake Warning at /home/mblatt/src/dune/opm/opm-grid/opm-parallel-dbg/opm-grid-config.cmake:283 (message):
  Incompatible value "2" of variable "DUNE_ISTL_VERSION_MAJOR"
Call Stack (most recent call first):
  /home/mblatt/src/dune/opm/opm-common/cmake/Modules/OpmFind.cmake:144 (find_package)
  /home/mblatt/src/dune/opm/opm-common/cmake/Modules/OpmFind.cmake:211 (find_and_append_package_to)
  /home/mblatt/src/dune/opm/opm-common/cmake/Modules/OpmLibMain.cmake:112 (find_and_append_package_list_to)
  CMakeLists.txt:111 (include)


CMake Warning at /home/mblatt/src/dune/opm/opm-grid/opm-parallel-dbg/opm-grid-config.cmake:287 (message):
  Incompatible value "3" of variable "DUNE_ISTL_VERSION_MINOR"
Call Stack (most recent call first):
  /home/mblatt/src/dune/opm/opm-common/cmake/Modules/OpmFind.cmake:144 (find_package)
  /home/mblatt/src/dune/opm/opm-common/cmake/Modules/OpmFind.cmake:211 (find_and_append_package_to)
  /home/mblatt/src/dune/opm/opm-common/cmake/Modules/OpmLibMain.cmake:112 (find_and_append_package_list_to)
  CMakeLists.txt:111 (include)


CMake Warning at /home/mblatt/src/dune/opm/opm-grid/opm-parallel-dbg/opm-grid-config.cmake:291 (message):
  Incompatible value "1" of variable "DUNE_ISTL_VERSION_REVISION"
Call Stack (most recent call first):
  /home/mblatt/src/dune/opm/opm-common/cmake/Modules/OpmFind.cmake:144 (find_package)
  /home/mblatt/src/dune/opm/opm-common/cmake/Modules/OpmFind.cmake:211 (find_and_append_package_to)
  /home/mblatt/src/dune/opm/opm-common/cmake/Modules/OpmLibMain.cmake:112 (find_and_append_package_list_to)
  CMakeLists.txt:111 (include)

These version are already set by the buildsystem when searching for the dune modules. The test warns if MINOR or REVISION are not "".

Color for warning.

The color coding looks cool, but the yellow color for warning experience quite different for different terminal, probably we could use another color instead, following is a picture, for the yellow you're hardly see anything...
@atgeirr

flow supresses obvious well misconfigurations

Flow does not warn on well misconfigurations. Can be reproduced in SPE1 dataset by changing the wellname within COMPDAT, WELSPECS and WCONPROD/WCONINJE e.g.:

WELSPECS
  'PROD' 'G1'  10 10 8400 'OIL' /
/
COMPDAT
  'PROD2' 10 10 3 3 'OPEN' 1* 1* 0.5 /
/
WCONPROD
  'SOMETHINGELSE' 'OPEN' 'ORAT' 20000 4* 1000 /
/

will run without warnings, although no well will be present in the result.

Found the issue while working on a different topic. Haven't looked into it much.

Problem liking to DUNE-COMMON

I am not able to build OPM after updating to current master

CMake is not able to find dune-common.

CMake Error at /home/thsa/workspace/opm/opm-common/cmake/Modules/OpmPackage.cmake:85 (find_package):
  Could not find a package configuration file provided by "dune-common" with
  any of the following names:

    dune-commonConfig.cmake
    dune-common-config.cmake

I have tried to pass the dune-common path manually without success.
A deep clean of everything did not help either.
Any hint on what may have gone wrong?

test_Summary fails locally

    Start 116: Summary

116: Test command: /home/kaib/OPM-master-test/debug/opm-common-build/bin/test_Summary
116: Test timeout computed to be: 1500
116: Running 27 test cases...
116: /home/kaib/OPM-master-test/debug/opm-common/tests/test_Summary.cpp(337): error in "well_keywords": difference{60%} between 30.0 * 1.5 + 30.0 * 2.5{120} and ecl_sum_get_well_var( resp, 2, "W_3", "WCIT" ){75} exceeds 1.0000000000000001e-05%
116: /home/kaib/OPM-master-test/debug/opm-common/tests/test_Summary.cpp(498): error in "group_keywords": difference{60%} between 30.0 * 1.5 + 30.0 * 2.5{120} and ecl_sum_get_group_var( resp, 2, "G_2", "GCIT" ){75} exceeds 1.0000000000000001e-05%
116: /home/kaib/OPM-master-test/debug/opm-common/tests/test_Summary.cpp(643): error in "completion_kewords": difference{60%} between 300.0 * 1.5 + 300.0 * 2.5{1200} and ecl_sum_get_well_completion_var( resp, 2, "W_3", "CCIT", 3 ){750} exceeds 1.0000000000000001e-05%
116: /home/kaib/OPM-master-test/debug/opm-common/tests/test_Summary.cpp(749): error in "field_keywords": difference{60%} between 30.0 * 1.5 + 30.0 * 2.5{120} and ecl_sum_get_field_var( resp, 2, "FCIT" ){75} exceeds 1.0000000000000001e-05%
116: 
116: *** 4 failures detected in test suite "Wells"

WELL_PROBE kw size

"WGIRL" and "WGITL" in some models contain more than one element, and causes OPM-parser to read next line as a new keyword and subsequently fail. The issue is in https://github.com/OPM/opm-common/blob/master/src/opm/parser/eclipse/share/keywords/000_Eclipse100/W/WELL_PROBE

MPI causes linker errors

this is a follow up of #296: I tried to set USE_MPI to ON on my Ubuntu 16.04 system with dune 2.5 manually compiled in sibling directories. this lead to linker errors starting in opm-grid:

opm-grid/build-cmake|master > make
[  2%] Updating version information
[  2%] Built target update-version
[ 79%] Built target opmgrid
[ 82%] Linking CXX executable bin/mirror_grid
/usr/lib/openmpi/lib/libmpi_cxx.so: error: undefined reference to 'opal_list_item_t_class'
/usr/lib/openmpi/lib/libmpi_cxx.so: error: undefined reference to 'opal_class_initialize'
collect2: error: ld returned 1 exit status
CMakeFiles/mirror_grid.dir/build.make:125: recipe for target 'bin/mirror_grid' failed
make[2]: *** [bin/mirror_grid] Error 1
CMakeFiles/Makefile2:175: recipe for target 'CMakeFiles/mirror_grid.dir/all' failed
make[1]: *** [CMakeFiles/mirror_grid.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

By now, it is probably needless to mention that it works flawlessly with the alternative build system.

Known issues preventing Windows compilation

Feel free to edit this post to add issues/explanations.

• #include <unistd.h> for the isatty function.

Feature Request: Unhandled Keywords Message

Currently the PARSER ignores keywords that are known to the PARSER but are unknown to FLOW and this creates numerous issues, as it is difficult to see if a particular option is implemented or active in FLOW, as in both cases the simulation proceeds and runs successfully or unsuccessfully, depending on your point of view.

It would be extremely useful if the PARSER issued a warning message after processing the deck stating that the keyword will be ignored by FLOW, similar to what is done for the inactive RPTRST keyword options in FLOW, that is:

Warning: Keyword 'BASIC' is unhandled for output to file.

Warning: Keyword 'PRES' is unhandled for output to file.

Warning: Keyword 'RS' is unhandled for output to file.

Warning: Keyword 'SGAS' is unhandled for output to file.

Warning: Keyword 'WELLS' is unhandled for output to file.

May be something like:

Warning: Keyword 'THERMAL' is ignored by Flow and will have no effect on the simulation.
Warning: Keyword 'THCONR' is ignored by Flow and will have no effect on the simulation.
Warning: Keyword 'SPECHEAT' is ignored by Flow and will have no effect on the simulation.
Warning: Keyword 'SPECROCK' is ignored by Flow and will have no effect on the simulation.

No suitable configuration found, valid are Twophase, polymer, solvent, or blackoil

I can help with identifying the status of the keywords that are active and inactive, if that would help.

OPM superLU detection seems to be incompatible with dune's

this makes it much harder to use SuperLU as a linear solver than it needs to be: Using dune 2.5, I get

CMake Warning at /home/and/src/opm-grid/build-cmake/opm-grid-config.cmake:223 (message):
  Incompatible value "1" of variable "SUPERLU_MIN_VERSION_4_3"
Call Stack (most recent call first):
  /home/and/src/dune-common/cmake/modules/DuneMacros.cmake:175 (find_package)
  /home/and/src/dune-common/cmake/modules/DuneMacros.cmake:421 (find_dune_package)
  /home/and/src/dune-common/cmake/modules/DuneMacros.cmake:464 (dune_process_dependency_leafs)
  /home/and/src/dune-common/cmake/modules/DuneMacros.cmake:488 (dune_create_dependency_leafs)
  /home/and/src/dune-common/cmake/modules/DuneMacros.cmake:634 (dune_create_dependency_tree)
  CMakeLists.txt:25 (dune_project)

How to handle non-standard keywords

This is moved from: OPM/opm-parser#1216

@GitPaean:
Add keywords: SKPRWAT, SKPRPOLY and PINTDIMS.

@OPMUSER
I understand the need to add additional functionality and keywords, but I think we need to have some way of indicating that this feature and the associated keywords that are non-standard with respect to E100/E300. I have some suggestions, but none of them are perfect:

Add new section called OPMFLOW that contains all the none standard keywords. That way everything is in the one place and can be easily recognized, but it also has the disadvantage of the keywords not associated with an ECL100 section not being in the section.

Add two new keywords FLOWSTR and FLOWEND (or something similar) and place all the alternative keywords in between the two aforementioned keywords. This allows the non-ECL100 keywords to be placed in the correct section and yet still be identified.

We have to bear in mind that as OPM Flow matures it is going to be used by more and more users in "production" mode, so we have take into account this user base as well as the research user base at the same time. In time the production users will be a source for funding further development, both for improvements and research topics as well.

I don't really have an answer to this but I wanted to start the discussion.

@atgeirr
I think your suggested solutions (separate section or keyword delimiters) are too restrictive, but I realize that it can be important to know which keywords are "standard".

What about naming all such keywords "OPMsomething"? The biggest problem is then that we will be limited to 5 characters for the "something" part.

@GitPaean
If we only add non-standard keywords for the functionalities not supported by the standard E100 simulator, I mean we do not change/expand the existing standard keywords, I do not see the big consequence can be resulted. In the manual, we should tell explicitly these are OPM keywords.

What about naming all such keywords "OPMsomething"? The biggest problem is then that we will be limited to 5 characters for the "something" part.

8-letter length limitation is already not very easy to use when describing keywords for some specific functionalities, 5 will make it much harder. I am not sure for how easy to remove the 8-letter limitation for non-standard keywords, then we can have some more intuitive keyword naming.

@alfbr

I think we need to have some way of indicating that this feature and the associated keywords that are non-standard with respect to E100/E300

I agree that this is problematic. However, we are only following the example led by E100/E300. There is no way to see from a keyword whether it is supported by E100 or E300. You need to consult the manual to see which it is. We have simply followed the same design principle.

@OPMUSER
There is some history here with E100 and E300 being developed by two separate teams without parental guidance ;-); hence, the WELXXXX (E100 keywords) and the WELLXXXX (E300) keywords as they were two separate programs unlike VIP and tNavigator that are based on the same code base.

Originally E100 and E300 were documented in two separate manuals because they were two separate programs, that is why there is all this confusion on which keywords belong to which simulator. The problem for Schlumberger at the time was that VIP, a major competitor was the one simulator for both black-oil and compositional formulations. I changing from black-oil to compositional was easy as just changing the PVT section. Thus Schlumberger started merging the manuals and keywords to give the impression that they were the same program, they are two separate programs.

So we should not dwell and the E100 and E300 difference, but how do wish to distinguish between the standard E100 keywords and the OPM Flow specific keywords. What about instead of OPM in front of the keywords what about a period or a $ sign and keep the eight characters for the keyword?

Should doxygen really be required?

Just tested a new setup and cmake failed due to missing doxygen. Is that intended?

Use 'installed' versions of the build modules?

When the build system was in opm-cmake I used to do (roughly):

1. fetch and update opm-cmake
2. cmake -DCMAKE_INSTALL_PREFIX=/path/to/common/share

In a regular Jenkins job; and then when building module opm-xxx I would configure with cmake -DOPM_CMAKE_ROOT=/path/to/common/share - unless I was actually updating the build system (which was quite seldom) - this worked fine.

However now it seems that opm-common does not install the cmake modules - so suddenly sibling builds have become mandatory; at least opm-common must be found in the sibling search? Is this by design - or an oversight of some kind?

DUNE_ISTL_VERSION_* not set in opm-simulators.

I'm having the problem that the version of istl is not set in config.h
This has worked before, and I did not change the DUNE version. What could be the reasons and where are these variables set?

Here a snippet from config.h :

define DUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS 1

define DUNE_GRID_VERSION_MAJOR 2

define DUNE_GRID_VERSION_MINOR 4

define DUNE_GRID_VERSION_REVISION 1

define DUNE_COMMON_VERSION_MAJOR 2

define DUNE_COMMON_VERSION_MINOR 4

define DUNE_COMMON_VERSION_REVISION 1

/* #undef DUNE_ISTL_VERSION_MAJOR /
/ #undef DUNE_ISTL_VERSION_MINOR /
/ #undef DUNE_ISTL_VERSION_REVISION */

Completion::fromCOMPDAT(): Possible Bug?

I was reading through Completion.cpp and came across this line from Completion::fromCOMPDAT(grid, prop, kw, wells):

if( prev_compls[ index ] == 0 ) (*well)->getCompletions().size();

This looks a bit strange to me. Does the getCompletions() member function—or the act of invoking .size() on its return value—have some non-local effect? If not, why do we not do something to the result of .size()?

cycle in constraints graph

recently cmake started to spit the following warning at me:

CMake Warning at /home/and/src/opm-common/cmake/Modules/OpmSatellites.cmake:295 (add_executable):
  Cannot generate a safe runtime search path for target tutorial1 because
  there is a cycle in the constraint graph:

    dir 0 is [/home/and/src/opm-common/lib]
    dir 1 is [/home/and/src/opm-material/lib]
    dir 2 is [/home/and/src/opm-grid/lib]
    dir 3 is [/home/and/src/ert/install/lib/x86_64-linux-gnu]
      dir 5 must precede it due to runtime library [libecl.so.2]
    dir 4 is [/home/and/tmp/boost-clang-install/lib]
    dir 5 is [/home/and/src/ert/build/lib/x86_64-linux-gnu]
      dir 3 must precede it due to runtime library [libecl.so.2]
    dir 6 is [/usr/lib/openmpi/lib]

  Some of these libraries may not be found correctly.
Call Stack (most recent call first):
  CMakeLists.txt:297 (opm_add_test)

without going into it too deeply, this looks like a problem caused by sibling builds. (maybe FindERT.cmake detects an installed version of the library as well as a sibling one?) also, this may or not be due to the fact that I compiled using ERT using GCC 5.2.1 while I used clang 3.6.2 for Dune and OPM. (given that ERT is plain-C, I consider this being the culprit somewhat unlikely.)

SSL cerificate of the CI system expired

The SSL certificate of the jenkins server has expired yesterday which yields a scary browser warning and necessitates to add a security exception when trying to access ci.opm-project.org

Jenkins should check that generated code is up to date

since decreeing the presence of python with an installed jinja2 module on everyone who wants to build OPM is IMO asked to much, opm-material ships the result of the genEvalSpecializations.py code generator script with master. This leads to people occasionally ignoring the warning at the beginning of these header files and edit them manually. To prevent this, Jenkins should run the code generator before building that module and bail out if any differences are detected, i.e. the regression test script should contain something like

cd opm-material
./bin/genEvalSpecializations.py
if test "$(git diff)" != ""; then
   echo "auto-generated code does not match the shipped version"
   exit 1
fi

remove dune-control support

dune-control support is a useless hack and maintaining support is additional load on the build system.

let's remove this.

Boost only found if static libraries are installed.

My favourite monster library can only be detected by the OPM build system if compiled such that static libraries are available. Since there is a check for that in opm-common, UseDynamicBoost, I assume that there is a problem.

Is it Okay to Rely on Schedule::getWells(timeStep) Returning Wells in Order of Appearance?

Right now, as a consequence of using an Opm::OrderedMap<> to manage the wells in a simulation model, the code fragment below will iterate over the wells in the order they are declared in the WELSPECS keyword (possibly entered multiple times in a simulation deck).

Is it okay to rely on this fact/implementation detail? The reason I ask is that restart data for wells must be output in the order of the wells' appearance/declaration.

---

// timeStep is integer step ID (std::size_t)
for (const auto& wellPtr : schedule.getWells(timeStep)) {
    use(*wellPtr);
}

Why Does `Summary.cpp:find_wells()` Use All Wells at Simulation End for its Field Vectors?

I was reading through Summary.cpp and in particular helper function find_wells() which gets called as part of Summary::add_timestep()'s handling of preconfigured "derived" summary vectors pertaining to wells, groups, fields, and connections/completions.

In the case of a "Field" vector (e.g., "FOPT"), function find_wells() will return

schedule.getWells();

which is all wells present at the end of the simulation run as opposed to those that are active/present at the pertinent sim_step. Contrariwise, the "Group" vectors are restricted to those wells that are in the relevant group at the particular time_step.

Is that distinction intentional?

Understand why the system include feature sometimes fails.

The feature included in #202 and made optional in #210 fails for some users, see for example OPM/opm-core#1108.

We should find the source of the problem and fix it.

cmake error

I am trying to build the latest version of OPM in my own laptop, while the cmake did not pass.

CMake Warning at /usr/share/cmake-3.5/Modules/FindBoost.cmake:725 (message):
  Imported targets not available for Boost version
Call Stack (most recent call first):
  /usr/share/cmake-3.5/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES)
  /usr/share/cmake-3.5/Modules/FindBoost.cmake:1332 (_Boost_MISSING_DEPENDENCIES)
  cmake/Modules/OpmFind.cmake:147 (find_package)
  cmake/Modules/OpmFind.cmake:211 (find_and_append_package_to)
  cmake/Modules/OpmLibMain.cmake:112 (find_and_append_package_list_to)
  CMakeLists.txt:51 (include)


CMake Warning at /usr/share/cmake-3.5/Modules/FindBoost.cmake:725 (message):
  Imported targets not available for Boost version
Call Stack (most recent call first):
  /usr/share/cmake-3.5/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES)
  /usr/share/cmake-3.5/Modules/FindBoost.cmake:1332 (_Boost_MISSING_DEPENDENCIES)
  cmake/Modules/OpmFind.cmake:147 (find_package)
  cmake/Modules/OpmFind.cmake:211 (find_and_append_package_to)
  cmake/Modules/OpmLibMain.cmake:112 (find_and_append_package_list_to)
  CMakeLists.txt:51 (include)


CMake Error at /usr/share/cmake-3.5/Modules/FindBoost.cmake:1677 (message):
  Unable to find the requested Boost libraries.

  Unable to find the Boost header files.  Please set BOOST_ROOT to the root
  directory containing Boost or BOOST_INCLUDEDIR to the directory containing
  Boost's headers.
Call Stack (most recent call first):
  cmake/Modules/OpmFind.cmake:147 (find_package)
  cmake/Modules/OpmFind.cmake:211 (find_and_append_package_to)
  cmake/Modules/OpmLibMain.cmake:112 (find_and_append_package_list_to)
  CMakeLists.txt:51 (include)


-- Generating debug symbols: -ggdb3
-- Looking for strip utility
-- Looking for strip utility - found
CMake Warning at /usr/share/cmake-3.5/Modules/FindBoost.cmake:725 (message):
  Imported targets not available for Boost version
Call Stack (most recent call first):
  /usr/share/cmake-3.5/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES)
  /usr/share/cmake-3.5/Modules/FindBoost.cmake:1332 (_Boost_MISSING_DEPENDENCIES)
  cmake/Modules/UseDynamicBoost.cmake:2 (find_package)
  cmake/Modules/OpmLibMain.cmake:128 (include)
  CMakeLists.txt:51 (include)


-- Writing config file "/home/bao/devel/OPM/debug/opm-common-build/config.h"...
-- This build defaults to installing in /usr/local
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.11") 
-- Libtool not found!
-- Writing version information to local header project-version.h
-- Configuring incomplete, errors occurred!
See also "/home/bao/devel/OPM/debug/opm-common-build/CMakeFiles/CMakeOutput.log".
See also "/home/bao/devel/OPM/debug/opm-common-build/CMakeFiles/CMakeError.log".

And in CMakeError.log

Determining if the pthread_create exist failed with the following output:
Change Dir: /home/bao/devel/OPM/debug/opm-common-build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_c97a8/fast"
/usr/bin/make -f CMakeFiles/cmTC_c97a8.dir/build.make CMakeFiles/cmTC_c97a8.dir/build
make[1]: Entering directory '/home/bao/devel/OPM/debug/opm-common-build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_c97a8.dir/CheckSymbolExists.c.o
/usr/bin/cc    -pipe -Wall -Wno-unknown-pragmas    -o CMakeFiles/cmTC_c97a8.dir/CheckSymbolExists.c.o   -c /home/bao/devel/OPM/debug/opm-common-build/CMakeFiles/CMakeTmp/CheckSymbolExists.c
Linking C executable cmTC_c97a8
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_c97a8.dir/link.txt --verbose=1
/usr/bin/cc  -pipe -Wall -Wno-unknown-pragmas     CMakeFiles/cmTC_c97a8.dir/CheckSymbolExists.c.o  -o cmTC_c97a8 -rdynamic 
CMakeFiles/cmTC_c97a8.dir/CheckSymbolExists.c.o: In function `main':
CheckSymbolExists.c:(.text+0x16): undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_c97a8.dir/build.make:97: recipe for target 'cmTC_c97a8' failed
make[1]: *** [cmTC_c97a8] Error 1
make[1]: Leaving directory '/home/bao/devel/OPM/debug/opm-common-build/CMakeFiles/CMakeTmp'
Makefile:126: recipe for target 'cmTC_c97a8/fast' failed
make: *** [cmTC_c97a8/fast] Error 2

File /home/bao/devel/OPM/debug/opm-common-build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include <pthread.h>

int main(int argc, char** argv)
{
  (void)argv;
#ifndef pthread_create
  return ((int*)(&pthread_create))[argc];
#else
  (void)argc;
  return 0;
#endif
}

Determining if the function pthread_create exists in the pthreads failed with the following output:
Change Dir: /home/bao/devel/OPM/debug/opm-common-build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_10bcf/fast"
/usr/bin/make -f CMakeFiles/cmTC_10bcf.dir/build.make CMakeFiles/cmTC_10bcf.dir/build
make[1]: Entering directory '/home/bao/devel/OPM/debug/opm-common-build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_10bcf.dir/CheckFunctionExists.c.o
/usr/bin/cc    -pipe -Wall -Wno-unknown-pragmas -DCHECK_FUNCTION_EXISTS=pthread_create   -o CMakeFiles/cmTC_10bcf.dir/CheckFunctionExists.c.o   -c /usr/share/cmake-3.5/Modules/CheckFunctionExists.c
Linking C executable cmTC_10bcf
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_10bcf.dir/link.txt --verbose=1
/usr/bin/cc  -pipe -Wall -Wno-unknown-pragmas -DCHECK_FUNCTION_EXISTS=pthread_create    CMakeFiles/cmTC_10bcf.dir/CheckFunctionExists.c.o  -o cmTC_10bcf -rdynamic -lpthreads 
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_10bcf.dir/build.make:97: recipe for target 'cmTC_10bcf' failed
make[1]: *** [cmTC_10bcf] Error 1
make[1]: Leaving directory '/home/bao/devel/OPM/debug/opm-common-build/CMakeFiles/CMakeTmp'
Makefile:126: recipe for target 'cmTC_10bcf/fast' failed
make: *** [cmTC_10bcf/fast] Error 2

Any comments?

Questions about the logging facillities.

I have a hard time finding any documentation for this part of OPM. If there is some then please point me to it.

Here are my questions:

• Can I stop the logging and flush/close all logfiles before the program exits?
• Let us say I already have a string with all the necessary formatting (e.g. read from a log file). Is there an
  easy way to log this raw string without any additional formatting added?

cmake error when build opm module chain from scratch

When I checkout all current master modules (and DUNE 2.4) then I get an error in opm-output because opm-common seems not to be included in the include path passed to the compiler.

opm-output/opm/test_util/summaryIntegrationTest.cpp:21:38: fatal error: opm/common/ErrorMacros.hpp: No such file or directory
 #include <opm/common/ErrorMacros.hpp>

Why does cmake complain about libtool not found?

Towards the end of running cmake (for opm-common) I see this:

...
-- Libtool not found!
-- Writing version information to local header project-version.h
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/atgeirr/fffff

Apparently we don't need libtool, so why is it even looking for it?

Ordering of `SimulationDataContainer::saturation()`?

Due to missing documenation I have to ask:
How are the saturation ordered for SimulationDataContainer::saturation()? All saturations of the first cell before the saturations of the next one, or all saturations of the first phase before the ones of the next phase?

HAVE_UMFPACK is replaced by HAVE_SUITESPARSE_UMFPACK in newer dune-istl versions.

Is it as simple as adding HAVE_SUITESPARSE_UMFPACK;
in Finddune-istl.cmake?

opm-simulators does not pickup dunegrid, dunegeometry targets

I am having build problems with the latest cmake changes. To me it seems like the target of dune-geometry and dune-grid are not picked up correctly. Hence either the wrong library in the system location is found or if there is none I get an error:

[ 98%] [100%] Building CXX object CMakeFiles/diagnose_relperm.dir/examples/diagnose_relperm.cpp.o
Building CXX object CMakeFiles/compute_tof.dir/examples/compute_tof.cpp.o
Building CXX object CMakeFiles/compute_tof_from_files.dir/examples/compute_tof_from_files.cpp.o
Building CXX object CMakeFiles/compute_initial_state.dir/examples/compute_initial_state.cpp.o
Linking CXX executable bin/compute_eikonal_from_files
/usr/bin/ld: cannot find -ldunegrid
/usr/bin/ld: cannot find -ldunegeometry
collect2: error: ld returned 1 exit status

For all opm-modules and dune-common the libraries are resolved by CMake to the full path. But for these to modules -ldunegrid -ldunegeometry is used.

Compiling issues

Hi OPM users,

We are encountering issue while linking/testing with system-wide installed boost module.Is there anyway we could get around of it?

login2.stampede2(1072)$ module list

Currently Loaded Modules:
  1) intel/17.0.4   2) impi/17.0.3   3) git/2.9.0   4) autotools/1.1   5) python/2.7.13   6) xalt/1.7.7   7) TACC   8) boost/1.64

CC=mpicc FC=ifort CXX=mpicxx cmake ..
make

..
..
/opt/apps/intel17/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to `VTT for std::__cxx11::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >@GLIBCXX_3.4.21'
/opt/apps/intel17/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_assign(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)@GLIBCXX_3.4.21'
/opt/apps/intel17/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::reserve(unsigned long)@GLIBCXX_3.4.21'

Thanks,

Kevin

build system: config mode bug?

I'm using Ubuntu 16.04 in conjunction with the system-provided Dune packages. under this circumstances, there seems to be a conflict between cmake dune-grid and dune-istl in config mode:

-- Performing Test HAVE_DUNE_ISTL
-- Performing Test HAVE_DUNE_ISTL - Success
-- Found dune-istl: /usr/include  
-- Version 2.4.1 of dune-istl from /usr/lib/dunecontrol/dune-istl/dune.module
[...]
-- Finding package opm-grid using config mode
CMake Warning at /home/and/src/opm-grid/opm-grid-config.cmake:283 (message):
  Incompatible value "2" of variable "DUNE_ISTL_VERSION_MAJOR"
Call Stack (most recent call first):
  /home/and/src/opm-common/cmake/Modules/OpmFind.cmake:144 (find_package)
  /home/and/src/opm-common/cmake/Modules/OpmFind.cmake:211 (find_and_append_package_to)
  /home/and/src/opm-common/cmake/Modules/OpmLibMain.cmake:112 (find_and_append_package_list_to)
  CMakeLists.txt:112 (include)


CMake Warning at /home/and/src/opm-grid/opm-grid-config.cmake:287 (message):
  Incompatible value "4" of variable "DUNE_ISTL_VERSION_MINOR"
Call Stack (most recent call first):
  /home/and/src/opm-common/cmake/Modules/OpmFind.cmake:144 (find_package)
  /home/and/src/opm-common/cmake/Modules/OpmFind.cmake:211 (find_and_append_package_to)
  /home/and/src/opm-common/cmake/Modules/OpmLibMain.cmake:112 (find_and_append_package_list_to)
  CMakeLists.txt:112 (include)


CMake Warning at /home/and/src/opm-grid/opm-grid-config.cmake:291 (message):
  Incompatible value "1" of variable "DUNE_ISTL_VERSION_REVISION"
Call Stack (most recent call first):
  /home/and/src/opm-common/cmake/Modules/OpmFind.cmake:144 (find_package)
  /home/and/src/opm-common/cmake/Modules/OpmFind.cmake:211 (find_and_append_package_to)
  /home/and/src/opm-common/cmake/Modules/OpmLibMain.cmake:112 (find_and_append_package_list_to)
  CMakeLists.txt:112 (include)

i.e., even though the ISTL version provided by the opm-grid-config.cmake seems to be the same as the one as the one found by the Finddune-istl.cmake module, it still complains.

I would not care about that warning too much if it would not cause the version macros for dune-istl to be omitted from config.h which causes a build error for opm-simulators:

make
[...]
[ 14%] Building CXX object CMakeFiles/opmsimulators.dir/opm/autodiff/NewtonIterationBlackoilCPR.cpp.o
In file included from /home/and/src/opm-simulators/opm/autodiff/NewtonIterationBlackoilCPR.cpp:25:
/home/and/src/opm-simulators/opm/autodiff/DuneMatrix.hpp:87:36: error: no member named 'nnz' in 'Opm::DuneMatrix'
            size_type& nnz = this->nnz;
                             ~~~~  ^
/home/and/src/opm-simulators/opm/autodiff/DuneMatrix.hpp:88:51: error: no member named 'j' in 'Opm::DuneMatrix'
            std::shared_ptr<size_type>& j = this->j;
[...]

the same issue occurs on the system which runs ubuntu 16.10.

FindERT.cmake produces an error

With the latest git master versions of all opm modules and ERT i get the following error when trying to configure opm-core:

CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
  Could NOT find ERT (missing: HAVE_ERT)
Call Stack (most recent call first):
  /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
  /home/and/src/opm-common/cmake/Modules/FindERT.cmake:261 (find_package_handle_standard_args)
  /home/and/src/opm-common/cmake/Modules/OpmFind.cmake:147 (find_package)
  /home/and/src/opm-common/cmake/Modules/OpmFind.cmake:211 (find_and_append_package_to)
  /home/and/src/opm-common/cmake/Modules/OpmLibMain.cmake:112 (find_and_append_package_list_to)
  CMakeLists.txt:158 (include)

the relevant part of the CMakeErrors.txt file is:

/usr/bin/g++    -I/home/and/src/external/ert/install/include  -Wall -Wunused -Wno-overloaded-virtual -Wno-cast-align -fno-strict-aliasing -fstrict-overflow -g -DDEBUG=1 -pipe -fopenmp -pthread -std=c++11 -DHAVE_ERT   -o CMakeFiles/cmTC_2f27f.dir/src.cxx.o -c /home/and/src/opm-core/CMakeFiles/CMakeTmp/src.cxx
/home/and/src/opm-core/CMakeFiles/CMakeTmp/src.cxx: In function ‘int main()’:
/home/and/src/opm-core/CMakeFiles/CMakeTmp/src.cxx:4:5: error: no match for ‘operator[]’ (operand types are ‘ERT::EclKW<int>’ and ‘int’)
   kw[0] = 10;
     ^
CMakeFiles/cmTC_2f27f.dir/build.make:65: recipe for target 'CMakeFiles/cmTC_2f27f.dir/src.cxx.o' failed
make[1]: *** [CMakeFiles/cmTC_2f27f.dir/src.cxx.o] Error 1
make[1]: Leaving directory '/home/and/src/opm-core/CMakeFiles/CMakeTmp'
Makefile:126: recipe for target 'cmTC_2f27f/fast' failed
make: *** [cmTC_2f27f/fast] Error 2

Source file was:
#include <ert/ecl/EclKW.hpp>
int main ( ) {
  ERT::EclKW<int> kw("SATNUM" , 1000);
  kw[0] = 10;
  return 0;
}

after inspecting the ERT::EclKW class, it turns out that the compiler is right: it has no operator[](int), at least not within the file EclKW.hpp. The question is: is this an ommision on the ERT side or is the FindERT.cmake buggy?

opm-core detection doesn't work properly

When I try to compile ewoms without any OPM modules other than the mandatory ones (opm-common and opm-material), the build system fails:

cmake -DCMAKE_MODULE_PATH=""  "-Ddune-common_DIR=/usr/lib/x86_64-linux-gnu/cmake/dune-common" "-Ddune-geometry_DIR=/usr/lib/x86_64-linux-gnu/cmake/dune-geometry" "-Ddune-grid_DIR=/usr/lib/x86_64-linux-gnu/cmake/dune-grid" "-Ddune-istl_DIR=/usr/lib/cmake/dune-istl" "-Dopm-common_DIR=/home/and/tmp/src-ebos-master/opm-common/build-cmake" "-Dopm-material_DIR=/home/and/tmp/src-ebos-master/opm-material/build-cmake" "-Ddune-localfunctions_DIR=/usr/lib/cmake/dune-localfunctions" -DBUILD_TESTING=OFF -DCMAKE_C_FLAGS=" -Wall -Wunused -Wmissing-include-dirs -Wcast-align -fstrict-overflow -ffast-math -fno-finite-math-only -O3 -march=native -DNDEBUG=1" -DCMAKE_CXX_FLAGS=" -Wall -Wunused -Wmissing-include-dirs -Wcast-align -fstrict-overflow -ffast-math -fno-finite-math-only -O3 -march=native -DNDEBUG=1" "/home/and/tmp/src-ebos-master/ewoms"
-- The CXX compiler identification is GNU 5.4.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The C compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- CMake version: 3.5.1
-- Linux distribution: Ubuntu 16.04.3 LTS
-- Target architecture: x86_64
-- Found Git: /usr/bin/git (found version "2.7.4") 
-- Source code repository: git f4d70e9*%
-- GNU C++ compiler version: 5.4.0 20160609
-- Linker: gold 1.11
-- Checking to see if CXX compiler accepts flag -Wl,--enable-new-dtags
-- Checking to see if CXX compiler accepts flag -Wl,--enable-new-dtags - yes
-- Precompiled headers: disabled
-- Build type: Release
-- Checking to see if CXX compiler accepts flag -mtune=native
-- Checking to see if CXX compiler accepts flag -mtune=native - yes
-- OpenMP: disabled
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Checking to see if CXX compiler accepts flag -pthread
-- Checking to see if CXX compiler accepts flag -pthread - yes
-- Could NOT find CppCheck (missing:  CPPCHECK_PROGRAM) 
-- Disabling clang-check as CMAKE_EXPORT_COMPILE_COMMANDS is not enabled
-- Finding package CXX11Features using module mode
-- Checking to see if CXX compiler accepts flag -std=c++14
-- Checking to see if CXX compiler accepts flag -std=c++14 - yes
-- Performing Test HAVE_FINAL
-- Performing Test HAVE_FINAL - Success
-- Performing Test HAVE_TYPE_TRAITS
-- Performing Test HAVE_TYPE_TRAITS - Success
-- Performing Test HAVE_SHARED_PTR
-- Performing Test HAVE_SHARED_PTR - Success
-- Performing Test HAVE_UNIQUE_PTR
-- Performing Test HAVE_UNIQUE_PTR - Success
-- Performing Test HAVE_NULLPTR
-- Performing Test HAVE_NULLPTR - Success
-- Performing Test HAVE_CONSTEXPR
-- Performing Test HAVE_CONSTEXPR - Success
-- Performing Test HAVE_ARRAY
-- Performing Test HAVE_ARRAY - Success
-- Performing Test HAVE_INTEGRAL_CONSTANT
-- Performing Test HAVE_INTEGRAL_CONSTANT - Success
-- Looking for C++ include tuple
-- Looking for C++ include tuple - found
-- Looking for C++ include tr1/tuple
-- Looking for C++ include tr1/tuple - found
-- Performing Test HAVE_ATTRIBUTE_ALWAYS_INLINE
-- Performing Test HAVE_ATTRIBUTE_ALWAYS_INLINE - Success
-- Performing Test HAS_ATTRIBUTE_DEPRECATED
-- Performing Test HAS_ATTRIBUTE_DEPRECATED - Success
-- Performing Test HAS_ATTRIBUTE_DEPRECATED_MSG
-- Performing Test HAS_ATTRIBUTE_DEPRECATED_MSG - Success
-- Performing Test HAVE_STATIC_ASSERT
-- Performing Test HAVE_STATIC_ASSERT - Success
-- Performing Test HAVE_AUTO
-- Performing Test HAVE_AUTO - Success
-- Performing Test HAVE_VARIADIC_TEMPLATES
-- Performing Test HAVE_VARIADIC_TEMPLATES - Success
-- Performing Test HAVE_VARIADIC_CONSTRUCTOR_SFINAE
-- Performing Test HAVE_VARIADIC_CONSTRUCTOR_SFINAE - Success
-- Performing Test HAVE_RVALUE_REFERENCES
-- Performing Test HAVE_RVALUE_REFERENCES - Success
-- Looking for C++ include tr1/type_traits
-- Looking for C++ include tr1/type_traits - found
-- Finding package dune-common using module mode
-- Finding package BLAS using module mode
-- Looking for sgemm_
-- Looking for sgemm_ - found
-- A library with BLAS API found.
-- Finding package LAPACK using module mode
-- A library with BLAS API found.
-- Looking for cheev_
-- Looking for cheev_ - found
-- A library with LAPACK API found.
-- Finding package CxaDemangle using module mode
-- Performing Test HAVE_CXA_DEMANGLE
-- Performing Test HAVE_CXA_DEMANGLE - Success
-- Performing Test HAVE_DUNE_COMMON
-- Performing Test HAVE_DUNE_COMMON - Success
-- Found dune-common: /usr/include  
-- Version 2.4.1 of dune-common from /usr/lib/x86_64-linux-gnu/cmake/dune-common
-- Finding package dune-geometry using module mode
-- Performing Test HAVE_DUNE_GEOMETRY
-- Performing Test HAVE_DUNE_GEOMETRY - Success
-- Found dune-geometry: /usr/include  
-- Version 2.4.1 of dune-geometry from /usr/lib/x86_64-linux-gnu/cmake/dune-geometry
-- Finding package dune-grid using module mode
-- Finding package UG using module mode
CMake Warning at /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/FindUG.cmake:32 (message):
  Could not find file ug-config.cmake relative to given UG_ROOT
Call Stack (most recent call first):
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/FindUG.cmake:91 (opmFindUg)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:167 (find_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmPackage.cmake:99 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/Finddune-grid.cmake:17 (find_opm_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:167 (find_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:235 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmLibMain.cmake:122 (find_and_append_package_list_to)
  CMakeLists.txt:104 (include)


-- Performing Test HAVE_DUNE_GRID
-- Performing Test HAVE_DUNE_GRID - Success
-- Found dune-grid: /usr/include  
-- Version 2.4.1 of dune-grid from /usr/lib/x86_64-linux-gnu/cmake/dune-grid
-- Finding package dune-istl using module mode
-- Finding package ParMETIS using module mode
CMake Warning at /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/FindParMETIS.cmake:95 (message):
  MPI not found ==> ParMETIS disabled! Plase make sure -DUSE_MPI=ON was set
  if you need ParMETIS.
Call Stack (most recent call first):
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:167 (find_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmPackage.cmake:99 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/Finddune-istl.cmake:14 (find_opm_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:167 (find_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:235 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmLibMain.cmake:122 (find_and_append_package_list_to)
  CMakeLists.txt:104 (include)


-- Finding package SuperLU using module mode
-- Finding package SuiteSparse using module mode
-- Performing Test HAVE_UMFPACK_WITHOUT_CHOLMOD
-- Performing Test HAVE_UMFPACK_WITHOUT_CHOLMOD - Success
-- Found SuiteSparse: /usr/lib/x86_64-linux-gnu/libumfpack.so;/usr/lib/x86_64-linux-gnu/libamd.so  
-- Performing Test HAVE_DUNE_ISTL
-- Performing Test HAVE_DUNE_ISTL - Success
-- Found dune-istl: /usr/include;/usr/include/suitesparse  
-- Version 2.4.1 of dune-istl from /usr/lib/cmake/dune-istl
-- Finding package opm-common using module mode
-- Finding package C99 using module mode
-- Performing Test HAVE_C99
-- Performing Test HAVE_C99 - Success
-- Found C99: -std=c99  
-- Finding package Boost using module mode
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   system
--   unit_test_framework
-- Performing Test HAVE_OPM_COMMON
-- Performing Test HAVE_OPM_COMMON - Success
-- Found opm-common: /home/and/tmp/src-ebos-master/opm-common;/usr/include  
-- Performing Test HAVE_DYNAMIC_BOOST_TEST
-- Performing Test HAVE_DYNAMIC_BOOST_TEST - Success
-- Finding package opm-material using module mode
-- Finding package opm-parser using module mode
CMake Warning at /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/Findopm-parser.cmake:47 (find_package):
  Could not find a package configuration file provided by "opm-parser" with
  any of the following names:

    opm-parserConfig.cmake
    opm-parser-config.cmake

  Add the installation prefix of "opm-parser" to CMAKE_PREFIX_PATH or set
  "opm-parser_DIR" to a directory containing one of the above files.  If
  "opm-parser" provides a separate development package or SDK, be sure it has
  been installed.
Call Stack (most recent call first):
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:167 (find_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmPackage.cmake:99 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/Findopm-material.cmake:16 (find_opm_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:167 (find_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:235 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmLibMain.cmake:122 (find_and_append_package_list_to)
  CMakeLists.txt:104 (include)


-- Finding package Valgrind using module mode
-- Found VALGRIND: /usr/include  
-- Performing Test HAVE_OPM_MATERIAL
-- Performing Test HAVE_OPM_MATERIAL - Success
-- Found opm-material: /home/and/tmp/src-ebos-master/opm-material;/home/and/tmp/src-ebos-master/opm-common;/usr/include  
-- Performing Test HAVE_DYNAMIC_BOOST_TEST
-- Performing Test HAVE_DYNAMIC_BOOST_TEST - Success
-- Finding package dune-localfunctions using module mode
-- Performing Test HAVE_DUNE_LOCALFUNCTIONS
-- Performing Test HAVE_DUNE_LOCALFUNCTIONS - Success
-- Found dune-localfunctions: /usr/include  
-- Version 2.4.1 of dune-localfunctions from /usr/lib/cmake/dune-localfunctions
-- Finding package dune-alugrid using module mode
CMake Warning at /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmPackage.cmake:85 (find_package):
  Could not find a package configuration file provided by "dune-alugrid" with
  any of the following names:

    dune-alugridConfig.cmake
    dune-alugrid-config.cmake

  Add the installation prefix of "dune-alugrid" to CMAKE_PREFIX_PATH or set
  "dune-alugrid_DIR" to a directory containing one of the above files.  If
  "dune-alugrid" provides a separate development package or SDK, be sure it
  has been installed.
Call Stack (most recent call first):
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/Finddune-alugrid.cmake:15 (find_opm_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:167 (find_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:235 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmLibMain.cmake:122 (find_and_append_package_list_to)
  CMakeLists.txt:104 (include)


-- Finding package ZLIB using module mode
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.8") 
-- Finding package ZOLTAN using module mode
-- Could NOT find PTScotch (missing:  PTSCOTCH_INCLUDE_DIR SCOTCH_LIBRARY PTSCOTCH_LIBRARY PTSCOTCHERR_LIBRARY) 
-- Found ZOLTAN: /usr/lib/x86_64-linux-gnu/libtrilinos_zoltan.so  
-- Finding package METIS using module mode
-- Could NOT find METIS (missing:  METIS_LIBRARIES METIS_INCLUDE_DIRS) 
-- Performing Test HAVE_DUNE_ALUGRID
-- Performing Test HAVE_DUNE_ALUGRID - Failed
-- Could NOT find dune-alugrid (missing:  dune-alugrid_FOUND) 
CMake Warning at /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmPackage.cmake:85 (find_package):
  Could not find a package configuration file provided by "dune-alugrid" with
  any of the following names:

    dune-alugridConfig.cmake
    dune-alugrid-config.cmake

  Add the installation prefix of "dune-alugrid" to CMAKE_PREFIX_PATH or set
  "dune-alugrid_DIR" to a directory containing one of the above files.  If
  "dune-alugrid" provides a separate development package or SDK, be sure it
  has been installed.
Call Stack (most recent call first):
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/Finddune-alugrid.cmake:49 (find_opm_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:167 (find_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:235 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmLibMain.cmake:122 (find_and_append_package_list_to)
  CMakeLists.txt:104 (include)


-- Could NOT find dune-alugrid (missing:  dune-alugrid_FOUND) 
-- Finding package dune-fem using module mode
CMake Warning at /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmPackage.cmake:85 (find_package):
  Could not find a package configuration file provided by "dune-fem" with any
  of the following names:

    dune-femConfig.cmake
    dune-fem-config.cmake

  Add the installation prefix of "dune-fem" to CMAKE_PREFIX_PATH or set
  "dune-fem_DIR" to a directory containing one of the above files.  If
  "dune-fem" provides a separate development package or SDK, be sure it has
  been installed.
Call Stack (most recent call first):
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/Finddune-fem.cmake:14 (find_opm_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:167 (find_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:235 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmLibMain.cmake:122 (find_and_append_package_list_to)
  CMakeLists.txt:104 (include)


-- Performing Test HAVE_DUNE_FEM
-- Performing Test HAVE_DUNE_FEM - Failed
-- Could NOT find dune-fem (missing:  dune-fem_FOUND) 
-- Finding package opm-grid using module mode
CMake Warning at /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmPackage.cmake:85 (find_package):
  Could not find a package configuration file provided by "opm-grid" with any
  of the following names:

    opm-gridConfig.cmake
    opm-grid-config.cmake

  Add the installation prefix of "opm-grid" to CMAKE_PREFIX_PATH or set
  "opm-grid_DIR" to a directory containing one of the above files.  If
  "opm-grid" provides a separate development package or SDK, be sure it has
  been installed.
Call Stack (most recent call first):
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/Findopm-grid.cmake:15 (find_opm_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:167 (find_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:235 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmLibMain.cmake:122 (find_and_append_package_list_to)
  CMakeLists.txt:104 (include)


-- Performing Test HAVE_OPM_GRID
-- Performing Test HAVE_OPM_GRID - Failed
-- Could NOT find opm-grid (missing:  opm-grid_FOUND opm-grid_ALL_PREREQS) 
-- Finding package opm-core using module mode
CMake Warning at /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmPackage.cmake:85 (find_package):
  Could not find a package configuration file provided by "opm-core" with any
  of the following names:

    opm-coreConfig.cmake
    opm-core-config.cmake

  Add the installation prefix of "opm-core" to CMAKE_PREFIX_PATH or set
  "opm-core_DIR" to a directory containing one of the above files.  If
  "opm-core" provides a separate development package or SDK, be sure it has
  been installed.
Call Stack (most recent call first):
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/Findopm-core.cmake:16 (find_opm_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:167 (find_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:235 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmLibMain.cmake:122 (find_and_append_package_list_to)
  CMakeLists.txt:104 (include)


-- Finding package ecl using module mode
CMake Error at /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:163 (list):
  list sub-command REMOVE_ITEM requires list to be present.
Call Stack (most recent call first):
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmPackage.cmake:99 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/Findopm-core.cmake:16 (find_opm_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:167 (find_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:235 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmLibMain.cmake:122 (find_and_append_package_list_to)
  CMakeLists.txt:104 (include)


CMake Warning at /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:164 (find_package):
  Could not find a package configuration file provided by "ecl" with any of
  the following names:

    eclConfig.cmake
    ecl-config.cmake

  Add the installation prefix of "ecl" to CMAKE_PREFIX_PATH or set "ecl_DIR"
  to a directory containing one of the above files.  If "ecl" provides a
  separate development package or SDK, be sure it has been installed.
Call Stack (most recent call first):
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmPackage.cmake:99 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/Findopm-core.cmake:16 (find_opm_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:167 (find_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:235 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmLibMain.cmake:122 (find_and_append_package_list_to)
  CMakeLists.txt:104 (include)


-- Finding package PETSc using module mode
-- Finding package opm-output using module mode
CMake Warning at /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmPackage.cmake:85 (find_package):
  Could not find a package configuration file provided by "opm-output" with
  any of the following names:

    opm-outputConfig.cmake
    opm-output-config.cmake

  Add the installation prefix of "opm-output" to CMAKE_PREFIX_PATH or set
  "opm-output_DIR" to a directory containing one of the above files.  If
  "opm-output" provides a separate development package or SDK, be sure it has
  been installed.
Call Stack (most recent call first):
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/Findopm-output.cmake:16 (find_opm_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:167 (find_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmPackage.cmake:99 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/Findopm-core.cmake:16 (find_opm_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:167 (find_package)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmFind.cmake:235 (find_and_append_package_to)
  /home/and/tmp/src-ebos-master/opm-common/cmake/Modules/OpmLibMain.cmake:122 (find_and_append_package_list_to)
  CMakeLists.txt:104 (include)


-- Performing Test HAVE_OPM_OUTPUT
-- Performing Test HAVE_OPM_OUTPUT - Failed
-- Could NOT find opm-output (missing:  opm-output_FOUND opm-output_ALL_PREREQS) 
-- Performing Test HAVE_DYNAMIC_BOOST_TEST
-- Performing Test HAVE_DYNAMIC_BOOST_TEST - Success
-- Performing Test HAVE_OPM_CORE
-- Performing Test HAVE_OPM_CORE - Success
-- Could NOT find opm-core (missing:  opm-core_FOUND opm-core_ALL_PREREQS) 
-- Performing Test HAVE_DYNAMIC_BOOST_TEST
-- Performing Test HAVE_DYNAMIC_BOOST_TEST - Success
-- Finding package Quadmath using module mode
-- Performing Test HAVE_EXTENDED_NUMERIC_LITERALS
-- Performing Test HAVE_EXTENDED_NUMERIC_LITERALS - Success
-- Performing Test QUADMATH_FOUND
-- Performing Test QUADMATH_FOUND - Success
-- Found Quadmath: quadmath  
-- Generating debug symbols: -ggdb3
-- Looking for strip utility
-- Looking for strip utility - found
-- Performing Test HAVE_DYNAMIC_BOOST_TEST
-- Performing Test HAVE_DYNAMIC_BOOST_TEST - Success
-- Writing config file "/home/and/tmp/src-ebos-master/ewoms/build-cmake/config.h"...
-- This build defaults to installing in /usr/local
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.11") 
-- Writing version information to local header project-version.h
-- Configuring incomplete, errors occurred!
See also "/home/and/tmp/src-ebos-master/ewoms/build-cmake/CMakeFiles/CMakeOutput.log".
See also "/home/and/tmp/src-ebos-master/ewoms/build-cmake/CMakeFiles/CMakeError.log".

The two mentioned logfiles contain exactly zero indication of why this is the case, but if I remove the optional OPM modules from ewoms-prereqs.cmake, it works fine. On closer inspection, it turned out that only opm-core needed to be removed, which brought my attention to the following gem in the output above:

-- Performing Test HAVE_OPM_CORE
-- Performing Test HAVE_OPM_CORE - Success
-- Could NOT find opm-core (missing:  opm-core_FOUND opm-core_ALL_PREREQS) 

(by now it is probably needless to say that with the dune build system everything worked fine out of the box.)

ROCKTAB: Error Message Confusion.

If the ROCKTAB keyword is in the input deck then Flow aborts with the following error message:

Failed to create valid EclipseState object.
Exception caught: Incorrect ordering of values in column: PO
terminate called after throwing an instance of 'std::invalid_argument'
  what():  Incorrect ordering of values in column: PO
[EIPC02-VirtualBox:02722] *** Process received signal ***
[EIPC02-VirtualBox:02722] Signal: Aborted (6)
[EIPC02-VirtualBox:02722] Signal code:  (-6)
[EIPC02-VirtualBox:02722] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20)[0x7f2b94701f20]
[EIPC02-VirtualBox:02722] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f2b94701e97]
[EIPC02-VirtualBox:02722] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f2b94703801]
[EIPC02-VirtualBox:02722] [ 3] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x8c8fb)[0x7f2b94d588fb]
[EIPC02-VirtualBox:02722] [ 4] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x92d3a)[0x7f2b94d5ed3a]
[EIPC02-VirtualBox:02722] [ 5] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x92d95)[0x7f2b94d5ed95]
[EIPC02-VirtualBox:02722] [ 6] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(__cxa_rethrow+0x4d)[0x7f2b94d5f03d]
[EIPC02-VirtualBox:02722] [ 7] flow(main+0x9f3)[0x564b7258fbc3]
[EIPC02-VirtualBox:02722] [ 8] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f2b946e4b97]
[EIPC02-VirtualBox:02722] [ 9] flow(_start+0x2a)[0x564b7259022a]
[EIPC02-VirtualBox:02722] *** End of error message ***
Aborted (core dumped)

This took a long time to find so it would be useful if the error message could be changed to be more informative.

To re-produce one needs to put the following in the RUNSPEC section

--
--       ROCK   NUMBER   WAT     POR-TRAN                                       
--       OPTN   TABLES   INDUCE  OPTION                                         
ROCKCOMP                                                                        
         REVERS 1                                                              /                                                                                

And the following in the PROPS section

--                                                                                     
--       ROCK COMPACTION TABLES                                                                  
--                                                    
ROCKTAB
--       PRESS    PORV     TX(YZ)   TY       TZ                                                     
--                MULT     MULT     MULT     MULT                                               
--       ------   ------   ------   ------   ------                                                
          100.0   0.9600   0.9650                    
          150.0   0.9800   0.9850                      
          175.0   0.9900   0.9950                     
          200.0   1.0000   1.0000                   
          250.0   1.0100   1.0100                          / TABLE NO. 01

Completions versus connections

The code in opm-common has up until now been developed with the misunderstanding that completion and connection are synonyms. With the advent of the keyword COMPLUMP that turns out to not be the case. My current understanding of the situation is:

connection: This a well-cell which is connected to reservoir; i fluids flow between the reservoir and the well through a connection.

completion: Possibility to group several connections together, and then treat the collection of connections as logical entity in e.g. WECON and similar keywords. The logical entity completion is created with the COMPLUMPkeyword where several connections are "lumped" together in a completion.

The important distinction between connections and completions come in the automatic workover routines implemented by the XECON keywords, where the keywords can be configured to:

... close the most offending connection.

Iff the COMPLUMP functionality is in place the simulator will close the most offending completion, i.e. set of connections, in one go. Currently the OPM codebase has no awareness of the distinction between connections and completions - and can therefor not support this distintion.

Supporting this properly will require changes both to the simulator and the input layer. My current plan for the input layer is as follows:

1. Rename the classes Completion and CompletionSet to Connection and ConnectionSet - that is already underway here: #419

2. An ID is added to the Connection class. This is ID is unique (and arbitrary) for individual connections, and all connections in the same completion have the same ID.

3. A method ConnectionSet::workoverConnections( id??) will return a list of connections, either with only one element if COMPLUMP is not active, or all the elements in the completion if COMPLUMPis active.

Because we must be able to treat single connections (no COMPLUMP) and completions (i.e. groups of connections) transparently I do not think it is wise to create a separate Completion datastructure.

I have misunderstood this for years, so there might still be misunderstandings looming. Clarifications greatly appreciated.

Duplicate targets

This is a cross-repo issue, but I post it here since it involves the build system.

I just recently got the following message from cmake in dune-cornerpoint:

CMake Error at CMakeLists.txt:112 (add_custom_target):
  add_custom_target cannot create target "check-commits" because another
  target with the same name already exists.  The existing target is a custom
  target created in source directory
  "/Users/atgeirr/opm-build-debug/dune-cornerpoint".  See documentation for
  policy CMP0002 for more details.

Apparently, this target is added both by opm-cmake/cmake/OpmLibMain.cmake and the CMakeLists.txt of some of the modules. I guess that it should be removed from the module-specific files? At least that appears to work for dune-cornerpoint, but I wanted to hear from the cmake experts if this is indeed the correct fix. (Also, a mystery: why did I not experience this before, the conflict has been there since May 28?)

Remove messagecontainer

Before mergin opm-parser into opm-common it was a point that opm-parser should be standalone; i.e. it could not depend on code from opm-common. Specifically this implied that the logging framework was not available to code in opm-parser, and instead a utility class MessageContainer was created to temporarily hold on to messages generated during the parsing process, and then subsequently replayed to the logging system afterwards.

Now that the parser code has access to the logger the code should issue normal logging calls and the MessageContainerclass should be removed.

MPI detection is inconsistent with DUNE's

when I do not specify anything MPI related on my machine, the dune 2.5 build system detects and enables MPI but the OPM build system does not. note that this could be different with dune 2.4 or dune 2.6-rc1.

Also, the OPM build system does not seem to honor DUNE's ENABLE_$FOO mechanism, in particular the ENABLE_MPI flag.

Building issue in a cluster

Hello, I had the following problem when I was trying to build opm-common in a cluster Stampede2 (https://www.tacc.utexas.edu/systems/stampede2).
I was able to build all the modules (dune-common dune-istl dune-geometry dune-grid libecl opm-common opm-parser opm-grid opm-material opm-output ewoms opm-simulators) in my local macbook in the same way. However, it did not somehow work in the cluster with gcc compiler. Can you tell why this happened? It looks like a Boost issue. I tried both Boost already installed in the system and the one I manually installed, but both of them did not work.

---

-- The C compiler identification is GNU 4.8.5
-- The CXX compiler identification is GNU 4.8.5
-- Check for working C compiler: /bin/cc
-- Check for working C compiler: /bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /bin/c++
-- Check for working CXX compiler: /bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- CMake version: 2.8.12.2
-- Linux distribution: CentOS Linux 7 (Core)
-- Target architecture: x86_64
-- Found Git: /opt/apps/git/2.9.0/bin/git (found version "2.9.0")
-- Source code repository: git 8ab7beb
-- GNU C++ compiler version: 4.8.5
-- Linker: ld 2.25.1-32.base.el7_4.2
-- Checking to see if CXX compiler accepts flag -Wl,--enable-new-dtags
-- Checking to see if CXX compiler accepts flag -Wl,--enable-new-dtags - yes
-- Precompiled headers: disabled
-- Build type: Release
-- Checking to see if CXX compiler accepts flag -mtune=native
-- Checking to see if CXX compiler accepts flag -mtune=native - yes
-- All warnings enabled: -Wall
-- OpenMP: disabled
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Checking to see if CXX compiler accepts flag -pthread
-- Checking to see if CXX compiler accepts flag -pthread - yes
-- Could NOT find CppCheck (missing: CPPCHECK_PROGRAM)
-- Disabling clang-check as CMAKE_EXPORT_COMPILE_COMMANDS is not enabled
-- Performing Test HAVE_C99
-- Performing Test HAVE_C99 - Success
-- Found C99: -std=c99
-- Checking to see if CXX compiler accepts flag -std=c++14
-- Checking to see if CXX compiler accepts flag -std=c++14 - no
-- Checking to see if CXX compiler accepts flag -std=c++11
-- Checking to see if CXX compiler accepts flag -std=c++11 - yes
-- Performing Test HAVE_FINAL
-- Performing Test HAVE_FINAL - Success
-- Performing Test HAVE_TYPE_TRAITS
-- Performing Test HAVE_TYPE_TRAITS - Success
-- Performing Test HAVE_SHARED_PTR
-- Performing Test HAVE_SHARED_PTR - Success
-- Performing Test HAVE_UNIQUE_PTR
-- Performing Test HAVE_UNIQUE_PTR - Success
-- Performing Test HAVE_NULLPTR
-- Performing Test HAVE_NULLPTR - Success
-- Performing Test HAVE_CONSTEXPR
-- Performing Test HAVE_CONSTEXPR - Success
-- Performing Test HAVE_ARRAY
-- Performing Test HAVE_ARRAY - Success
-- Performing Test HAVE_INTEGRAL_CONSTANT
-- Performing Test HAVE_INTEGRAL_CONSTANT - Success
-- Looking for C++ include tuple
-- Looking for C++ include tuple - found
-- Looking for C++ include tr1/tuple
-- Looking for C++ include tr1/tuple - found
-- Performing Test HAVE_ATTRIBUTE_ALWAYS_INLINE
-- Performing Test HAVE_ATTRIBUTE_ALWAYS_INLINE - Success
-- Performing Test HAS_ATTRIBUTE_UNUSED
-- Performing Test HAS_ATTRIBUTE_UNUSED - Success
-- Performing Test HAS_ATTRIBUTE_DEPRECATED
-- Performing Test HAS_ATTRIBUTE_DEPRECATED - Success
-- Performing Test HAS_ATTRIBUTE_DEPRECATED_MSG
-- Performing Test HAS_ATTRIBUTE_DEPRECATED_MSG - Success
-- Performing Test HAVE_STATIC_ASSERT
-- Performing Test HAVE_STATIC_ASSERT - Success
-- Performing Test HAVE_AUTO
-- Performing Test HAVE_AUTO - Success
-- Performing Test HAVE_VARIADIC_TEMPLATES
-- Performing Test HAVE_VARIADIC_TEMPLATES - Success
-- Performing Test HAVE_VARIADIC_CONSTRUCTOR_SFINAE
-- Performing Test HAVE_VARIADIC_CONSTRUCTOR_SFINAE - Success
-- Performing Test HAVE_RVALUE_REFERENCES
-- Performing Test HAVE_RVALUE_REFERENCES - Success
-- Looking for C++ include tr1/type_traits
-- Looking for C++ include tr1/type_traits - found
-- Boost version: 1.64.0
-- Found the following Boost libraries:
-- system
-- unit_test_framework
-- Generating debug symbols: -ggdb3
-- Looking for strip utility
-- Looking for strip utility - found
-- Performing Test HAVE_DYNAMIC_BOOST_TEST
-- Performing Test HAVE_DYNAMIC_BOOST_TEST - Failed
-- Writing config file "/work/02552/sogoogos/rmine/OPM_20180221/opm-common/cmake-build-release/config.h"...
-- This build defaults to installing in /work/02552/sogoogos/rmine/foo_20180221
-- Found Doxygen: /bin/doxygen (found version "1.8.5")
-- Writing version information to local header project-version.h
-- Configuring done
-- Generating done
-- Build files have been written to: /work/02552/sogoogos/rmine/OPM_20180221/opm-common/cmake-build-release

-------------------------------
....
Linking CXX static library lib/libopmcommon.a
[ 64%] Built target opmcommon
Scanning dependencies of target test_OpmLog
Scanning dependencies of target test_SimulationDataContainer
[ 72%] [ 72%] Building CXX object CMakeFiles/test_SimulationDataContainer.dir/tests/test_SimulationDataContainer.cpp.o
Building CXX object CMakeFiles/test_OpmLog.dir/tests/test_OpmLog.cpp.o
Linking CXX executable bin/test_SimulationDataContainer
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crt1.o: In function _start': (.text+0x20): undefined reference tomain'
CMakeFiles/test_SimulationDataContainer.dir/tests/test_SimulationDataContainer.cpp.o: In function boost::unit_test::make_test_case(boost::function<void ()> const&, boost::unit_test::basic_cstring<char const>, boost::unit_test::basic_cstring<char const>, unsigned long)': test_SimulationDataContainer.cpp:(.text._ZN5boost9unit_test14make_test_caseERKNS_8functionIFvvEEENS0_13basic_cstringIKcEES8_m[_ZN5boost9unit_test14make_test_caseERKNS_8functionIFvvEEENS0_13basic_cstringIKcEES8_m]+0x20): undefined reference toboost::unit_test::ut_detail::normalize_test_case_name(boost::unit_test::basic_cstring)'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_timer.so.1.64.0: undefined reference to VTT for std::__cxx11::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_system.so: undefined reference tostd::__cxx11::basic_string<char, std::char_traits, std::allocator >::_M_create(unsigned long&, unsigned long)@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::operator=(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&)@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_stringbuf<char, std::char_traits, std::allocator >::str() const@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >::basic_stringstream(std::_Ios_Openmode)@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_string<char, std::char_traits, std::allocator >::_M_append(char const*, unsigned long)@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::runtime_error::runtime_error(std::runtime_error const&)@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_string<char, std::char_traits, std::allocator >::_M_replace(unsigned long, unsigned long, char const*, unsigned long)@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct(unsigned long, char)@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tovtable for std::__cxx11::basic_stringbuf<char, std::char_traits, std::allocator >@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_timer.so.1.64.0: undefined reference to vtable for std::__cxx11::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_string<char, std::char_traits, std::allocator >::_M_assign(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_istringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_istringstream()@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tovtable for std::__cxx11::basic_istringstream<char, std::char_traits, std::allocator >@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::runtime_error::runtime_error(char const*)@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference totypeinfo for std::__cxx11::basic_ostringstream<char, std::char_traits, std::allocator >@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to vtable for std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_string<char, std::char_traits, std::allocator >::reserve(unsigned long)@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to VTT for std::__cxx11::basic_istringstream<char, std::char_traits<char>, std::allocator<char> >@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::runtime_error::runtime_error(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_string<char, std::char_traits, std::allocator >::rfind(char, unsigned long) const@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::_M_sync(char*, unsigned long, unsigned long)@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_ostringstream<char, std::char_traits, std::allocator >::~basic_ostringstream()@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::runtime_error::runtime_error(char const*)@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_ostringstream<char, std::char_traits, std::allocator >::basic_ostringstream(std::_Ios_Openmode)@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_system.so: undefined reference to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_string<char, std::char_traits, std::allocator >::append(char const*)@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_ostringstream()@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference toVTT for std::__cxx11::basic_ostringstream<char, std::char_traits, std::allocator >@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_system.so: undefined reference to operator delete(void*, unsigned long)@CXXABI_1.3.9' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_string<char, std::char_traits, std::allocator >::find(char const*, unsigned long, unsigned long) const@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_istringstream<char, std::char_traits<char>, std::allocator<char> >::basic_istringstream(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::_Ios_Openmode)@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_stringstream<char, std::char_traits, std::allocator >::~basic_stringstream()@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::runtime_error::runtime_error(std::runtime_error const&)@GLIBCXX_3.4.21' collect2: error: ld returned 1 exit status make[2]: *** [bin/test_SimulationDataContainer] Error 1 make[1]: *** [CMakeFiles/test_SimulationDataContainer.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... Linking CXX executable bin/test_OpmLog /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crt1.o: In function_start':
(.text+0x20): undefined reference to main' CMakeFiles/test_OpmLog.dir/tests/test_OpmLog.cpp.o: In functionboost::unit_test::make_test_case(boost::function<void ()> const&, boost::unit_test::basic_cstring, boost::unit_test::basic_cstring, unsigned long)':
test_OpmLog.cpp:(.text._ZN5boost9unit_test14make_test_caseERKNS_8functionIFvvEEENS0_13basic_cstringIKcEES8_m[_ZN5boost9unit_test14make_test_caseERKNS_8functionIFvvEEENS0_13basic_cstringIKcEES8_m]+0x20): undefined reference to boost::unit_test::ut_detail::normalize_test_case_name(boost::unit_test::basic_cstring<char const>)' /opt/apps/gcc7_1/boost/1.64/lib/libboost_timer.so.1.64.0: undefined reference toVTT for std::__cxx11::basic_stringstream<char, std::char_traits, std::allocator >@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_system.so: undefined reference to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned long&, unsigned long)@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_string<char, std::char_traits, std::allocator >::operator=(std::__cxx11::basic_string<char, std::char_traits, std::allocator >&&)@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::str() const@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_stringstream<char, std::char_traits, std::allocator >::basic_stringstream(std::_Ios_Openmode)@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_append(char const*, unsigned long)@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::runtime_error::runtime_error(std::runtime_error const&)@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned long, unsigned long, char const*, unsigned long)@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_string<char, std::char_traits, std::allocator >::_M_construct(unsigned long, char)@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to vtable for std::__cxx11::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_timer.so.1.64.0: undefined reference tovtable for std::__cxx11::basic_stringstream<char, std::char_traits, std::allocator >@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_assign(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_istringstream<char, std::char_traits, std::allocator >::~basic_istringstream()@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to vtable for std::__cxx11::basic_istringstream<char, std::char_traits<char>, std::allocator<char> >@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::runtime_error::runtime_error(char const*)@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to typeinfo for std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tovtable for std::__cxx11::basic_ostringstream<char, std::char_traits, std::allocator >@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::reserve(unsigned long)@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference toVTT for std::__cxx11::basic_istringstream<char, std::char_traits, std::allocator >@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::runtime_error::runtime_error(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::rfind(char, unsigned long) const@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_stringbuf<char, std::char_traits, std::allocator >::_M_sync(char*, unsigned long, unsigned long)@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_ostringstream()@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::runtime_error::runtime_error(char const*)@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::basic_ostringstream(std::_Ios_Openmode)@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_system.so: undefined reference tostd::__cxx11::basic_string<char, std::char_traits, std::allocator >::~basic_string()@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::append(char const*)@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_ostringstream<char, std::char_traits, std::allocator >::~basic_ostringstream()@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to VTT for std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_system.so: undefined reference tooperator delete(void*, unsigned long)@CXXABI_1.3.9'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::find(char const*, unsigned long, unsigned long) const@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::__cxx11::basic_istringstream<char, std::char_traits, std::allocator >::basic_istringstream(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::_Ios_Openmode)@GLIBCXX_3.4.21'
/opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference to std::__cxx11::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_stringstream()@GLIBCXX_3.4.21' /opt/apps/gcc7_1/boost/1.64/lib/libboost_unit_test_framework.so: undefined reference tostd::runtime_error::runtime_error(std::runtime_error const&)@GLIBCXX_3.4.21'
collect2: error: ld returned 1 exit status
make[2]: *** [bin/test_OpmLog] Error 1
make[1]: *** [CMakeFiles/test_OpmLog.dir/all] Error 2
make: *** [all] Error 2

Setting the package version

Hello;

as identified by @blattms here: OPM/opm-parser#1109 opm-parser does not set the PACKAGE_VERSION variable. I would like to fix that - but it is not entirely clear to me what version string/number should be used?

HAVE_OPM_COMMON - Failed

Hi!

Currently all modules that have OPM-COMMON in their prereq fails the test. It is of course an irony, since the test is found in OPM-COMMON. It doesn't find itself. Many of us have that problem...

Anyway - should I dig into this, or is it blatantly obvious (me not being a cmake knowledgeable person)?

Since the prereq is not REQUIRED in most modules, things just continue smoothly. But some modules (opm-benchmarks, opm-polymer, opm-upscaling, opm-verteq) have opm-common as REQUIRED, and thus won't continue.

I guess one of these two alternatives apply:

A) This should work - you're doing something wrong (help appreciated)
B) This currently doesn't work / make sense, since we have no code/headers in the module (thus we should remove the REQUIRED on the modules having it as such?)

Thank you

About #include "config.h"

Can someone remind me under what kind of circumstances, we need to add #include "config.h" and why exactly? It looks like something related to Dune. The compilation error refer to mpihelper from Dune.

find_package( ) does not set ${opm-common_INCLUDE_DIR}?

I do the following:

1. Check out opm-common in a random location and install to /tmp/opm/install
2. Check out opm-parser in another random location, configure with -DCMAKE_PREFIX_PATH=/tmp/opm/install

What happens then is that this find_package(opm-common): https://github.com/OPM/opm-parser/blob/master/CMakeLists.txt#L16 works - finding opm-common, however the ${opm-common_INCLUDE_DIR} variable is not set - and the build of the parser will fail afterwards. If opm-parser finds opm-common in the sibling location the ${opm-common_INCLUDE_DIR} variable is correctly set.

It is not clear to me if this is a bug in the parser build system or in the opm-common module; I am quite at a loss here and we be grateful for some hints.

Error on libray

The Simulator stop working around a week ago.

I try to reinstall it and I get an error during installation.
It says that:

The following packages have unmet dependencies:
libopm-output1: Depends: libecl1 but it is not going to be installed
libopm-parser1: Depends: libecl1 but it is not going to be installed
libopm-simulators1: Depends: libecl1 but it is not going to be installed
libopm-simulators1-bin: Depends: libecl1 but it is not going to be installed
E. Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution)

when using that line "apt-get -f install"

It states that

dpkg: Error processing archive /var/cache/apt/archives/libecl1_2017.10-rfinal-1-xenial_amd64.deb (--unpack)

Can you help me by telling what went wrong or tell me how to delete Flow in order to try a reinstall from zero.

Thanks