Giter VIP home page Giter VIP logo

opm-material's Introduction

THIS MODULE IS DEPRECATED The material module have been integrated into opm-common

CONTENT

opm-material is an infrastructural OPM module for code related with material properties like relative-permeability/capillary pressure laws, thermodynamic relations, flash solvers, empirical heat conduction laws, et cetera. It is a "library-less" module and only requires the availability of the DUNE module "dune-common" and the "opm-common" OPM module. Additionally, the "opm-parser" can optionally be used if ECL input is supposed to be processesed. Historically, opm-material emerged as a spin-off of OPM's eWoms module [1], which in turn is a heavily modified version of the Dumux [2] simulation toolkit for flow and transport in porous media.

LICENSE

This module is distributed under the GNU General Public License, version 2 or later (GPLv2+). Note, that for these parts the DUNE template exception does NOT apply.

If you need to know the license of an individual header file, refer to the copyright statement at the beginning of each file. To avoid legal issues, the Open Porous Media initiative recommends you to use a license which is compatible with the GNU General Public license, version 3 or later (GPLv3+) for code which you publish that uses any module provided by the Open Porous Media initiative.

PLATFORMS

The opm-material module is designed to run on Linux platforms. It is also regularly run on Mac OS X. No efforts have been made to ensure that the code will compile and run on windows platforms, but contributions for this are certainly welcome.

DEPENDENCIES FOR DEBIAN BASED DISTRIBUTIONS (Debian Squeeze/Ubuntu Precise)

# packages necessary for building
sudo apt-get install -y build-essential gfortran cmake cmake-data util-linux

# packages necessary for documentation
sudo apt-get install -y doxygen ghostscript texlive-latex-recommended pgf

# packages necessary for version control
sudo apt-get install -y git-core

# basic libraries
sudo apt-get install -y libboost-all-dev

# required DUNE parts
sudo apt-get install libdune-common-dev

DEPENDENCIES FOR RED HAT ENTERPRISE LINUX (RHEL) BASED DISTRIBUTIONS

# packages necessary for building
sudo yum install make gcc-c++ gcc-gfortran cmake28 util-linux

# packages necessary for documentation
sudo yum install doxygen ghostscript texlive

# packages necessary for version control
sudo yum install git

# basic libraries
sudo yum install boost-devel

# DUNE libraries
sudo yum-config-manager --add-repo \
    http://www.opm-project.org/packages/current/redhat/6/opm.repo
sudo yum install dune-common-devel

DOWNLOADING FROM GIT

The prerequisite "dune-common" module can be downloaded like this:

git clone git://github.com/dune-project/dune-common.git -b releases/2.4

The prerequisite OPM modules are available using the following commands:

git clone git://github.com/OPM/opm-common.git
git clone git://github.com/OPM/opm-parser.git

For a read-only download of the actual opm-material module use:

git clone git://github.com/OPM/opm-material.git

If you want to contribute to the opm-material development, fork OPM/opm-material on github and open pull requests.

BUILDING

There are two ways to build the opm-material module.

As a stand-alone module.

In this setup we recommend creating an entirely separate directory outside the directory containing the source code and doing the build from that separate directory (termed "the build directory"). This configuration is sometimes referred to as an "out-of-source build".

As an example, consider the following layout in which "opm-material" refers to the directory containing the package source code as downloaded from GitHub

workspace
  |
  +-- build
  |
  +-- opm-material
  |     |
  |     +-- ...
  |     |
  |     +-- opm
  |     |
  |     +-- ...

The following command will configure a release-type (optimised) build using traditional Unix Makefiles within the "build" directory

cd path/to/build
cmake ../opm-material -DCMAKE_BUILD_TYPE=Release

If you want to debug the code, specify the build type "Debug" instead of "Release" in the command above. This will disable optimizations and make it easier to step through the code.

Building the tests shipped with the module then amounts to typing

make

in the top-level "build" directory; i.e., the directory from which we invoked the "cmake" utility. On a multi-core computer system you may want to build the software in parallel (make(1)'s "job-server" mode) in order to reduce the total amount of time needed to complete the build. To do so, replace the above "make" command with

make -j N

or, possibly,

nice -20 make -j N

in which "N" is an integer that should typically not exceed the number of cores in the system.

Once the library has been built, it can be installed in a central, system-wide location (often in /usr/local) through the command

sudo make install

As a dune module.

  • Put the opm-material directory in the same directory as the other dune modules to be built (e.g. dune-commmon, dune-grid). Note that for Ubuntu you can install Dune from the ppa as outlined above.
  • Run dunecontrol normally. For more information on the dune build system, see http://www.dune-project.org/doc/installation-notes.html

DOCUMENTATION

Efforts have been made to document the code with Doxygen. In order to build the documentation, enter the command

make doc

in the topmost directory.

REPORTING ISSUES

Issues can be reported in the Git issue tracker online at:

http://github.com/OPM/opm-material/issues

To help diagnose build errors, please provide a link to a build log together with the issue description.

You can capture such a log from the build using the script utility, e.g.:

LOGFILE=$(date +%Y%m%d-%H%M-)build.log ;
    cmake -E cmake_echo_color --cyan --bold "Log file: $LOGFILE" ;
script -q $LOGFILE -c 'cmake ../opm-material -DCMAKE_BUILD_TYPE=Debug' &&
script -q $LOGFILE -a -c 'ionice nice make -j 4 -l 3' ||
cat CMakeCache.txt CMakeFiles/CMake*.log >> $LOGFILE

The resulting file can be uploaded to for instance gist.github.com.

[1] http://opm-project.org/ewoms

[2] http://dumux.org

opm-material's People

Contributors

akva2 avatar andlaus avatar atgeirr avatar babrodtk avatar blattms avatar bska avatar dr-robertk avatar flikka avatar gitpaean avatar goncalvesmachadoc avatar hakonhagland avatar hcholle avatar hnil avatar joakim-hove avatar jokva avatar jorgekva avatar kjetilly avatar osae avatar plgbrts avatar qilicun avatar rolk avatar svenn-t avatar totto82 avatar trinemykk avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

opm-material's Issues

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>

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.

ECLMaterialLawManager::materialParams_ behaves/is used inconsistently

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

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
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.

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.

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

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.

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)

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!

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!

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?

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
----------------------------------------------------------

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.

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)

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. The MaterialLawParameters have different interfaces. Since the call are on the top level, it is a minor thing.

  6. 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.

  7. 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.

  8. The results are not dramatically, but quite a bit different. This needs to be investigated.

Comments are welcome!

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

Bug in Spline.hpp

Line

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.

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.

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.

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

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

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.

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


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.

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?

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?

[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.

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.