opm / opm-upscaling Goto Github PK

For some reason the tests we have for the upscale elasticity code now fails on the Red Hat 5 build, on the Red Hat 6 build it passes as before.

In file included from /home/edscott/GIT/OPM/opm-upscaling/opm/upscaling/writeECLData.cpp:25:
/home/edscott/GIT/OPM/opm-upscaling/opm/upscaling/writeECLData.hpp:37:21: error: unknown type name
      'time_t'
                    time_t current_posix_time,
                    ^
1 error generated.

Fixed by adding a simple:

#include <time.h>

There is an error in some of the upscaling routines, at least in 'upscale_relperm' and 'upscale_relpermvisc'. Everything builds fine, but running the applications yields wrong results. This is the command I use:

./upscale_relperm -points 5 parallel.grdecl rock1_anal_Jfun.res rock2_anal_Jfun.res

(I can provide the model on request)

Per March 12, this is the results: https://gist.github.com/604c1d16ed3efc21441e.git
Per July 11, this is the results: https://gist.github.com/65aca11eadc7669369d8.git

As can be seen from the output all upscaled quantities are 1e-12 in the newest version. The same problem is ecountered for 'upscale_relpermvisc'. The error must have been introduced in commit e138bd4 or 731dc9e, most likely the first one.

I wild guess is that it can have something to do with unit conversion.

After merging the opm-parser dependency in opm-core the tests in opm-upscaling will not build on jenkins any longer - see e.g. http://opm-project.org/CDash/index.php?project=opm-upscaling

The tests work for me when I build locally. Do not really understand what is the problem here (could it be related to permissions ??)

I built a lithofacies model in SBED and wanted to take subsamples out of it. However, I did not manage to make it. I am not sure if that my model fit to the cpchop tool. The model is in grdecl format, which can be found in this link

https://gist.github.com/adibsb/abbd7a2381617e55a7e84c5e3fb6bcfb

I ran this command: cpchop gridfilename=perm.grdecl subsamples=10

That resulted in some errors and the following was what I got:

 *** Process received signal ***
Signal: Segmentation fault (11)
Signal code: Invalid permissions (2)
 Failing at address: 0x7f5135e4e098
 [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20)[0x7f5135a84f20]
 [ 1] /usr/lib/x86_64-linux-gnu/libopmcommon.so.2018(+0xcc4fc)[0x7f5136f364fc]
 [ 2] /usr/lib/x86_64-linux-gnu/libopmcommon.so.2018(_ZNK3Opm10DeckRecord7getItemERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x3e)[0x7f5136f3c49e]
 [ 3] cpchop(_ZN3Opm18CornerPointChopperC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x4bf)[0x55dfc67848df]
 [ 4] cpchop(main+0x19e)[0x55dfc6745bee]
 [ 5] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f5135a67b97]
 [ 6] cpchop(_start+0x2a)[0x55dfc674c6ca]
 *** End of error message ***
Segmentation fault (core dumped)

Thank you guys for the great job made in OPM.
I am trying to learn some about it.

How might I use the permeability tensor that is generated by 'upscale_perm' to create a coarse grid ?

I.e, replace a fine grid (10,000 blocks) for a coarser one (1,000 blocks).

Seems the elasticity is to blame. It is compiled against Dune 2.2.0 and using dunecontrol (also for opm-core). This is the relevant output:

../dune/elasticity/elasticity_upscale_impl.hpp: In member function ‘Opm::Elasticity::BoundaryGrid Opm::Elasticity::ElasticityUpscale::extract MasterFace(Opm::Elasticity::Direction, typename GridType::LeafGridView::ctype, Opm::Elasticity::ElasticityUpscale::SIDE, bool) [with GridType = Dune::CpGrid]’:
../dune/elasticity/elasticity_upscale_impl.hpp:62: warning: ‘idx’ may be used uninitialized in this function
/private/hhgs/dev/opm-porsol/dune/porsol/common/RockJfunc.hpp: In member function ‘void Dune::RockJfunc::readStatoilFormat(std::istream&)’:
/private/hhgs/dev/opm-porsol/dune/porsol/common/RockJfunc.hpp:185: warning: ‘start.std::istream_iterator<Dune::FieldVector<double, 4>, char, std::char_ traits, long int>::_M_value.Dune::FieldVector<double, 4>::data.Dune::array<double, 4ul>::a[3u]’ may be used uninitialized in this function
/private/hhgs/dev/opm-porsol/dune/porsol/common/RockJfunc.hpp:185: warning: ‘start.std::istream_iterator<Dune::FieldVector<double, 4>, char, std::char traits, long int>::_M_value.Dune::FieldVector<double, 4>::data.Dune::array<double, 4ul>::a[2u]’ may be used uninitialized in this function
/private/hhgs/dev/opm-porsol/dune/porsol/common/RockJfunc.hpp:185: warning: ‘start.std::istream_iterator<Dune::FieldVector<double, 4>, char, std::char traits, long int>::_M_value.Dune::FieldVector<double, 4>::data.Dune::array<double, 4ul>::a[1u]’ may be used uninitialized in this function
/private/hhgs/dev/opm-porsol/dune/porsol/common/RockJfunc.hpp:185: warning: ‘start.std::istream_iterator<Dune::FieldVector<double, 4>, char, std::char traits, long int>::_M_value.Dune::FieldVector<double, 4>::_data.Dune::array<double, 4ul>::a[0u]’ may be used uninitialized in this function
/bin/sh ../libtool --tag=CXX --mode=link g++ -DNOOUTPUT -O3 -DNDEBUG -Wall -g -L/project/res/x86_64_RH_5/share/opm/boost/lib -L/project/res/x86 _64_RH_5/share/opm/boost/lib -o upscale_relpermvisc upscale_relpermvisc.o -lboost_unit_test_framework -lboost_filesystem -lboost_system -llapack -l blas -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lgfortran begin -lgfortran -lm -lgcc_s -L/private/hhgs/dev/opm-porsol/lib -lopmporsol -llapack -lblas -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr /lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lgfortranbegin -lgfortran -lm -lgcc_s -L/private/hhgs/dev/du ne-cornerpoint/lib -ldunecornerpoint -lboost_date_time -lboost_filesystem -lboost_system -L/private/hhgs/dev/opm-core/li b -lopmcore -L/private/hhgs/dev/dune-grid-2.2.0/lib -ldunegrid -L/private/hhgs/dev/dune-geometry-2.2.0/lib -ldunegeometry -L/private/hhgs/dev/dune -common-2.2.0/lib -ldunecommon
g++ -DNOOUTPUT -O3 -DNDEBUG -Wall -g -o upscale_relpermvisc upscale_relpermvisc.o -L/project/res/x86_64_RH_5/share/opm/boost/lib -L/usr/lib/gcc/x86_64 -redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/private/hhgs/dev/opm-porsol/lib / private/hhgs/dev/opm-porsol/lib/.libs/libopmporsol.a -L/private/hhgs/dev/dune-cornerpoint/lib -L/private/hhgs/dev/dune-grid-2.2.0/lib -L/private/hhgs/d ev/dune-geometry-2.2.0/lib -L/private/hhgs/dev/dune-common-2.2.0/lib -L/private/hhgs/dev/opm-core/lib -lm -lgcc_s /private/hhgs/dev/dune-cornerpoint/li b/.libs/libdunecornerpoint.a /private/hhgs/dev/opm-core/lib/.libs/libopmcore.so -lboost_filesystem -lboost_system -lboost_date_time -lboost_unit_test_f ramework -lgfortranbegin -lgfortran -lblas /private/hhgs/dev/dune-grid-2.2.0/lib/.libs/libdunegrid.a /private/hhgs/dev/dune-geometry-2.2.0/lib/.libs/li bdunegeometry.a /private/hhgs/dev/dune-common-2.2.0/lib/.libs/libdunecommon.a -llapack -Wl,--rpath -Wl,/private/hhgs/dev/opm-core/lib/.libs -Wl,--rpa th -Wl,/usr/local/lib
make[2]: *** [upscale_elasticity-upscale_elasticity.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory /private/hhgs/dev/opm-upscaling/examples' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory/private/hhgs/dev/opm-upscaling'
make: *** [all] Error 2
--- Failed to build opm-upscaling ---
Terminating dunecontrol due to previous errors!

Currently it is installed and ends up in the Debian packages. Yet, it is hard to judge what it is doing. No -h supported, no manpage, etc. Would be cool if somebody would add that.

There seem to have been some changes for the programs, e.g cpchop prints:

./opm-parallel/bin/cpchop
Usage: cpchop gridfilename=filename.grdecl [subsamples=10] [ilen=5] [jlen=5] 
       [zlen=5] [imin=] [imax=] [jmin=] [jmax=] [upscale=true] [bc=fixed]
       [resettoorigin=true] [seed=111] [minperm=1e-9] 
       [dips=false] [azimuthdisplacement=] [satnumvolumes=false] [mincellvolume=1e-9]
       [filebase=] [resultfile=] [endpoints=false] [cappres=false]
       [rock_list=] [anisotropicrocks=false]

and the manpage does not reference all.
Cool, if somebody could update this (and the rest). I don't feel competent enough for this.

Found a mistake in my own code while attempt to refactor - flux is computed from the faceiter.

The elasticity tests fail as follows:

      Start 11: run_upscale_elasticity_mpc_EightCells
11/14 Test #11: run_upscale_elasticity_mpc_EightCells ..........***Exception: Other  0.50 sec

(the remainder also fails)

I finally figured out how to run the tests by looking at the generated CTestTestfile.cmake... The result is as follows:

 failed to locate -0.5 0
Assertion failed: (0), function find, file /Users/atgeirr/opm-build-debug/opm-upscaling/opm/elasticity/boundarygrid.cpp, line 145.

I have not made any attempt to understand why it fails. @akva2 do you have a clue?

After running cpchop with a huge number of random subsamples (e.g. 2000), the mean of subsample porosities differ from upscaled porosity for full model. The difference seem to be larger the larger the subsamples are. If cpchop is used on full model (no subsampling), upscaled porosity is equal to the upscaled porosity from e.g. upscale_avg. I have a testmodel available to send by email if needed (too large for gist). Could the problem be due to a bias in the random sampling?

make[3]: Entering directory /home/mblatt/src/dune/opm/opm-upscaling/dune/elasticity' CXX boundarygrid.lo In file included from /home/mblatt/src/dune/opm/dune-geometry/dune/geometry/referenceelements.hh:8:0, from boundarygrid.hh:17, from boundarygrid.cpp:12: /home/mblatt/src/dune/opm/dune-common/dune/common/nullptr.hh:27:1: error: expected ';' after class definition /home/mblatt/src/dune/opm/dune-common/dune/common/nullptr.hh:27:1: error: qualifiers can only be specified for objects and functions /home/mblatt/src/dune/opm/dune-common/dune/common/nullptr.hh:27:3: error: expected unqualified-id before 'nullptr' make[3]: *** [boundarygrid.lo] Fehler 1 make[3]: Leaving directory/home/mblatt/src/dune/opm/opm-upscaling/dune/elasticity'

The error message is
*** The MPI_Comm_rank() function was called before MPI_INIT was invoked.
*** This is disallowed by the MPI standard.
*** Your MPI job will now abort.

The problem is that MPI_INIT is never called. I will provide a fix for the test.

Hi,
When I tried to build opm-upscaling, the following errors happened. I have already compile opm-material opm-porsol opm-benchmarks.

CMake Error at EmbedCases.cmake:46 (add_dependencies):
  Cannot add target-level dependencies to non-existent target
  "upscale_relperm_benchmark".

  The add_dependencies works for top-level logical targets created by the
  add_executable, add_library, or add_custom_target commands.  If you want to
  add file-level dependencies see the DEPENDS option of the add_custom_target
  and add_custom_command commands.
Call Stack (most recent call first):
  EmbedCases.cmake:50 (opm_pack_stone)
  CMakeLists.txt:165 (include)


CMake Error at EmbedCases.cmake:38 (add_dependencies):
  Cannot add target-level dependencies to non-existent target
  "upscale_relperm_benchmark".

  The add_dependencies works for top-level logical targets created by the
  add_executable, add_library, or add_custom_target commands.  If you want to
  add file-level dependencies see the DEPENDS option of the add_custom_target
  and add_custom_command commands.
Call Stack (most recent call first):
  EmbedCases.cmake:51 (opm_pack_case)
  CMakeLists.txt:165 (include)


CMake Error at CMakeLists.txt:168 (include):
  include could not find load file:

    OpmStaticTargets


CMake Error at CMakeLists.txt:169 (opm_from_git):
  Unknown CMake command "opm_from_git".


-- Configuring incomplete, errors occurred!

Referring to the wiki page
http://www.opm-project.org/wiki/index.php/Dune-elasticity-upscale
is this a separate module that should be on github?
Should it be named something with opm?

See http://opm-project.org/CDash/index.php?project=opm-upscaling

Since Dune 2.3 is going to be released soon, this issue should be fixed until the OPM 2014.03 release...

Hello,

No real issue here, just a question and looking for advice (and not signed up for mailing list yet). I'm currently exploring replacing some of the DUNE-based solvers in OPM with PETSc based solvers and I came across @jokva 's thesis. To @jokva I just wanted to confirm; this petsc-support branch contains all of the code relevant to your thesis and any further work with utilizing PETSc libraries within opm correct? And what is the best way to clone this/get OPM running on my local system using the petsc library/your code? (apologies if that is a dumb question, I'm still learning and somewhat blindly followed the OPM instruction guide without much understanding of how to change the repo the backend is running from).

Additionally, to all, are there other good examples of where petsc solvers have been leveraged within OPM, and if so do they utilize GPUs (and where could I find these exapmles?). I am very new to the OPM codebase so any help or guidance is greatly appreciated!

Sincerely,
Kenneth Meyer

Commit 77ff7dc (which pulls in a814aa6) causes a build failure on my machine. The specific error is:

CXXLD steadystate_test_implicit

steadystate_test_implicit.o: In function `Dune::SteadyStateUpscalerImplicit<Dune::SimulatorTraits<Dune::Isotropic, Dune::Implicit> >::upscaleSteadyState(int, std::vector<double, std::allocator > const&, double, double, Dune::FullMatrix<double, Dune::OwnData, Dune::COrdering> const&, bool&)':

/datavol/src/phd/opm_new/opm-upscaling/dune/upscaling/test/../../../dune/upscaling/SteadyStateUpscalerImplicit_impl.hpp:241: undefined reference to `Opm::writeECLData(UnstructuredGrid const&, std::map<std::string, std::vector<double, std::allocator > const_, std::lessstd::string, std::allocator<std::pair<std::string const, std::vector<double, std::allocator > const_> > > const&, int, double, boost::posix_time::ptime const&, std::string const&, std::string const&)'

collect2: error: ld returned 1 exit status

This is presumably because HAVE_ERT is not defined in opm-core/opm/core/utility/writeECLData.cpp on my system, while Opm::writeECLData is used regardless in opm-upscaling/dune/upscaling/SteadyStateUpscalerImplicit_impl.hpp.

I'm not at all familiar with this code though, so I hope the solution is obvious to those that are.

The application examples/upscale_relperm comes with an MPI feature. If HAVE_MPI is defined, then upscale_relperm.cpp is compiled in parallel mode. What is the best way to tell cmake that HAVE_MPI should be defined? I have tried using -DUSE_MPI=ON, but have encountered some problems in that MPI packages can not be found:

Unable to find MPI library {rdmacm, ibverbs, numa}

It seems like cmake can't find the MPI libraries. If -DUSE_MPI=ON is the correct way to do this, how can I specify where to look for the MPI libraries?

Hi,
I am trying to build OPM for MacOS. I'm unable to compile the Upscaling route. I tried follow the method presented in the OPM installing from source page on the website.
The error as

too many template arguments for class template 'LeafMultipleCodimMultipleGeomTypeMapper'

This pops up while processing the file opm/upscaling/RelPermUtils.cpp. Just for reference I am including CmakeCache, Error log files.

CMakeCache.txt
CMakeError.log
CMakeOutput.log

Any suggestion and help would be appreciated.
Thanks everyone in advance for your suggestion.

I'm trying to test upscale_perm with the following GRDECL file:

SPECGRID
3 4 5 1 F /

COORD
COORD.dat /

ZCORN
ZCORN.dat /

PERMX
PERMX.dat /

PERMY
PERMY.dat /

PERMZ
PERMZ.dat /

PORO
PORO.dat /

ACTNUM
ACTNUM.dat /

I get the following error:

Parsing Eclipse file </mnt/d/core-ups/opm-wsl/daily_work/2022_07_21/problem_floating_point/scripting_example/out/simple.grdecl> ... Program threw an exception: Problem with keyword COORD
In /mnt/d/core-ups/opm-wsl/daily_work/2022_07_21/problem_floating_point/scripting_example/out/simple.grdecl line 4.
Internal error: Malformed floating point number 'COORD.dat'
terminate called after throwing an instance of 'std::_Nested_exception<Opm::OpmInputError const>'
  what():  Problem with keyword COORD

However, if I copy the contents of COORD.dat file into the GRDECL, everything works normally. I'm not sure it is related to line endings in Linux/Windows, since I'm using OPM within WSL (Windows Subsystem for Linux). Any ideas about what might be happening?

Thanks!
Rafael March.

I guess this is intentional, with commit 9edfe8a
but it would be great to get confirmation.

Fallout after: OPM/opm-grid#207??

Opm::EclipseGridInspector::EclipseGridInspector(std::shared_ptr<Opm::Deck const>)'
/private/jenkins/jenkins/OPM/install/RH6/include/opm/porsol/common/ReservoirPropertyCommon_impl.hpp:766: undefined reference to `Opm::EclipseGridInspector::gridSize() const'

Methods UpscalerBase<>::computeDelta() and UpscalerBase<>::computeAverageVelocity() use PeriodicConditionHandler::getCanonicalBoundaryId() to assign pressure and flux contributions to appropriate flow directions. The canonical boundary IDs are assigned through calls to UpscalerBase<>::setCanonicalBoundaryId().

In the case of linear pressure drops, function Opm::createLinear() uses a geometry-based approach to identify the canonical boundary segment of each boundary intersection. This calculation potentially fails unless the model geometry is a Cartesian box. Consequently, any upscaling method that derives from UpscalerBase<> and uses UpscalerBase<>::computeEffectivePerm() as part of its implementation, will therefore fail when applying Linear boundary conditions on non-Cartesian geometries.

If we want to lift this restriction I can see a couple of possible remedies

• Applying vertical truncation (i.e., clip_z) to input models (simple implementation, just need to expose the option, and/or apply the fix unconditionally).

• Add a new "non-interface" Dune::cpgrid::Intersection method, globalBoundaryId(), that captures the "non-unique" boundary ID case of Dune::cpgrid::Intersection::boundaryId() and reimplement the global boundary ID in terms of the new method. We can thread this method it through class Opm::GIE::Face so we don't have to reimplement all upscaling codes in terms of class Dune::CpGrid, but we would effectively be limiting the upscaling code to CpGrid nonetheless.

• Repurpose Dune::cpgrid::Intersection::boundarySegmentIndex() to return the non-unique branch of the current boundaryId() and reimplement boundary identification in terms of boundarySegmentIndex(). This might break some assumptions of the Dune grid interface but will be okay for the only grid we really care about.

• Actually reimplement all upscaling codes in terms of CpGrid and discard any notion that the upscaling module works on any Dune grids. Then we can do whatever we like.

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.

In function ‘int main(int, char**)’:
/home/akva/kode/opm-new/rg/opm-upscaling/src/opm-upscaling/examples/cpchop.cpp:391:25: warning: ‘Pcmin’ may be used uninitialized in this function [-Wuninitialized]
/home/akva/kode/opm-new/rg/opm-upscaling/src/opm-upscaling/examples/cpchop.cpp:332:71: note: ‘Pcmin’ was declared here

the logic error is pretty obvious, there's a (theoretical?) option to not set Pcmincandidate in the block further up, and thus Pcmin may end up uninitialized due to the std::min() call.

sadly i'm not the correct person to come up with a fix as i don't have the complete overview. annotate points to kari b skjerve (dunno her hub user), though i have a suspicion she only did the commit.

[This issue was originally created by @laods in the Resinsight repository. The problem is not really with ResInsight but rather opm-core / opm-upscaling / opm-porsol and ERT. I have therefor moved the issue here. Joakim]

This issue has been discussed via e-mail for some time (at least @joakim-hove, @hhgs, @magnesj and myself has been involved), but for the sake of openness it really belongs to the GitHub issue tracker. I choose to open it here, but it is not clear to me whether this issue belongs here or in another OPM module, e.g. opm-core or opm-upscaling.

The problem is that not all eclipse output files from the upscaling application steadystate_test_implicit are possible to open in ResInsight. The produced EGRID file opens fine, but the UNRST files are not possible to open. Three issues have been identified:

* The basename (without extension) of all eclipse output files must be identical.
* ERT crashes when time stampes are prior to 1970.
* The number of active cells in the EGRID files does not match the number of parameter values in the UNRST files.

By this issue I do not intend to push those of you already working on it, but it is probably for the best to let the hole community of OPM be aware of it.

error:

[100%] Creating packed binary of benchmarks/input/stonefile_benchmark
gmake[2]: ../benchmarks/input/create_hex_data_file.sh: No such file or directory
gmake[2]: *** [CMakeFiles/stonefile.dir/build.make:82: benchmarks/input/stonefile_benchmark.txt.gz.hex] Error 127
gmake[1]: *** [CMakeFiles/Makefile2:2114: CMakeFiles/stonefile.dir/all] Error 2
gmake: *** [Makefile:161: all] Error 2
--- Failed to build opm-upscaling ---

fix:
create_hex_data_file.sh.patch.txt
In Linux /bin/sh is the same thing as /bin/bash. But in FreeBSD bash is not necessarily installed. But /bin/sh works just fine for such a simple script.

--- benchmarks/input/create_hex_data_file.sh.orig	2020-10-17 14:09:04.707214000 -0500
+++ benchmarks/input/create_hex_data_file.sh	2020-10-17 14:08:53.035480000 -0500
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 #
 # This script takes an input file and dump it in hexadecimal (1 byte) format
 # The second input is the name of the output file

Hi,

We (@cfbe and I) are running steadystate_test_implicit on a large amount of models, and have encountered some convergence problems. With the default criteria, about 1/3 of our saturation points did not converge (e.g., stationary solution not found). We have tried to change both max_it and sat_change_year, but only seen small improvements.

However, when we plot the upscaled rel.perm. against water saturation, the points lie on a smooth curve (apart from some very few outliers). Hence, it might seems like the convergence criteria is too strong. Today the stopping criteria is based on the maximum saturation change in the cells. This means that if we have some ill-conditioned cells (maybe close to zero volume), the convergence may fail. We thought therefore that it would be better to use some kind of averaging criteria, possibly weighted with pore volume.

We have implemented and tested a stopping criteria based on this:

avg_diff = sqrt ( sum( (sat_old - sat)^2) * pore_vol ) / tot_pore_vol)

This is clearly a looser criteria, but those saturation points that seemed like outliers on the plot are still marked as unsuccessful.

Any thoughts on this?

I have some linker problems when calling binaries created by make install. For bin/upscale_perm, I get the following error message:

error while loading shared libraries: libboost_system.so.1.45.0: cannot open shared object file: No such file or directory

When calling ldd upscale_perm no references to boost-system, ecl (ERT) or dune-common are found (libboost_system.so.1.45.0 => not found). These are the libraries that are not installed in default system locations. Similar problems are encountered for other binaries and for other OPM modules. I have tested both the release/2013.03 and the master branch.

These are my options for cmake:

DUNE_ROOT="/project/res/x86_64_RH_5/share/opm/dune"
SUPERLU_ROOT="/project/res/x86_64_RH_5/share/opm/SuperLU_4.0"
BOOST_ROOT="/project/res/x86_64_RH_5/share/opm/boost"
ERT_ROOT="/project/res/x86_64_RH_5/share/ert/release/opm-2013.03"
CMAKE_INSTALL_PREFIX=/project/multiscale/OPM/release-2013.03/install/opm-upscaling

Calls to make and make install are run successfully.

What causes this linker problem?

Hello,

I'm checking if I can use opm-upscaling for relative permeability upscaling using two-phase flow numerical simulations. I understood upscale_relperm.cpp performs upscaling considering the capillary limit, upscale_relpermvisc.cpp performs upscaling considering the viscous limit. Do we have an out-of-the-box code to perform upscaling in the range between both limits? That is, actually running the fluid displacement simulation? Is it what upscale_steadystate_implicit.cpp does?

Thanks,
Rafael.

One of our Jenkins job (OPM-Deploy-RH6) has failed since July 25.

The error is in the upscale_relperm_BC*_pts30_surfTens11_stone1_stone*_EightCells tests, and the failure seems to be that Jenkins is unable to actually compare the output:

[/private/jenkins/jenkins/RH6/workspace/OPM-Deploy-RH6/opm-upscaling/tests/compareUpscaling.cpp:35] Could not open file.

Has anyone seen this error before? I have tried to wipe the workspace, but that didn't help.

cpchop does not run on Red Hat 5, complains about initializing MPICH. The code runs nicely on Red Hat 6. Output is found here: https://gist.github.com/alfbr/6864218

It seems something is fishy with the packaging of Dune for Ubuntu 12.04. If I build both Dune and OPM from source, everything now builds smoothly. If I use the more convenient option of installing Dune packages through the available ppa (both routes using Dune 2.2), then a number of upscaling codes segfaults. The elasticity code built fine, but most others seem to segfault.

Not sure how critical this is, so I am not sure it makes a lot of sense to spend resources on it. However, if we do nothing about it, we should change the README file for opm-core so that no users will use the ppa.

Thoughts are most welcome.

In the last commit I added two references solutions and one grid:

• 16cells.grdecl
• upscale_relperm_gravityDailyVersion_16cells.txt
• upscale_relperm_gravitySBEDVersion_16cells.txt

It has been necessary to create a new grid with SBED to use the original relperm upscaling code and compare the results with the ones obtained with the daily version of the code. It shows significant discrepancies: the daily version of the program does not seem to take the gravity effect into account contrary to SBED.

In addition, the periodic option for the boundary conditions has been tested with the Dailly and installed version of the relperm upscaling code with the following grid:

• Eightscells
• Hummocky
• 16cells
• 27cellsIso
• PeriodicTilted
• benchmark_tiny_grid

If the daily version program gives results with the Eightcells grid and the 27cellsIso grid (and the installed version gives results for the 27cellsIsso and benchmark grids), most of the time the program run and then the "core dumped" (or do not run at all for the daily version with the 16cells grid).

W: libopm-upscaling-bin: binary-without-manpage usr/bin/cpchop
W: libopm-upscaling-bin: binary-without-manpage usr/bin/cpchop_depthtrend
W: libopm-upscaling-bin: binary-without-manpage usr/bin/cpregularize
W: libopm-upscaling-bin: binary-without-manpage usr/bin/exp_variogram
W: libopm-upscaling-bin: binary-without-manpage usr/bin/grdecldips
W: libopm-upscaling-bin: binary-without-manpage usr/bin/steadystate_test_implicit
W: libopm-upscaling-bin: binary-without-manpage usr/bin/upscale_avg
W: libopm-upscaling-bin: binary-without-manpage usr/bin/upscale_cap
W: libopm-upscaling-bin: binary-without-manpage usr/bin/upscale_cond
W: libopm-upscaling-bin: binary-without-manpage usr/bin/upscale_elasticity
W: libopm-upscaling-bin: binary-without-manpage usr/bin/upscale_perm
W: libopm-upscaling-bin: binary-without-manpage usr/bin/upscale_relperm
W: libopm-upscaling-bin: binary-without-manpage usr/bin/upscale_relperm_benchmark
W: libopm-upscaling-bin: binary-without-manpage usr/bin/upscale_relpermvisc
W: libopm-upscaling-bin: binary-without-manpage usr/bin/upscale_singlephase
W: libopm-upscaling-bin: binary-without-manpage usr/bin/upscale_steadystate_implicit

I feel a bit underqualified for this (and might be missing steam). Unfortunately, help2cmake -N --version-string 2021.04 -h "" <prog> is not 100% helpful (just as the help printed) and needs quite a bit of editing. Would be cool if someone else would find time for this.

Commit OPM/opm-material@d4c220e (PR OPM/opm-material#138) turns the ParameterCace of each FluidSystem into a template that depends on an Evaluation. This breaks the build of examples/co2_blackoil_pvt.cpp and examples/sim_c02_impes.cpp and basically everything that uses the opm-material dependent file opm/porsol/blackoil/co2fluid/BlackoilCo2Fluid.hpp

The quick work-around that restores the build of opm-upscaling is to apply the patch below (i.e., to disable the build of examples that depend on opm-material's FluidSystem implementation). That may even be the correct solution--at least if we do not foresee future development of this part of opm-upscaling. The other way is to bring BlackoilCo2PVT.hpp up to date with the API-update from opm-material.

diff --git a/CMakeLists_files.cmake b/CMakeLists_files.cmake
index bbb4baf..0bde818 100644
--- a/CMakeLists_files.cmake
+++ b/CMakeLists_files.cmake
@@ -82,7 +82,7 @@ list (APPEND TEST_DATA_FILES
 list (APPEND EXAMPLE_SOURCE_FILES
        examples/aniso_implicitcap_test.cpp
        examples/aniso_simulator_test.cpp
-       examples/co2_blackoil_pvt.cpp
+       # examples/co2_blackoil_pvt.cpp
        examples/cpchop.cpp
        examples/cpchop_depthtrend.cpp
        examples/cpregularize.cpp
@@ -94,7 +94,7 @@ list (APPEND EXAMPLE_SOURCE_FILES
        examples/mimetic_periodic_test.cpp
        examples/mimetic_solver_test.cpp
        examples/sim_blackoil_impes.cpp
-       examples/sim_co2_impes.cpp
+       # examples/sim_co2_impes.cpp
        examples/sim_steadystate_explicit.cpp
        examples/sim_steadystate_implicit.cpp
        examples/steadystate_test_implicit.cpp
@@ -131,7 +131,7 @@ list (APPEND PROGRAM_SOURCE_FILES
        examples/exp_variogram.cpp
        examples/grdecldips.cpp
        examples/sim_blackoil_impes.cpp
-       examples/sim_co2_impes.cpp
+       # examples/sim_co2_impes.cpp
        examples/steadystate_test_implicit.cpp
        examples/upscale_avg.cpp
        examples/upscale_cap.cpp

If I install the package libopm-upscaling1-bin from the opm ppa, and try to run upscale_singlephase, I get the message:

upscale_singlephase: error while loading shared libraries: libdunecornerpoint.so.1: cannot open shared object file: No such file or directory

If I do

sudo apt-get install libdunecornerpoint1

everything works fine.

OPM/opm-core@5365684 is not taken into this project, any reason, or just a small slip?

K

upscale_relperm crashes if surface_tension is zero, which would be the case if the contact angle is 90 degrees. In this case, the capillary pressure is zero for all saturations, and capillary pressure cannot be used to distribute saturations.

If surface_tension is negative, corresponding to a contact angle over 90 degrees (oil-wet), upscale_relperm exits gracefully with the error message that no valid capillary pressure points can be found for this system.

Upscaled Kr(Sw) is indifferent to the surface tension scaling, and a possible fix could be to postpone the incorporation of surface_tension until the end result is printed (by just scaling the outputted Pc-vector appropriately).

In file included from ../../../dune/upscaling/SteadyStateUpscalerImplicit.hpp:135:0,
from steadystate_test_implicit.cpp:41:
../../../dune/upscaling/SteadyStateUpscalerImplicit_impl.hpp:46:45: fatal error: opm/core/utility/writeECLData.hpp: No such file or directory
compilation terminated.

While working on DUNE 2.9 Debian packages I realize, e.g.:

[ 66%] Built target tests
In file included from /build/opm-upscaling-2022.10+ds/opm/porsol/common/SimulatorTraits.hpp:43,
                 from /build/opm-upscaling-2022.10+ds/opm/upscaling/UpscalingTraits.hpp:38,
                 from /build/opm-upscaling-2022.10+ds/opm/upscaling/SinglePhaseUpscaler.hpp:39,
                 from /build/opm-upscaling-2022.10+ds/opm/upscaling/RelPermUtils.hpp:33,
                 from /build/opm-upscaling-2022.10+ds/examples/upscale_cap.cpp:67:
/build/opm-upscaling-2022.10+ds/opm/porsol/mimetic/IncompFlowSolverHybrid.hpp:158:35: warning: 'template<class _Arg1, class _Arg2, class _Result> struct std::binary_function' is deprecated [-Wdeprecated-declarations]
  158 |         class axpby : public std::binary_function<T,T,T> {
      |                                   ^~~~~~~~~~~~~~~
In file included from /usr/include/c++/12/bits/stl_tree.h:65,
                 from /usr/include/c++/12/map:60,
                 from /usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/ompi/mpi/cxx/mpicxx.h:42,
                 from /usr/lib/x86_64-linux-gnu/openmpi/include/mpi.h:2887,
                 from /usr/include/dune/common/parallel/mpihelper.hh:10,
                 from /build/opm-upscaling-2022.10+ds/examples/upscale_cap.cpp:60:
/usr/include/c++/12/bits/stl_function.h:131:12: note: declared here
  131 |     struct binary_function
      |            ^~~~~~~~~~~~~~~

cpchop gets segmentation fault when run with endpoints=true. run with output is found here: https://gist.github.com/karbor/6901965
when the exact same is run with an old version of cpchop (from June 2012) it runs fine.