opm / opm-material Goto Github PK

View Code? Open in Web Editor NEW

15.0 15.0 51.0 10.79 MB

Provides thermodynamic relations, capillary pressure curves, etc.

License: Other

CMake 0.30% C++ 98.45% Shell 0.08% Python 1.17%

opm-material's People

Contributors

Stargazers

Watchers

opm-material's Issues

Test failure in Statoil

5/12 Test #12: test_immiscibleflash .............   Passed    0.30 sec
 6/12 Test #10: test_components ..................   Passed    0.40 sec
 7/12 Test  #9: test_2dtables ....................***Exception: Other  0.71 sec
terminate called after throwing an instance of 'Opm::NumericalProblem'
  what():  [/private/jenkins/jenkins/RH6/workspace/opm-material-install-RH6/opm/material/common/UniformXTabulated2DFunction.hpp:255] Attempt to get undefined table value (-9.8, -10)

building error

The files in opm-common do exist, while I do not know why the compiler could find the these files.

Not knowing if this is related to OPM/opm-parser#668.

The compilation of opm-parser is okay though. Anyone saw this problem too?

Thanks.

In file included from /home/kaib/OPM/debug/opm-material/tests/test_2dtables.cpp:30:0:
/home/kaib/OPM/debug/opm-material/opm/material/common/UniformXTabulated2DFunction.hpp:30:37: fatal error: opm/common/Exceptions.hpp: No such file or directory
 #include <opm/common/Exceptions.hpp>
                                     ^
compilation terminated.
In file included from /home/kaib/OPM/debug/opm-material/opm/material/fluidsystems/blackoilpvt/LiveOilPvt.hpp:31:0,
                 from /home/kaib/OPM/debug/opm-material/tests/test_eclblackoilpvt.cpp:34:
/home/kaib/OPM/debug/opm-material/opm/material/common/UniformXTabulated2DFunction.hpp:30:37: fatal error: opm/common/Exceptions.hpp: No such file or directory
 #include <opm/common/Exceptions.hpp>
                                     ^
compilation terminated.
In file included from /home/kaib/OPM/debug/opm-material/opm/material/fluidsystems/SinglePhaseFluidSystem.hpp:29:0,
                 from /home/kaib/OPM/debug/opm-material/opm/material/checkFluidSystem.hpp:29,
                 from /home/kaib/OPM/debug/opm-material/tests/test_fluidsystems.cpp:29:
/home/kaib/OPM/debug/opm-material/opm/material/fluidsystems/BaseFluidSystem.hpp:32:37: fatal error: opm/common/Exceptions.hpp: No such file or directory
 #include <opm/common/Exceptions.hpp>
                                     ^
compilation terminated.
make[2]: *** [CMakeFiles/test_2dtables.dir/tests/test_2dtables.cpp.o] Error 1
make[2]: Leaving directory `/home/kaib/OPM/debug/opm-material-build'
make[1]: *** [CMakeFiles/test_2dtables.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make[2]: *** [CMakeFiles/test_fluidsystems.dir/tests/test_fluidsystems.cpp.o] Error 1
make[2]: Leaving directory `/home/kaib/OPM/debug/opm-material-build'
make[1]: *** [CMakeFiles/test_fluidsystems.dir/all] Error 2
In file included from /home/kaib/OPM/debug/opm-material/opm/material/fluidmatrixinteractions/EclMaterialLawManager.hpp:34:0,
                 from /home/kaib/OPM/debug/opm-material/tests/test_eclmateriallawmanager.cpp:35:
/home/kaib/OPM/debug/opm-material/opm/material/fluidmatrixinteractions/PiecewiseLinearTwoPhaseMaterial.hpp:31:38: fatal error: opm/common/ErrorMacros.hpp: No such file or directory
 #include <opm/common/ErrorMacros.hpp>
                                      ^
compilation terminated.
make[2]: *** [CMakeFiles/test_eclblackoilpvt.dir/tests/test_eclblackoilpvt.cpp.o] Error 1
make[2]: Leaving directory `/home/kaib/OPM/debug/opm-material-build'
make[1]: *** [CMakeFiles/test_eclblackoilpvt.dir/all] Error 2
In file included from /home/kaib/OPM/debug/opm-material/tests/test_fluidmatrixinteractions.cpp:34:0:
/home/kaib/OPM/debug/opm-material/opm/material/fluidmatrixinteractions/BrooksCorey.hpp:33:38: fatal error: opm/common/ErrorMacros.hpp: No such file or directory
 #include <opm/common/ErrorMacros.hpp>
                                      ^
compilation terminated.
In file included from /home/kaib/OPM/debug/opm-material/tests/test_immiscibleflash.cpp:33:0:
/home/kaib/OPM/debug/opm-material/opm/material/constraintsolvers/MiscibleMultiPhaseComposition.hpp:33:68: fatal error: opm/common/utility/platform_dependent/disable_warnings.h: No such file or directory
 #include <opm/common/utility/platform_dependent/disable_warnings.h>
                                                                    ^
compilation terminated.
In file included from /home/kaib/OPM/debug/opm-material/opm/material/components/Unit.hpp:28:0,
                 from /home/kaib/OPM/debug/opm-material/tests/test_components.cpp:34:
/home/kaib/OPM/debug/opm-material/opm/material/components/Component.hpp:29:38: fatal error: opm/common/ErrorMacros.hpp: No such file or directory
 #include <opm/common/ErrorMacros.hpp>

CMake error complains about dune_common

I get an error when I try to install opm-material from source, as it complains about dune_common.

(full log on gist)

-- Finding package dune-common using module mode
-- Failed to find library "dunecommon" for module dune-common
-- 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
CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
  Could NOT find dune-common (missing: dune-common_LIBRARY)
Call Stack (most recent call first):
  /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
  /scratch/riseth/opm-project/opm-20170314/opm-common/cmake/Modules/OpmPackage.cmake:368 (find_package_handle_standard_args)
  /scratch/riseth/opm-project/opm-20170314/opm-common/cmake/Modules/Finddune-common.cmake:14 (find_opm_package)
  /scratch/riseth/opm-project/opm-20170314/opm-common/cmake/Modules/OpmFind.cmake:147 (find_package)
  /scratch/riseth/opm-project/opm-20170314/opm-common/cmake/Modules/OpmFind.cmake:211 (find_and_append_package_to)
  /scratch/riseth/opm-project/opm-20170314/opm-common/cmake/Modules/OpmLibMain.cmake:112 (find_and_append_package_list_to)
  CMakeLists.txt:95 (include)

I have downloaded all the required dune modules to the same folder as opm-common,opm-parser and opm-material: /scratch/riseth/opm-project/opm-20170314/
I have run dunecontrol all, but not install. Is that required?

Test failure:

5/12 Test  #2: test_eclmateriallawmanager .......***Exception: Other  0.32 sec
terminate called after throwing an instance of 'std::logic_error'
  what():  [/private/jenkins/jenkins/RH6/workspace/opm-material-install-RH6/tests/test_eclmateriallawmanager.cpp:257] Discrepancy between the deck and the EclMaterialLawManager

Premature version upgrade breaks build of OPM

Since f97f34a (what happend to using pull requests, anyway) I cannot build the master of OPM anymore:

--- calling bexec for opm-material ---
loading initial cache file ../../opts.cmake
CMake Error at /home/mblatt/src/dune/opm-2.6/opm-common/cmake/Modules/OpmFind.cmake:180 (find_package):
  Could not find a configuration file for package "opm-common" that is
  compatible with requested version "2018.10".

  The following configuration files were considered but not accepted:

    /home/mblatt/src/dune/opm-2.6/opm-common/opm-parallel/opm-common-config.cmake, version: 2018.04

Call Stack (most recent call first):
  /home/mblatt/src/dune/opm-2.6/opm-common/cmake/Modules/OpmPackage.cmake:191 (find_and_append_package_to)
  opm-material-prereqs.cmake:25 (find_package_deps)
  CMakeLists.txt:66 (include)


-- Configuring incomplete, errors occurred!
See also "/home/mblatt/src/dune/opm-2.6/opm-material/opm-parallel/CMakeFiles/CMakeOutput.log".
See also "/home/mblatt/src/dune/opm-2.6/opm-material/opm-parallel/CMakeFiles/CMakeError.log".
--- Failed to build opm-material ---
Terminating dunecontrol due to previous errors!

The make test

The make test for opm-material usually takes pretty long time, so most of time I do not do that.

Is the following output desired?

      Start  1: test_eclblackoilpvt
 1/12 Test  #1: test_eclblackoilpvt ..............***Exception: Other  0.02 sec

ECLMaterialLawManager::materialParams_ behaves/is used inconsistently

opm-material/opm/material/fluidmatrixinteractions/EclMaterialLawManager.hpp

Lines 210 to 228 in 12376bc

 MaterialLawParams& materialLawParams(unsigned elemIdx) 

 { 

 if (hasElementSpecificParameters()) { 

 assert(0 <= elemIdx && elemIdx < materialLawParams_.size()); 

 return *materialLawParams_[elemIdx]; 

 } 

 else 

 return *materialLawParams_[satnumRegionIdx_[elemIdx]]; 

 } 

 const MaterialLawParams& materialLawParams(unsigned elemIdx) const 

 { 

 if (hasElementSpecificParameters()) { 

 assert(0 <= elemIdx && elemIdx < (int) materialLawParams_.size()); 

 return *materialLawParams_[elemIdx]; 

 } 

 else 

 return *materialLawParams_[satnumRegionIdx_[elemIdx]]; 

 }

: In the functions ECLMaterialLawManager::materialLawParam(unsigned elemetIdx) there is a switch on ECLMaterialLawManager::hasElementSpecificParameters(). If true the size is assumed to equal to the number elements in the grid, other it is supposed to be the number of satNumRegions.

Nevertheless, during ECLMaterialLawManager::init the same switch is used to either call ECLMaterialLawManager::initElemSpecific_ or ECLMaterialLawManager::initNonElemSpecific_. But both methods create ECLMaterialLawManager::materialLawParams_ with the same size as the number of elements and initialize one entry for each element. See

opm-material/opm/material/fluidmatrixinteractions/EclMaterialLawManager.hpp

Lines 548 to 561 in 12376bc

 materialLawParams_.resize(numCompressedElems); 

 for (unsigned elemIdx = 0; elemIdx < numCompressedElems; ++elemIdx) { 

 materialLawParams_[elemIdx] = std::make_shared<MaterialLawParams>(); 

 unsigned satnumRegionIdx = static_cast<unsigned>(satnumRegionIdx_[elemIdx]); 

 initThreePhaseParams_(deck, 

 eclState, 

 *materialLawParams_[elemIdx], 

 satnumRegionIdx, 

 *oilWaterScaledEpsInfoDrainage_[elemIdx], 

 oilWaterParams[elemIdx], 

 gasOilParams[elemIdx]); 

 materialLawParams_[elemIdx]->finalize();

and

opm-material/opm/material/fluidmatrixinteractions/EclMaterialLawManager.hpp

Lines 382 to 386 in 12376bc

 materialLawParams_.resize(numCompressedElems); 

 for (unsigned elemIdx = 0; elemIdx < numCompressedElems; ++elemIdx) { 

 unsigned satnumRegionIdx = static_cast<unsigned>(satnumRegionIdx_[elemIdx]); 

 materialLawParams_[elemIdx] = satRegionParams[satnumRegionIdx]; 

 }

If I am not missing something then this could lead to rather unwanted behaviour during a simulation and should be resolved. I would propose to always create one entry in ECLMaterialLawManager::materialLawParams_ for each cell and remove the switches from ECLMaterialLawManager::materialLawParams() as this seems easier to grasp as varying sizes depending on the properties.

Runs with no disgas and PVTO present runs without warning. flow fail without usefull message if no oil pvt is pressent in deck

There is no checking of consistency in OilPvtMultiplexer.hpp (line 125-126)

Also if no oil properties is present flow fails without usefull meassages.

CO2.hpp Accesses Index Out of Bounds

The vaporPressure() function has the following lines

static const Scalar a[4] =
    { -7.0602087, 1.9391218, -1.6463597, -3.2995634 };
static const Scalar t[4] =
    { 1.0, 1.5, 2.0, 4.0 };

// this is on page 1524 of the reference
Evaluation exponent = 0;
Evaluation Tred = T/criticalTemperature();
for (int i = 0; i < 5; ++i)
    exponent += a[i]*Opm::pow(1 - Tred, t[i]);

In other words, the t and a arrays have size 4, but since the loop uses an upper bound of 5, we end up accessing the out-of-bounds elements a[4] and t[4]. Is the upper loop index supposed to be 4 as well?

This, and a number of other issues were identified in the latest static analysis run.

Compilation fails with g++-4.9.2

In file included from /home/mblatt/DUNE-test/opm-simulators/ebos/equil/equilibrationhelpers.hh:33:0,
                 from /home/mblatt/DUNE-test/opm-simulators/ebos/equil/initstateequil.hh:32,
                 from /home/mblatt/DUNE-test/opm-simulators/ebos/eclequilinitializer.hh:31,
                 from /home/mblatt/DUNE-test/opm-simulators/ebos/eclproblem.hh:55,
                 from /home/mblatt/DUNE-test/opm-simulators/ebos/ebos.hh:31,
                 from /home/mblatt/DUNE-test/opm-simulators/ebos/ebos_blackoil.cc:30:
/home/mblatt/DUNE-test/opm-material/opm/material/fluidsystems/BlackOilFluidSystem.hpp: In instantiation of ‘static constexpr unsigned int Opm::BlackOilFluidSystem<Scalar, IndexTraits>::solventComponentIndex(unsigned int) [with Scalar = double; IndexTraits = Opm::BlackOilDefaultIndexTraits]’:
/home/mblatt/DUNE-test/opm-simulators/opm/simulators/wells/BlackoilWellModel_impl.hpp:1530:126:   required from ‘void Opm::BlackoilWellModel<TypeTag>::computeAverageFormationFactor(std::vector<typename Ewoms::Properties::GetProperty<TypeTag, Ewoms::Properties::PTag::Scalar>::p::type>&) const [with TypeTag = Ewoms::Properties::TTag::EbosTypeTag; typename Ewoms::Properties::GetProperty<TypeTag, Ewoms::Properties::PTag::Scalar>::p::type = double]’
/home/mblatt/DUNE-test/opm-simulators/opm/simulators/wells/BlackoilWellModel_impl.hpp:365:48:   required from ‘void Opm::BlackoilWellModel<TypeTag>::wellTesting(int, double, Opm::DeferredLogger&) [with TypeTag = Ewoms::Properties::TTag::EbosTypeTag]’
/home/mblatt/DUNE-test/opm-simulators/opm/simulators/wells/BlackoilWellModel_impl.hpp:309:76:   required from ‘void Opm::BlackoilWellModel<TypeTag>::beginTimeStep() [with TypeTag = Ewoms::Properties::TTag::EbosTypeTag]’
/home/mblatt/DUNE-test/opm-simulators/ebos/eclproblem.hh:886:9:   required from ‘void Ewoms::EclProblem<TypeTag>::beginTimeStep() [with TypeTag = Ewoms::Properties::TTag::EbosTypeTag]’
/home/mblatt/DUNE-test/ewoms/ewoms/common/simulator.hh:675:13:   required from ‘void Ewoms::Simulator<TypeTag>::run() [with TypeTag = Ewoms::Properties::TTag::EbosTypeTag]’
/home/mblatt/DUNE-test/ewoms/ewoms/common/start.hh:361:9:   required from ‘int Ewoms::start(int, char**) [with TypeTag = Ewoms::Properties::TTag::EbosTypeTag]’
/home/mblatt/DUNE-test/opm-simulators/ebos/ebos_blackoil.cc:96:51:   required from here
/home/mblatt/DUNE-test/opm-material/opm/material/fluidsystems/BlackOilFluidSystem.hpp:447:5: error: body of constexpr function ‘static constexpr unsigned int Opm::BlackOilFluidSystem<Scalar, IndexTraits>::solventComponentIndex(unsigned int) [with Scalar = double; IndexTraits = Opm::BlackOilDefaultIndexTraits]’ not a return-statement
     }
     ^

Seems like it only supports C++11 constexpr that is only allowed to have one return statement.

gas condensate reservoir

can be used opm-material to simulate a gas condensate reservoir?
like eclipse(E-300)

Assertion in EclEpsScalingPoints.hpp when using flow_solvent

Using the solvent_test_suite with

./flow_solvent SPE1CASE2_SOLVENT.DATA

I get the following assertion:

flow_solvent: opm-material/opm/material/fluidmatrixinteractions/EclEpsScalingPoints.hpp:247: void Opm::EclEpsScalingPointsInfo<Scalar>::extractUnscaled(Opm::DeckConstPtr, Opm::EclipseStateConstPtr, unsigned int) [with Scalar = double; Opm::DeckConstPtr = std::shared_ptr<const Opm::Deck>; Opm::EclipseStateConstPtr = std::shared_ptr<const Opm::EclipseState>]: Assertion `std::abs(maxKrw - maxKrg) < 1e-30' failed.

Raising the tolerance to 1e-12 leads to the same assertion.

results degradation with JFUNC

When I compare current results for Model 2.2 with results from end of 2016 there is a significant change of results. If I comment out JFUNC the results stays the same. I guess something wrong happened when the new JFUNC implementation in opm-parser was introduced.
@andlaus, @jokva Any idea?

Basic documentation needed

Please provide a readme. The readme should as a bare minimum include a description of what this module provides and dependencies towards other opm modules.

compile failed with gcc-6.1

I tried to test a newer gcc compiler, the other opm modules compile very smoothly, especially for opm-simulators, but opm-material meet one issue.

In file included from /home/liuming/work/opm/opm-material/tests/test_fluidsystems.cpp:31:0:
/home/liuming/work/opm/opm-material/opm/material/checkFluidSystem.hpp: In function ‘void checkFluidSystem() [with Scalar = double; FluidSystem = Opm::FluidSystems::SinglePhase<double, Opm::GasPhase<double, Opm::N2<double> > >; RhsEval = Opm::DenseAd::Evaluation<double, 3>; LhsEval = Opm::DenseAd::Evaluation<double, 3>]’:
/home/liuming/work/opm/opm-material/opm/material/checkFluidSystem.hpp:367:100: internal compiler error: in assign_temp, at function.c:961
             try { auto tmpVal = FluidSystem::diffusionCoefficient(fs, paramCache, phaseIdx, compIdx); static_assert(std::is_same<decltype(tmpVal), RhsEval>::value, "The default return value must be the scalar used by the fluid state!"); } catch (...) {};
                                                                                                    ^
0x885945 assign_temp(tree_node*, int, int)
    ../../src/gcc/function.c:961
0x75cbc7 expand_call(tree_node*, rtx_def*, int)
    ../../src/gcc/calls.c:2569
0x83d6f6 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool)
    ../../src/gcc/expr.c:10594
0x768b08 expand_expr
    ../../src/gcc/expr.h:256
0x768b08 expand_call_stmt
    ../../src/gcc/cfgexpand.c:2660
0x768b08 expand_gimple_stmt_1
    ../../src/gcc/cfgexpand.c:3548
0x768b08 expand_gimple_stmt
    ../../src/gcc/cfgexpand.c:3714
0x769c45 expand_gimple_basic_block
    ../../src/gcc/cfgexpand.c:5720
0x76eb26 execute
    ../../src/gcc/cfgexpand.c:6335
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <file:///usr/share/doc/gcc-6/README.Bugs> for instructions.
make[2]: *** [CMakeFiles/test_fluidsystems.dir/tests/test_fluidsystems.cpp.o] Error 1
make[1]: *** [CMakeFiles/test_fluidsystems.dir/all] Error 2
make: *** [all] Error 2

NumbericalProblem is thrown in NcpFlash, when no water initially with a dead oil dead gas three phase system

The message is as follows,

Program threw an exception: [/home/kaib/OPM-master-test/debug/opm-material/opm/material/constraintsolvers/NcpFlash.hpp:239] NcpFlash solver failed: {c_alpha^kappa} = {4865.86 0 0}, T = 15.555

Any clues about that? I can share the example.

[Build System] Introduce Boost.Test as an Optional Prerequisite

I'm about to do some work on vertical scaling of saturation functions, especially the features that are introduced by the ECLIPSE keywords KRWR, KRGR, KRORW, and KRORG. As part of this work I'd like to expand the set of unit tests in opm-material to ensure I don't make too many mistakes. The current set of unit tests don't use a testing framework however and instead rely on manually implementing function main().

Is there a hard limit on using testing frameworks in opm-material or may I write my new unit tests in terms of the Boost.Test library?

Discussion: Blackoil API

this issue is intended to be the continuation of the conversation of #98 and is thus some kind of a TODO list. So far we (@atgeirr and me) have agreed on the following things (If I forgot something, or we did not actually agree, please add a comment):

(Edit from @atgeirr: I'll edit directly in your list just this time, to avoid massive quoting. See the "Edited:" items below. It can be assumed that I agree with what it says now. )

the API in opm-material stays "single point" and won't switch to "bulk mode"
- some convenience layer may be added to the simulator modules which use a "global" POV. (I suppose this will only be done if the wrapper is actually more convenient to use than explicit loops. Let's see.)
The API for the low-level PVT objects for gas, oil and water stays largely unchanged:
- The parameters passed to these objects methods stay as they are
- Unifying classes will only be done if the result is an improvement on the current state. (IMO this mean "clarity of the code". Edited: @atgeirr also thinks that changes which only result in fewer classes are worth it. possibly these two things are not mutually exclusive, though)
- renaming some methods would be beneficial (but I forgot which these were, please add comments). Edited: the method dealing with the saturation curve should use the word "saturated" to make more clear what they do.
the API of the BlackOilFluidSystem will become more consistent and higher-level:
- instead of explicitly passing the quantities on which a method depends on, a "fluid state" object is passed everywhere
- the phase/component indices are passed as method arguments (i.e., they will no longer encoded into the method names)
the mapping from active to canonical phase indices will continue to happen outside of the fluid system
- the initialization code needs to deal with error conditions
all methods of BlackOilFluidSystem get black-oil specific variants:
- instead of via the ParameterCache object, the PVT region index is passed explicitly as an integer to these
- the ParameterCache taking variants of these methods are simple forwards to the new methods
The fact that the computation methods are static is unfortunate:
- it makes instantiation of multiple fluid systems (e.g., for comparison purposes) much harder than it needs to be
- it is a lot of work to change the approach to the normal "instanced classes" pattern because every single model in eWoms would need a lot of changes as would most of the constraint solvers from opm-material
- in retrospect, it thus would have been better to use instanced classes, and we might change to that pattern some time in the future, but it is not on the immediate agenda
some methods of the BlackOilFluidSystem must be renamed for consistency
Edited: the phase parameters required should be strongly typed (new enum class perhaps?) and not convertible from int for safety.

a question about "opm-material-prereqs.cmake"

There is a piece of code "find_package_deps(opm-material)" in the "opm-material-prereqs.cmake" file.

I am confused about this "find_package_deps(opm-material)" code. It is like the "find_package()" of CMake, but it seems that this code is not a CMake command. Could someone explain this code please? Thanks!

Test failing (segfault) after PR120

After #120 a test fails, thus stopping the OPM build pipeline on Jenkins. See https://ci.opm-project.org/job/opm-material/964/

Are permeability and capillary pressure lookup saturations correct?

I was reading through some of the opm-material codes. Some of the lookup saturations that are used in some of the classes (i.e. EclDefaultMaterial and EclStone1Material) seemed a little odd to me. I hoped you could explain why you are using these saturation:

The lookup saturation that are used for Pcog (and Krg) is So = 1 - Sg. I always thought that for "Krw and Pcow" lookup Sw and for "Krg and Pcog" lookup Sg is used. If my assumption is correct then based on the fact that your gas/oil table are tabulated against So, I think So = 1 - Sg - Swco would be more appropriate.
In EclStone1Material, So = 1 - Sg - Swco is used for lookup of Krog but in "updateHysteresis" function So = 1 - Sg is used for Krog. I suppose that "updateHysteresis" needs to be updated.
In EclDefaultMaterial's "updateHysteresis" method Sw = 1 - Sg is used for updating krwSw. IMHO, krwSw = Sw should be used here. Also in this method So_go = 1 + Sw_ow is used where probably So_go = 1 - Sw_ow would be more accurate.

Failing test in opm-core

Currently the test_relpermdiagnistics test in opm-core is failing.

The failure is due to a failing assert here: https://github.com/OPM/opm-material/blob/master/opm/material/fluidmatrixinteractions/EclEpsScalingPoints.hpp#L374

The test data used is here: https://github.com/OPM/opm-core/blob/master/tests/relpermDiagnostics.DATA#L61

So it is indeed 'correct' to fail the assertion, but it is not clear to me how this should be fixed:

Remove the assert( )?
Fix the test data?

Official Debian Packages

This is for people interested in this effort. The current state is on salsa.debian.org. This is currently being finalized (mainly coming up with good package descriptions), and will then be submitted to debian.

Negative invB(b) factors

Due to linear extrapolation we can get negative invB (b) factors for some setup of the PVT tables when computing well potentials for default pressure (i.e. 1 atm)

PVDG
25 0.05
50 0.02
..
/

should give b approx 0.06 and invB = 1 / 0.08 >0 for 1 atm.

but since we instead extrapolate invB we get the following

which gives approximately -10 for invB for 1 atm.

@bska @OPMUSER Any suggestions on how this should be fixed.
I have some like adding an extra data point for 1 atm (or 1 bar) in the invB table where values are computed based on extrapolation of the input table or change to a constant extrapolation of the table. But comments are very welcome.

Where is lapack required?

On one machine CMake showed an error that no lapack is available on the system. Can someone tell me where the usage of lapack is mandatory? I tried to find it myself but could not.

Some shared_ptr in EclMaterialLawManager are of little use

In the current master both EclMaterialLawManager::oilWaterEpsInfoDrainage_ is a vector of shared_ptr, but according to the code that initializes its entries each shared_ptr is actually created as a new pointer. Thus there will be now duplicates. (I assume that the original designe idea was to point to the entries of unscaledEpsInfo_ if there are no element specific parameters.)

For EclMaterialLawManager::materialLawParams the picture is slightly different. If hasElementSpecificParameters() is false, then the entries point to the parameters for the satnumRegions the element belongs to. I am not sure what the more often use case is: element specific parameters or not.

We should ask us whether the memory savings in some cases outweight the additional level of indirection and code obfuscation. To the very least it makes communicating the values harder.

The make test take really some while to finish.

The following is the output, is it normal?

Running tests...
Test project /home/kaib/OPM/build/opm-material-build
      Start  1: fluidmatrixinteractions
 1/10 Test  #1: fluidmatrixinteractions ..........   Passed    0.00 sec
      Start  2: pengrobinson
 2/10 Test  #2: pengrobinson .....................   Passed   18.23 sec
      Start  3: localad
 3/10 Test  #3: localad ..........................   Passed    0.35 sec
      Start  4: ncpflash
 4/10 Test  #4: ncpflash .........................   Passed    0.04 sec
      Start  5: spline
 5/10 Test  #5: spline ...........................   Passed    0.01 sec
      Start  6: tabulation
 6/10 Test  #6: tabulation .......................   Passed   17.47 sec
      Start  7: 2dtables
 7/10 Test  #7: 2dtables .........................   Passed    0.03 sec
      Start  8: components
 8/10 Test  #8: components .......................   Passed    0.00 sec
      Start  9: fluidsystems
 9/10 Test  #9: fluidsystems .....................   Passed   60.99 sec
      Start 10: immiscibleflash
10/10 Test #10: immiscibleflash ..................   Passed    0.04 sec

call opm-material from dumux

As discussed with some OPM developers, we would like to evaluate the feasibility of using opm-material in Dumux.

I made a first attempt and converted the Dumux test_box2p2c. The OPM changes are documented in the branch feature/call-from-dumux. Note that this is against the release 2016.04, I hope that not too much did change there. The Dumux changes are documented here:
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/366

Encountered issues:

Opm's Valgrind.hh and Dumux' valgrind.hh define the same functions in the same namespace. They differ in the way HAVE_VALGRIND is treated. It isn't possible to use both at the same time. The one from OPM is nicer. A possibility would be to use that one also in Dumux and put a namespace Dumux around the namespace Valgrind. For the moment, I just commented the inclusions of the Opm file.
Dumux' 2p2c model expects the FluidSystem to export indices {w,n}PhaseIdx and {w,n}CompIdx. One solution would be to add them to Opm's FluidSystem.
The NullParameterCache is a template class in Opm and a non-template class in Dumux. I solved it by using Opm's one in the VolumeVariables. A better solution is needed to make have the possibility to switch between using dumux/material and opm-material.
The FluidSystems have a different interface for the (binary) diffusion coefficient, the FluidMatrixInteractions have different interfaces for the capillary pressure and relperms. Again, I solved it by using Opm's one in the VolumeVariables. This could be made flexible (but not nice) by SFINAE and std::enable_if. Or interface unification.
The MaterialLawParameters have different interfaces. Since the call are on the top level, it is a minor thing.
The ConstraintSolver types are hardcoded in the VolumeVariables. This could be solved by creating properties such that they can be changed on the top level.
Opm's FluidState doesn't offer a function setMassFraction which seems to be convenient when mass instead of the mole fractions are usedas primary variables. Naturally, I would have nothing against adding this to Opm's FluidStates.
The results are not dramatically, but quite a bit different. This needs to be investigated.

Comments are welcome!

Passing tests print error messages

Noticed while working on the Debian packages. While all the test pass they do print quite some errors:

error for "gasDensity": 0.101555% difference (tolerance: 0.1%)
error for "gasDensity": 0.10424% difference (tolerance: 0.1%)
error for "gasDensity": 0.106803% difference (tolerance: 0.1%)
error for "gasDensity": 0.109397% difference (tolerance: 0.1%)
error for "gasDensity": 0.112078% difference (tolerance: 0.1%)
error for "gasDensity": 0.114636% difference (tolerance: 0.1%)
error for "gasDensity": 0.117221% difference (tolerance: 0.1%)
error for "gasDensity": 0.119897% difference (tolerance: 0.1%)
error for "gasDensity": 0.12245% difference (tolerance: 0.1%)
error for "gasDensity": 0.125028% difference (tolerance: 0.1%)
error for "gasDensity": 0.127698% difference (tolerance: 0.1%)
error for "gasDensity": 0.130248% difference (tolerance: 0.1%)
14/18 Test  #5: eclmateriallawmanager ............   Passed    2.18 sec

This is a bit disturbing. Maybe these test always return success in main?

Bug in Spline.hpp

Line

opm-material/opm/material/common/Spline.hpp

Line 1247 in 4181950

unsigned idx = i;

triggers an unused variable warning, for good reason. The variable is equal to i or (if reverse is true) counting down backwards. However, for actual indexing, i is always used, not idx.

There also seems to be no unit tests for this code, which makes me a bit reluctant about fixing it.

pengrobinson test segfaults on Ubuntu 14.04 in Release

On Ubuntu 14.04, stock, with gcc 4.82, the pengrobinson test fails:

vagrant@vagrant:~/workspace/opm/opm-material-build$ make test
Running tests...
Test project /home/vagrant/workspace/opm/opm-material-build
    Start 1: fluidmatrixinteractions
1/7 Test #1: fluidmatrixinteractions ..........   Passed    0.00 sec
    Start 2: pengrobinson
2/7 Test #2: pengrobinson .....................***Exception: SegFault  0.00 sec
    Start 3: ncpflash
3/7 Test #3: ncpflash .........................   Passed    0.03 sec
    Start 4: tabulation
4/7 Test #4: tabulation .......................   Passed   12.13 sec
    Start 5: 2dtables
5/7 Test #5: 2dtables .........................   Passed    0.02 sec
    Start 6: fluidsystems
6/7 Test #6: fluidsystems .....................   Passed   15.23 sec
    Start 7: immiscibleflash
7/7 Test #7: immiscibleflash ..................   Passed    0.03 sec

86% tests passed, 1 tests failed out of 7

Total Test time (real) =  32.48 sec

The following tests FAILED:
      2 - pengrobinson (SEGFAULT)
Errors while running CTest
make: *** [test] Error 8

The relevant part of Testing/Temporary/LastTest.log is

2/7 Testing: pengrobinson
2/7 Test: pengrobinson
Command: "/home/vagrant/workspace/opm/opm-material-build/bin/test_pengrobinson"
Directory: /home/vagrant/workspace/opm/opm-material-build/tests
"pengrobinson" start time: Apr 09 08:15 UTC
Output:
----------------------------------------------------------
<end of output>
Test time =   0.00 sec
----------------------------------------------------------
Test Failed.
"pengrobinson" end time: Apr 09 08:15 UTC
"pengrobinson" time elapsed: 00:00:00
----------------------------------------------------------

In debug mode, however, it appears to succeed:

vagrant@vagrant:~/workspace/opm/opm-material-build$ make test
Running tests...
Test project /home/vagrant/workspace/opm/opm-material-build
    Start 1: fluidmatrixinteractions
1/7 Test #1: fluidmatrixinteractions ..........   Passed    0.00 sec
    Start 2: pengrobinson
2/7 Test #2: pengrobinson .....................   Passed   43.68 sec
    Start 3: ncpflash
3/7 Test #3: ncpflash .........................   Passed    0.04 sec
    Start 4: tabulation
4/7 Test #4: tabulation .......................   Passed   14.63 sec
    Start 5: 2dtables
5/7 Test #5: 2dtables .........................   Passed    0.10 sec
    Start 6: fluidsystems
6/7 Test #6: fluidsystems .....................   Passed   18.25 sec
    Start 7: immiscibleflash
7/7 Test #7: immiscibleflash ..................   Passed    0.03 sec

100% tests passed, 0 tests failed out of 7

Total Test time (real) =  81.76 sec

and the same part of the log file:

2/7 Testing: pengrobinson
2/7 Test: pengrobinson
Command: "/home/vagrant/workspace/opm/opm-material-build/bin/test_pengrobinson"
Directory: /home/vagrant/workspace/opm/opm-material-build/tests
"pengrobinson" start time: Apr 09 08:19 UTC
Output:
----------------------------------------------------------
alpha[-] p[Pa] S_g[-] rho_o[kg/m^3] rho_g[kg/m^3] <M_o>[kg/mol] <M_g>[kg/mol] R_s[m^3/m^3] B_g[-] B_o[-]
0.98 4.59137e+07 7.71576e-28 593.853 153.824 0.0888336 0.012423 100.722 0.00516612 1.0375

tons of lines removed for brevity, before it ends with

{ 116260, 0.0846657 },
{ 108267, 0.0390865 }
};
<end of output>
Test time =  43.68 sec
----------------------------------------------------------
Test Passed.
"pengrobinson" end time: Apr 09 08:20 UTC
"pengrobinson" time elapsed: 00:00:43
----------------------------------------------------------

Errors in Statoil when adding tests:

I have not had the time to look at this at all - but here is the backtrace:

-- Found Doxygen: /usr/bin/doxygen (found version "1.6.1") 
CMake Error at /private/jenkins/jenkins/OPM/install/RH6/share/opm/cmake/Modules/OpmSatellites.cmake:285 (add_executable):
  add_executable called with incorrect number of arguments
Call Stack (most recent call first):
  CMakeLists.txt:97 (opm_add_test)

CMake Error at /private/jenkins/jenkins/OPM/install/RH6/share/opm/cmake/Modules/OpmSatellites.cmake:286 (target_link_libraries):
  Cannot specify link libraries for target "test_eclmateriallawmanager" which
  is not built by this project.
Call Stack (most recent call first):
  CMakeLists.txt:97 (opm_add_test)

Wrong maxPcow and maxPcgo

When I use "EclEpsScalingPoints.hpp" to output all the endpoints value in saturation tables, I get the wrong number for maxPcow and maxPcgo when the capillary pressure is not zero. I test some cases like spe1, spe3, and spe9, but it does not get the correct value in all of these cases. But I checked the code, it looks correct in the implementation. maybe something wrong in the parser? I'm not sure.

	MaterialLawParams& materialLawParams(unsigned elemIdx)
	{
	if (hasElementSpecificParameters()) {
	assert(0 <= elemIdx && elemIdx < materialLawParams_.size());
	return *materialLawParams_[elemIdx];
	}
	else
	return *materialLawParams_[satnumRegionIdx_[elemIdx]];
	}

	const MaterialLawParams& materialLawParams(unsigned elemIdx) const
	{
	if (hasElementSpecificParameters()) {
	assert(0 <= elemIdx && elemIdx < (int) materialLawParams_.size());
	return *materialLawParams_[elemIdx];
	}
	else
	return *materialLawParams_[satnumRegionIdx_[elemIdx]];
	}

	materialLawParams_.resize(numCompressedElems);
	for (unsigned elemIdx = 0; elemIdx < numCompressedElems; ++elemIdx) {
	materialLawParams_[elemIdx] = std::make_shared<MaterialLawParams>();
	unsigned satnumRegionIdx = static_cast<unsigned>(satnumRegionIdx_[elemIdx]);

	initThreePhaseParams_(deck,
	eclState,
	*materialLawParams_[elemIdx],
	satnumRegionIdx,
	*oilWaterScaledEpsInfoDrainage_[elemIdx],
	oilWaterParams[elemIdx],
	gasOilParams[elemIdx]);

	materialLawParams_[elemIdx]->finalize();

opm / opm-material Goto Github PK

opm-material's People

Contributors

Stargazers

Watchers

Forkers

opm-material's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs