doxyfiles are broken. this causes issues on EL5 where doxygen won't silently ignore them. in particular

@abs_top_srcdir@/tests/not-unit/blackoil/simpleSPE9/blac
koil_sim_test.txt \
@abs_top_srcdir@/tests/not-unit/blackoil/CO2/co2_sim_test.txt

with friends are not in the repo.

With @blattms' changes to opm-core and dune-cornerpoint applied the opm-porsol module does not compile for the latest master versions anymore:

and@heuristix:~/src/opm-porsol|master > make
[ 27%] Built target opmporsol
[ 31%] Building CXX object CMakeFiles/aniso_implicitcap_test.dir/examples/aniso_implicitcap_test.cpp.o
In file included from /home/and/src/opm-porsol/examples/aniso_implicitcap_test.cpp:42:
In file included from /home/and/src/opm-porsol/examples/SimulatorTester.hpp:40:
In file included from /home/and/src/opm-porsol/opm/porsol/common/SimulatorBase.hpp:49:
In file included from /home/and/src/dune-cornerpoint/dune/grid/CpGrid.hpp:47:
/home/and/src/dune-cornerpoint/dune/grid/cpgrid/CpGridData.hpp:517:1: warning: 'Mover' defined as a struct template here but previously declared as a class template [-Wmismatched-tags]
struct Mover
^
/home/and/src/dune-cornerpoint/dune/grid/cpgrid/CpGridData.hpp:99:37: note: did you mean struct here?
    template<class T, int i> friend class mover::Mover;
                                    ^~~~~
                                    struct                                                                                                                                                                                                                                     
/home/and/src/dune-cornerpoint/dune/grid/cpgrid/CpGridData.hpp:90:26: note: did you mean struct here?
template<class T, int i> class Mover;
                         ^~~~~
                         struct                                                                                                                                                                                                                                                
/home/and/src/dune-cornerpoint/dune/grid/cpgrid/CpGridData.hpp:551:31: error: implicit instantiation of undefined template 'Dune::cpgrid::Entity<0>'
        Entity<0> from_entity=Entity<0>(*gatherView_, from_cell_index, true);
                              ^
/home/and/src/dune-cornerpoint/dune/grid/cpgrid/CpGridData.hpp:406:32: note: template is declared here
[...]

I'm experiencing a compile error on both openSUSE 12.2 (GCC 4.7.1) and Fedora 17 (GCC 4.7.0).

I'm using the newest versions of Dune 2.2 via svn, and the newest versions of OPM from github. Specifically opm-porsol's latest commit is b313849.

I simply place all of the relevant dune and opm modules in the same directory and call "dune-common/bin/dunecontrol all" to build.

I can't make sense of the error since the relevant code looks correct to me. Could it be a bug in GCC 4.7?

The opm-porsol part of the output of "dunecontrol all" is here: http://pastebin.com/7zTeq7AW
Here is the actual error:

../dune/porsol/euler/ImplicitCapillarity_impl.hpp: In instantiation of ‘void Dune::ImplicitCapillarity<GridInterface, ReservoirProperties, BoundaryConditions, InnerProd>::init(const Opm::parameter::ParameterGroup&, const GI&, const RP&, const BC&) [with GridInterface = Dune::GridInterfaceEulerDune::CpGrid; ReservoirProperties = Dune::ReservoirPropertyCapillaryAnisotropicRelperm<3>; BoundaryConditions = Dune::BasicBoundaryConditions<true, true>; InnerProd = Dune::Anisotropic::InnerProduct; Dune::ImplicitCapillarity<GridInterface, ReservoirProperties, BoundaryConditions, InnerProd>::RP = Dune::ReservoirPropertyCapillaryAnisotropicRelperm<3>]’:
../dune/porsol/common/SimulatorBase.hpp:212:6: required from ‘void Dune::SimulatorBase::initSolvers(const Opm::parameter::ParameterGroup&) [with SimTraits = Dune::SimulatorTraits<Dune::Anisotropic, Dune::ImplicitCap>]’
../dune/porsol/common/SimulatorBase.hpp:104:6: required from ‘void Dune::SimulatorBase::init(const Opm::parameter::ParameterGroup&) [with SimTraits = Dune::SimulatorTraits<Dune::Anisotropic, Dune::ImplicitCap>]’
aniso_implicitcap_test.cpp:69:19: required from here
../dune/porsol/euler/ImplicitCapillarity_impl.hpp:106:2: error: no matching function for call to ‘Dune::ImplicitCapillarityDune::GridInterfaceEuler<Dune::CpGrid, Dune::ReservoirPropertyCapillaryAnisotropicRelperm<3>, Dune::BasicBoundaryConditions<true, true>, Dune::Anisotropic::InnerProduct>::initObj(const Dune::GridInterfaceEulerDune::CpGrid&, const RP&, const Dune::BasicBoundaryConditions<true, true>&)’
../dune/porsol/euler/ImplicitCapillarity_impl.hpp:106:2: note: candidate is:
../dune/porsol/euler/ImplicitCapillarity_impl.hpp:111:17: note: void Dune::ImplicitCapillarity<GridInterface, ReservoirProperties, BoundaryConditions, InnerProd>::initObj(const GI&, const RP&, const BC&) [with GridInterface = Dune::GridInterfaceEulerDune::CpGrid; ReservoirProperties = Dune::ReservoirPropertyCapillaryAnisotropicRelperm<3>; BoundaryConditions = Dune::BasicBoundaryConditions<true, true>; InnerProd = Dune::Anisotropic::InnerProduct; Dune::ImplicitCapillarity<GridInterface, ReservoirProperties, BoundaryConditions, InnerProd>::RP = Dune::ReservoirPropertyCapillaryAnisotropicRelperm<3>]
../dune/porsol/euler/ImplicitCapillarity_impl.hpp:111:17: note: no known conversion for argument 2 from ‘const RP {aka const Dune::ReservoirPropertyCapillaryAnisotropicRelperm<3>}’ to ‘Dune::ReservoirPropertyCapillaryAnisotropicRelperm<3>&’

Edit: I forgot to mention that dune+opm compiles fine using clang(++) on openSUSE 12.2, and also works fine on Ubuntu 12.04 (which uses GCC 4.6).

The opm-porsol repository contains a branch, mortar, that appears to have been fully merged into the master branch. Unless anyone can inform me otherwise, I'm inclined to remove it.

Just noticed this for opm-porsol, but I would guess that it applies to all other modules, too:

When building an opm module with the same module and other modules installed using a common prefixe (in my case /home/mblatt/dune_install_2.2/include), the source path of the current modules has to have precedence before the include path of the installed modules. Currently, it is the last one:

auto-tools/CMakeFiles/aniso_simulator_test.dir/flags.make:CXX_FLAGS = -std=c++11 -g -O0 -pipe -Wall -Wno-unknown-pragmas -ggdb3 -g -O0 -DDEBUG -I/home/mblatt/dune-test/opm-porsol/auto-tools -I/home/mblatt/dune_install_2.2/include -I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi -I/usr/include/superlu -I/usr/include/suitesparse -I/home/mblatt/dune-test/opm-core -I/home/mblatt/dune-test/dune-cornerpoint -I/home/mblatt/dune-test/opm-porsol

When working with installed modules (/home/mblatt/dune_install_2.2/include), this means that all headers included using

#include<path/to/header>

will result in the installed headers being included rather than the local ones.

OK, back from vacation and Lars has left me. Trying to get builds to run again after inclusion of opm-material. Sorry, but I have not done any checking myself so far, as I chances are you guys have already been through it. I have added Atgeirr and Bård to the Jenkins server, so you should shortly see the build failure log in your mail box. opm-material seems to build fine, while opm-porsol fails, and it seems related to opm-material. This is the relevant part of cmake output:

10:22:33 -- Finding package opm-material using module mode
10:22:33 CMake Error at cmake/Modules/OpmFind.cmake:138 (find_package):
10:22:33 Could not find module Findopm-material.cmake or a configuration file for
10:22:33 package opm-material.
10:22:33
10:22:33 Adjust CMAKE_MODULE_PATH to find Findopm-material.cmake or set
10:22:33 opm-material_DIR to the directory containing a CMake configuration file for
10:22:33 opm-material. The file will have one of the following names:
10:22:33
10:22:33 opm-materialConfig.cmake
10:22:33 opm-material-config.cmake
10:22:33
10:22:33 Call Stack (most recent call first):
10:22:33 cmake/Modules/OpmFind.cmake:188 (find_and_append_package_to)
10:22:33 CMakeLists.txt:106 (find_and_append_package_list_to)
10:22:33
10:22:33
10:22:33 -- Finding package dune-cornerpoint using module mode
10:22:33 -- Finding package dune-common using module mode
10:22:33 -- Finding package dune-grid using module mode
10:22:33 -- Finding package opm-core using module mode
10:22:33 -- Performing Test HAVE_DUNE_CORNERPOINT
10:22:36 -- Performing Test HAVE_DUNE_CORNERPOINT - Success
10:22:36 -- Found dune-cornerpoint: /project/multiscale/jenkins-build/RH5/workspace/dune-cornerpoint
10:22:36 -- Generating debug symbols: -ggdb3
10:22:36 -- Looking for strip utility
10:22:36 -- Looking for strip utility - found
10:22:36 -- Writing config file "/project/multiscale/jenkins-build/RH5/workspace/opm-porsol/build/config.h"...
10:22:36 -- This build defaults to installing in /project/multiscale/OPM/jenkins-install/RH5/opm-porsol
10:22:37 -- Found Doxygen: /usr/bin/doxygen
10:22:37 -- Libtool not found!
10:22:37 -- Configuring incomplete, errors occurred!
10:22:37 Build step 'Execute shell' marked build as failure
10:22:37 Sending e-mails to: [email protected] [email protected] [email protected] [email protected] [email protected]
10:22:37 Finished: FAILURE

Seems I was a bit hasty. I cannot see any difference in the set-up, but for some reason the Red Hat 6 build fails to locate opm-material in the build folder. Again added Atgeirr, Bård and Roland, so you should get the log in your mailbox soon.

This applies to the release/2013.03 branch.

When trying to compile blackoil_sim_test.cpp on a CentOS 5 machine with gcc 4.1.2, I get an internal compiler error:

/home/atgeirr/opm/opm-porsol/opm/porsol/blackoil/BlackoilFluid.hpp:544: internal compiler error: in create_tmp_var, at gimplify.c:485

The line indicated looks innocent enough, I do not know what causes the error. I would be interested in knowing if anyone else can reproduce the problem.

If I try to run blackoil_sim with hydrostatic boundary conditions I get problems with convergence of the non-linear solver. According to @osae the hydrostatic conditions worked early Spring 2012. In march 2012 @bska changed the BC representation in opm-core. Could there by compatibility issues between @osae implementation of hydrostatic BC an the new BC representation?

Hi,

I have been digging into boundary conditions for steady-state upscaling. As I understand, for fixed BCs, the fractional flow is calculated on each boundary face not parallel to the flow direction (see opm/porsol/euler/EulerUpstreamImplicit_impl.hpp). However, I observe that for saturations outside the range of the input curves, the fractional flow is negative(!). Further digging tells me that the rel.perm in such regions are extrapolated using class Opm::NonuniformTableLinear, and this cause negative rel.perm. because the curve is strictly monotone.

This has also caused me troubles in other settings as well, for instance

Assertion `! ((m[0] < 0) || (m[1] < 0))' failed.

in opm/core/transport/implicit/SinglePointUpwindTwoPhase.hpp:385.

I think we all can agree that negative rel.perms are unfeasible (this also goes for rel.perm > 1). Thus extrapolation of rel.perm curves is dangerous. I am not sure how we best can handle this? Maybe set rel.perm. to 0 or 1 if out of range? Or include a check on the returned rel.perm, if it is in [0,1], and otherwise set it to 0 or 1?

In file included from ../EulerSolverTester.hpp:55:0,
from euler_upstream_test.cpp:44:
../../../../dune/porsol/common/setupGridAndProps.hpp: In function ‘void Dune::setupGridAndProps(const Opm::parameter::ParameterGroup&, Dune::CpGrid&, ResProp<3>&)’:
../../../../dune/porsol/common/setupGridAndProps.hpp:89:24: error: ‘class Opm::EclipseGridParser’ has no member named ‘saveEGRID’

Some micro-optimalizations in opm-porsol are having unforseen consequences. To avoid reallocating cell-level entities for each cell, these entities are reused across cells with size according to the cell with the most DOFs attached.

the problem is that code further down the line assumes that these have the same size as the number of faces for a particular cell. for complex meshes, this is not a constant, and out of bounds writes is the consequence. in particular, the out of bounds writes happen in IncompFlowSolverHybrid.hpp, computePressureAndFluxes and buildCellContrib.

people are already on top of this (PR#89 was a first attempt), but i was asked to open this issue for tracking purposes, so here it is.

I suppose that his is a regression in opm-parser so @joakim-hove is probably the right person to asses this, but it occurs with the master version of flow_polymer, so I post this issue here:

and@heuristix:~/src/opm-polymer|master > ./bin/flow_polymer deck_filename=/home/and/src/opm-data/polymer_test_suit/simple2D/2D_THREEPHASE_POLY_HETER.DATA
*********************************************************************************************
*                                                                                           *
*                       This is Flow-Polymer (version 2015.04)                              *
*                                                                                           *
* Flow-Polymer is a simulator for three-phase black-oil-polymer flow that is a part of OPM. *
* For more information see:                                                                 *
*                              http://opm-project.org                                       *
*                                                                                           *
*********************************************************************************************

---------------    Reading parameters     ---------------
deck_filename found at /, value is /home/and/src/opm-data/polymer_test_suit/simple2D/2D_THREEPHASE_POLY_HETER.DATA
output not found. Using default value 'true'.
output_dir not found. Using default value 'output'.
Program threw an exception: IOConfig: Reading GRIDFILE keyword from GRID section: Output of GRID file is not supported
terminate called after throwing an instance of 'std::runtime_error'
  what():  IOConfig: Reading GRIDFILE keyword from GRID section: Output of GRID file is not supported
Aborted

(in contrast to what the file name of the deck suggests, this is actually a 3D grid, but with a thickness of 1 in y-direction. I also strongly suspect that the deck is correct in the sense that Eclipse can process it because opm-data contains the results of an Eclipse run for this.)

The release/2013.03 branch currently fails to build with gcc 4.1.2. This is because it tries to build the program "co2_sim_test" which in turn includes files using constexpr. Under autotools, this was handled by a conditional, see commit 9b2987f.

I want to set up a case where the injection rates changes during simulation. If I understand the code correctly this is not yet implemented in opm-porsol. Is there any plan to do so?

Hi.
I have tried to build the newest commit of opm-porsol, but I get the following error message:

In file included from ../EulerSolverTester.hpp:55:0,
                 from euler_upstream_test.cpp:44:
../../../../dune/porsol/common/setupGridAndProps.hpp: In function ‘void Dune::setupGridAndProps(const Opm::parameter::ParameterGroup&, Dune::CpGrid&, ResProp<3>&)’:
../../../../dune/porsol/common/setupGridAndProps.hpp:88:50: error: ‘struct boost::filesystem::basic_path<std::basic_string<char>, boost::filesystem::path_traits>::string_type’ has no member named ‘string’

I use the newest commit of opm-core, which was built successfully.

I have used the newest revisions from github for all opm modules along with dune 2.2.

Input parameters:
fileformat=eclipse
filename=Larssinmodell.grdecl
kr_filename=not_used
outputWater=ss_upscaling_Larssinmodell_fixed_water.txt
outputOil=ss_upscaling_Larssinmodell_fixed_oil.txt
rock_list=rocklist.txt
sat_pdrop_filename=satpdrop.txt
use_jfunction_scaling=false
output_vtk=false
flow_direction=0
boundary_condition_type=0
perm_threshold_md=1E-12
start_from_cp=true
viscosity1=0.00033
viscosity2=0.00178
density1=1026
density2=1026
linsolver_verbosity=0
print_inoutflows=true
transport_verbosity=0

If run with fixed BCs, error message is:
steadystate_test_implicit: /project/multiscale/users/laods/opm/opm-core/opm/core/transportSinglePointUpwindTwoPhase.hpp:315: void Opm::SinglePointUpwindTwoPhase::makefhfQPeriodic(const std::vector<int, std::allocator >&, const std::vector<int, std::allocator >&, const std::vector<int, std::allocator >&) [with TwophaseFluid = Opm::TwophaseFluidWrapper]: Assertion `! p_faces.empty()' failed.

And if run with linear or periodic BCs error message is:
steadystate_test_implicit:
/private/laods/summer2012/boost-1.45//include/boost/smart_ptr/scoped_ptr.hpp:91: T& boost::scoped_ptr::operator*() const [with T = Dune::Amg::AMG<Dune::MatrixAdapter<Dune::BCRSMatrix<Dune::FieldMatrix<double, 1, 1>, std::allocator<Dune::FieldMatrix<double, 1, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::SeqILU0<Dune::BCRSMatrix<Dune::FieldMatrix<double, 1, 1>, std::allocator<Dune::FieldMatrix<double, 1, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, 1>, Dune::Amg::SequentialInformation, std::allocator<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > > >]: Assertion `px != 0' failed.

The same goes for other modules using cmake/Modules/UseOnlyNeeded.cmake
and simply leaving this out circumvents the problem.

Seems to be related to the following issue

// gcc -flto -Wl,--as-needed math.c -lm -o math
// removing either -flto or --as-needed makes it work
// also, if the argument is known at compile time the call disappears so it works

include <math.h>

int main(int argc, char **argv)
{
sqrt(argc);
}

To my best knowledge opm-porsol uses the AMG of dune-istl, but currently --with-superlu is not processed in the configure script. Therefore AMG will use an iterative solver on the coarse level which might severely degrade its convergence.

Please honor superlu pathes provided to configure

I have been comparing CO2 simulations at Sleipner using Eclipse and OPM. In order to get comparable results I had to convert the OPM injection rates to reservoir conditions (multiply with the Bg) manually. How does the wells in OPM treat volumes?

If i run

~/master/opm/opm_ss/opm-upscaling/examples/upscale_perm -linsolver_type 1
-linsolver_verbosity 0 -bc f SN74_lower_sc4_6_7ch_props_chopped5x5x1.grdecl 

everything works fine, and I get a upscaled single-phase perm tensor. However, if I want to print solver statistics, and use option "-linsolver_verbosity 1", I get

Compute for fixed boundary conditions: ...  
In file /home/birkeland/odsater/master/opm/opm_ss/opm-porsol/dune/porsol/mimetic
/IncompFlowSolverHybrid.hpp, line 1507: Linear solver failed to converge in 2 iterations.
Residual reduction achieved is 0.00914169

There are several things I don't understand here:

• In the first run, does the lin.solver converge, or does it fail and don't print error message?
• Why are only two iterations used in the second run?

If I further try to change the linsolver, .i.e, run

~/master/opm/opm_ss/opm-upscaling/examples/upscale_perm -linsolver_type 0
-linsolver_verbosity 1 -bc f SN74_lower_sc4_6_7ch_props_chopped5x5x1.grdecl 

I get the same error message as before:

Compute for fixed boundary conditions: ...  
In file /home/birkeland/odsater/master/opm/opm_ss/opm-porsol/dune/porsol/mimetic
/IncompFlowSolverHybrid.hpp, line 1507: Linear solver failed to converge in 2 iterations.
Residual reduction achieved is 0.00914169

This error message is from line 1507 in 'IncompFlowSolverHybrid.hpp'. That is in the member function 'solveLinearSystemAMG()', but I thought linsolver_type=0 corresponded to ILU0/CG, which is implemented in member function 'solverLinearSystem()'.

Something is wrong here, but I can't figure out what.

When I try to build opm-porsol I get the following error:

../dune/porsol/common/setupGridAndProps.hpp: In function ‘void Dune::setupGridAndProps(const Opm::parameter::ParameterGroup&, Dune::CpGrid&, ResProp<3>&)’:
../dune/porsol/common/setupGridAndProps.hpp:89:24: error: ‘class Opm::EclipseGridParser’ has no member named ‘saveEGRID’

The necessary dune modules and opm-core (cmake branch) is build and linked successfully

I am testing the release/2013.03 branch on my Ubuntu 12.04 system, and I get the following error message:

Linking CXX executable bin/tpfa_solver_test
lib/libopmporsol.a(LinearSolverISTL.cpp.o):(.rodata+0xa8): multiple definition of `Dune::GetSuperLUType::type'
CMakeFiles/tpfa_solver_test.dir/examples/tpfa_solver_test.cpp.o:(.rodata+0xde0): first defined here

I tried the newest commit from @rolk, that is opm-porsol@07f69fa180