opm / opm-material Goto Github PK
View Code? Open in Web Editor NEWProvides thermodynamic relations, capillary pressure curves, etc.
License: Other
Provides thermodynamic relations, capillary pressure curves, etc.
License: Other
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)
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>
I get an error when I try to install opm-material from source, as it complains about dune_common.
-- 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)
/scratch/riseth/opm-project/opm-20170314/
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
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
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
opm-material/opm/material/fluidmatrixinteractions/EclMaterialLawManager.hpp
Lines 210 to 228 in 12376bc
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
opm-material/opm/material/fluidmatrixinteractions/EclMaterialLawManager.hpp
Lines 382 to 386 in 12376bc
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.
There is no checking of consistency in OilPvtMultiplexer.hpp (line 125-126)
Also if no oil properties is present flow fails without usefull meassages.
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.
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.
can be used opm-material to simulate a gas condensate reservoir?
like eclipse(E-300)
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.
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.
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
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.
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?
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. )
ParameterCache
object, the PVT region index is passed explicitly as an integer to theseParameterCache
taking variants of these methods are simple forwards to the new methodsThere 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!
After #120 a test fails, thus stopping the OPM build pipeline on Jenkins. See https://ci.opm-project.org/job/opm-material/964/
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:
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:
assert( )
?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.
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
25 20
50 50
..
/
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.
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.
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 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
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!
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?
Line
opm-material/opm/material/common/Spline.hpp
Line 1247 in 4181950
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.
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
----------------------------------------------------------
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)
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.