Giter Site home page Giter Site logo

opm / opm-output Goto Github PK

View Code? Open in Web Editor NEW
3.0 3.0 21.0 962 KB

This repository is intended for output-writer functionality for the flow simulators in OPM

Home Page: http://www.opm-project.org

License: GNU General Public License v3.0

CMake 1.22% Shell 0.20% C++ 98.58%

opm-output's People

Contributors

akva2 avatar andlaus avatar atgeirr avatar babrodtk avatar blattms avatar bska avatar gitpaean avatar joakim-hove avatar jokva avatar ptaule avatar sveinung-r avatar totto82 avatar

Stargazers

 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  avatar

opm-output's Issues

NUMRES value inside the EGRID File

I was trying to visualize the data output by OPM with our own 3D visualizer, but it turned out it cannot because OPM does not write the NUMRES property inside the EGRID file. It should be 1 by default.

RPTRST switch FLOWS

Within the IOR Centre there is the desire to couple OPM with IORSim through restart files (as a first step). IORSim relies on the output of inter block flow fields. The output of these values is done by the switch FLOWS as part of the RPTRST keyword.

What is the best way to add this functionality? The flow fields are obviously available in OPM and the output of face values should also be available.

WGOR unit is not properly handled for FIELD.

For example, for SPE1CASE2, which is using FIELD unit system, the output from OPM is 177 or 178 times of the output from Eclipse, which is approximately the ratio of the unit Mscf and stb.

The WOPR under FIELD unit is Mscf/stb.

I am not sure how the unit is handled in the summary part, while for this case, something need to be changed.

What are the keywords related to the following three variables?

Or they just been used by other keywords, and they should be populated all the time?

template<> constexpr
measure rate_unit< rt::reservoir_water >() { return measure::rate; }

template<> constexpr
measure rate_unit< rt::reservoir_oil >() { return measure::rate; }

template<> constexpr
measure rate_unit< rt::reservoir_gas >() { return measure::rate; }

And they have been always used by summing all of them up together. What is the purpose to have three of them instead of having only one to account the sum of them?

I am not familiar with this part, excuse me if I oversaw something here.

about the summary output

Now, if we specify one record twice, we will get two same output in the summary file.

For example, if we put

WGPR
   'PROD01'
/ 

WGPR
   'PROD01'
/ 

or We put

WGPR
   'PROD01'
/ 

ALL

in the SUMMARY section, we will have two same WGPR output for well PROD01. I think there are some other occasions can trigger repeated output in the summary file, while I did not try.

I am wondering if it is possible to remove the repeated output. I do not think it is a big problem, while better to have.

Efficiency factor and output of well rates

Currently the output code does not take into account the well efficiency factor.
The total water production is in the current code:

{ "WWPT", mul( rate< rt::wat, producer >, duration ) },

This can be fixed in the output code by quarrying the efficiency factor for wells and groups from the parser and apply it here and in similar places.

TCPU summary output has intermediate zero values

flow outputs TCPU as a summary vector (wall clock time or close to it as a function of simulator date), but values are only printed for report dates, not the intermediate time stepping, like this:

$ summary.x FOO.DATA TCPU
-- Days   dd/mm/yyyy               TCPU 
----------------------------------------
   0.00   01/12/2017                  0 
   1.00   02/12/2017                  0 
   4.00   05/12/2017                  0 
  13.00   14/12/2017                  0 
  31.00   01/01/2018            203.478 
  85.00   24/02/2018                  0 
  93.49   04/03/2018                  0 
 118.95   29/03/2018                  0 
 195.34   14/06/2018                  0 
 320.34   17/10/2018                  0 
 396.00   01/01/2019            665.793 
 521.00   06/05/2019                  0 
 646.00   08/09/2019                  0 
 761.00   01/01/2020            909.397 
 886.00   05/05/2020                  0 
1011.00   07/09/2020                  0 

while not a bug, this tends to plot ugly unless worked around. Eclipse 100 reports TCPU at all these timesteps.

Does the restart output supports the polymer related now?

I tried to put POLYMER under RTRST or RTSCHED, while I could not find any polymer related output in the UNRST file.

Before I investigate more, I would like to have some ideas on whether we have this kind of support yet.

Thanks.

The summary file not working with some MRST reading functions any more

I have been using the same routine readSummaryLocal from MRST to read the summary file from OPM for long.

Now the problem happens when reading the .SMSPEC file. When reading some data type information (INTE, REAL, DOUB, etc.). A new type like �H or H appears now and it causes problem with MRST.

The routine still works well with the SUMMARY files from the Eclipse.

Anyone working with output routines has any clue? or which part I should look at the output code to figure out the possible reason?

Thanks.

Weird result from flow simulation

When running flow on the SPE9_CP data set I get a rather strange (single) value in one of the summary vectors compared to the eclipse reference solution. This is for time 40.00.

summary.x ~/opm-data/spe9/eclipse-simulation/SPE9_CP WBHP:PRODU9

   0.00   01/01/2015            3861.91                                                                    
   4.00   05/01/2015            2825.35                                                                    
  10.00   11/01/2015             2627.5                                                                    
  15.00   16/01/2015            2477.92                                                                    
  20.00   21/01/2015            2305.46                                                                    
  30.00   31/01/2015            1762.71                                                                    
  40.00   10/02/2015            1440.15                                                                    
  50.00   20/02/2015            1363.26                                                                    
  60.00   02/03/2015            1272.22                                                                    
  70.00   12/03/2015            1152.84                                                                    
  80.00   22/03/2015               1000                                                                    
  90.00   01/04/2015               1000                                                                    
 100.00   11/04/2015               1000                                                                    
 110.00   21/04/2015               1000                                                                    
 120.00   01/05/2015               1000                                                                    
 130.00   11/05/2015               1000                                                                    
 140.00   21/05/2015               1000              

summary.x ~/spe9_2/SPE9_CP WBHP:PRODU9

0.00     01/01/2015            3823.46                 
10.00    11/01/2015            2634.62                 
20.00    21/01/2015             2295.8                 
30.00    31/01/2015            1752.79                 
40.00    10/02/2015               1000                 
50.00    20/02/2015            1417.95                 
60.00    02/03/2015            1268.17                 
70.00    12/03/2015            1151.14                 
80.00    22/03/2015               1000                 
90.00    01/04/2015               1000                 
100.00   11/04/2015               1000                 
110.00   21/04/2015               1000                 
120.00   01/05/2015               1000                 
130.00   11/05/2015               1000                 
140.00   21/05/2015               1000                 

I'm not sure if the issul lies in flow or in the SPE9_CP_DATA.

Compile failure for current master

I get the following compile error (and so does Travis):

/Users/atgeirr/opm-build-debug/opm-output/opm/output/eclipse/Summary.cpp:664:21: error: reference to 'conversions' is ambiguous
    using namespace conversions;
                    ^
/Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/Units/ConversionFactors.hpp:240:11: note: candidate found by name lookup is 'Opm::conversions'
namespace conversions {
          ^
/Users/atgeirr/opm-build-debug/opm-output/opm/output/eclipse/Summary.cpp:62:11: note: candidate found by name lookup is 'Opm::(anonymous namespace)::conversions'
namespace conversions {
          ^
/Users/atgeirr/opm-build-debug/opm-output/opm/output/eclipse/Summary.cpp:667:51: error: use of undeclared identifier 'metric'
        case UnitSystem::UNIT_TYPE_METRIC: return metric;
                                                  ^
/Users/atgeirr/opm-build-debug/opm-output/opm/output/eclipse/Summary.cpp:668:50: error: use of undeclared identifier 'field'
        case UnitSystem::UNIT_TYPE_FIELD: return field;
                                                 ^
/Users/atgeirr/opm-build-debug/opm-output/opm/output/eclipse/Summary.cpp:669:25: error: use of undeclared identifier 'metric'
        default: return metric;

It should perhaps be simple to fix, but I cannot quite figure out how to refer to an anonymous namespace nested inside (!) the Opm namespace. I propose either to drop the anonymous namespace, move it to the outer scope (it's a cpp file so no problem) or use the name "details".

I don't think I know what is supposed to happen when nesting anonymous namespaces, and my first rule of C++ is that if I don't understand it it is bad...

Summary output seemingly doubled?

(sorry, accidentally hit enter)

When processing the summary output with the plotwells.sh utility from opm-data, I get all well figures twice. I do not know if it is a bug in the script that has been exposed by minor changes to output, or if the output is wrong.

Building issue in a cluster

Hello, I had the following problem when I was trying to build opm-output in a cluster Stampede2 (https://www.tacc.utexas.edu/systems/stampede2).
I was able to build all the modules (dune-common dune-istl dune-geometry dune-grid libecl opm-common opm-parser opm-grid opm-material opm-output ewoms opm-simulators) in my local macbook in the same way. However, it did not somehow work in the cluster with Intel compiler. Can you tell what the problem is here?


Configuration message (cmake $OPM_CMAKE_OPTIONS ..)

-- The C compiler identification is Intel 17.0.0.20170411
-- The CXX compiler identification is Intel 17.0.0.20170411
-- Check for working C compiler: /opt/intel/compilers_and_libraries_2017.4.196/linux/mpi/intel64/bin/mpicc
-- Check for working C compiler: /opt/intel/compilers_and_libraries_2017.4.196/linux/mpi/intel64/bin/mpicc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /opt/intel/compilers_and_libraries_2017.4.196/linux/mpi/intel64/bin/mpicxx
-- Check for working CXX compiler: /opt/intel/compilers_and_libraries_2017.4.196/linux/mpi/intel64/bin/mpicxx -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Performing Test HAVE_C99
-- Performing Test HAVE_C99 - Success
-- Found C99: -std=c99
-- Checking to see if CXX compiler accepts flag -std=c++14
-- Checking to see if CXX compiler accepts flag -std=c++14 - yes
-- Performing Test HAVE_FINAL
-- Performing Test HAVE_FINAL - Success
-- Performing Test HAVE_TYPE_TRAITS
-- Performing Test HAVE_TYPE_TRAITS - Success
-- Performing Test HAVE_SHARED_PTR
-- Performing Test HAVE_SHARED_PTR - Success
-- Performing Test HAVE_UNIQUE_PTR
-- Performing Test HAVE_UNIQUE_PTR - Success
-- Performing Test HAVE_NULLPTR
-- Performing Test HAVE_NULLPTR - Success
-- Performing Test HAVE_CONSTEXPR
-- Performing Test HAVE_CONSTEXPR - Success
-- Performing Test HAVE_ARRAY
-- Performing Test HAVE_ARRAY - Success
-- Performing Test HAVE_INTEGRAL_CONSTANT
-- Performing Test HAVE_INTEGRAL_CONSTANT - Success
-- Looking for C++ include tuple
-- Looking for C++ include tuple - found
-- Looking for C++ include tr1/tuple
-- Looking for C++ include tr1/tuple - found
-- Performing Test HAVE_ATTRIBUTE_ALWAYS_INLINE
-- Performing Test HAVE_ATTRIBUTE_ALWAYS_INLINE - Success
-- Performing Test HAS_ATTRIBUTE_DEPRECATED
-- Performing Test HAS_ATTRIBUTE_DEPRECATED - Success
-- Performing Test HAS_ATTRIBUTE_DEPRECATED_MSG
-- Performing Test HAS_ATTRIBUTE_DEPRECATED_MSG - Success
-- Performing Test HAVE_STATIC_ASSERT
-- Performing Test HAVE_STATIC_ASSERT - Success
-- Performing Test HAVE_AUTO
-- Performing Test HAVE_AUTO - Success
-- Performing Test HAVE_VARIADIC_TEMPLATES
-- Performing Test HAVE_VARIADIC_TEMPLATES - Success
-- Performing Test HAVE_VARIADIC_CONSTRUCTOR_SFINAE
-- Performing Test HAVE_VARIADIC_CONSTRUCTOR_SFINAE - Success
-- Performing Test HAVE_RVALUE_REFERENCES
-- Performing Test HAVE_RVALUE_REFERENCES - Success
-- Looking for C++ include tr1/type_traits
-- Looking for C++ include tr1/type_traits - found
-- Boost version: 1.64.0
-- Found the following Boost libraries:
-- unit_test_framework
-- Found opm-common: /work/02552/sogoogos/rmine/OPM_20180221/opm-common/cmake-build-release/lib/libopmcommon.a
-- Could NOT find CJSON (missing: CJSON_INCLUDE_DIRS HAVE_CJSON)
-- Found opm-parser: /work/02552/sogoogos/rmine/OPM_20180221/opm-parser/cmake-build-release/lib/libopmparser.a
-- CMake version: 2.8.12.2
-- Linux distribution: CentOS Linux 7 (Core)
-- Target architecture: x86_64
-- Found Git: /opt/apps/git/2.9.0/bin/git (found version "2.9.0")
-- Source code repository: git 165d5cc%
-- Linker: ld 2.26.20160125
-- Precompiled headers: disabled
-- Build type: Release
-- OpenMP: disabled
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
-- Could NOT find CppCheck (missing: CPPCHECK_PROGRAM)
-- Disabling clang-check as CMAKE_EXPORT_COMPILE_COMMANDS is not enabled
-- Performing Test HAVE_DYNAMIC_BOOST_TEST
-- Performing Test HAVE_DYNAMIC_BOOST_TEST - Success
-- Writing config file "/work/02552/sogoogos/rmine/OPM_20180221/opm-output/cmake-build-release/config.h"...
-- This build defaults to installing in /work/02552/sogoogos/rmine/foo_20180221
-- Found Doxygen: /bin/doxygen (found version "1.8.5")
-- Writing version information to local header project-version.h
-- Configuring done
-- Generating done
-- Build files have been written to: /work/02552/sogoogos/rmine/OPM_20180221/opm-output/cmake-build-release


Building message (make $OPM_MAKE_OPTIONS)

Scanning dependencies of target update-version
Scanning dependencies of target datafiles
[ 2%] [ 5%] Updating version information
Generating tests/summary_deck_non_constant_porosity.DATA
[ 8%] Generating tests/FIRST_SIM.DATA
[ 8%] Built target update-version
[ 11%] Generating tests/summary_deck.DATA
Scanning dependencies of target opmoutput
[ 14%] Generating tests/group_group.DATA
[ 17%] Generating tests/testblackoilstate3.DATA
[ 20%] Generating tests/testrft.DATA
[ 22%] Generating tests/table_deck.DATA
[ 25%] Making "tests" data available in output tree
[ 25%] Built target datafiles
[ 31%] [ 31%] Building CXX object CMakeFiles/opmoutput.dir/opm/test_util/summaryIntegrationTest.cpp.o
Building CXX object CMakeFiles/opmoutput.dir/opm/test_util/summaryRegressionTest.cpp.o
[ 34%] Building CXX object CMakeFiles/opmoutput.dir/opm/test_util/summaryComparator.cpp.o
[ 37%] Building CXX object CMakeFiles/opmoutput.dir/opm/test_util/EclFilesComparator.cpp.o
[ 40%] Building CXX object CMakeFiles/opmoutput.dir/opm/output/eclipse/EclipseGridInspector.cpp.o
[ 42%] Building CXX object CMakeFiles/opmoutput.dir/opm/output/eclipse/EclipseIO.cpp.o
[ 45%] Building CXX object CMakeFiles/opmoutput.dir/opm/output/eclipse/LinearisedOutputTable.cpp.o
In file included from /work/02552/sogoogos/rmine/OPM_20180221/opm-output/opm/output/eclipse/EclipseIO.hpp(35),
from /work/02552/sogoogos/rmine/OPM_20180221/opm-output/opm/output/eclipse/EclipseIO.cpp(27):
/work/02552/sogoogos/rmine/OPM_20180221/opm-output/opm/output/data/Solution.hpp(38): error: cannot determine the exception specification of the default constructor due to a circular dependency
using Base::map;
^

[ 48%] Building CXX object CMakeFiles/opmoutput.dir/opm/output/eclipse/RestartIO.cpp.o
compilation aborted for /work/02552/sogoogos/rmine/OPM_20180221/opm-output/opm/output/eclipse/EclipseIO.cpp (code 2)
make[2]: *** [CMakeFiles/opmoutput.dir/opm/output/eclipse/EclipseIO.cpp.o] Error 2
make[2]: *** Waiting for unfinished jobs....
In file included from /work/02552/sogoogos/rmine/OPM_20180221/opm-output/opm/output/eclipse/RestartIO.hpp(34),
from /work/02552/sogoogos/rmine/OPM_20180221/opm-output/opm/output/eclipse/RestartIO.cpp(30):
/work/02552/sogoogos/rmine/OPM_20180221/opm-output/opm/output/data/Solution.hpp(38): error: cannot determine the exception specification of the default constructor due to a circular dependency
using Base::map;
^

compilation aborted for /work/02552/sogoogos/rmine/OPM_20180221/opm-output/opm/output/eclipse/RestartIO.cpp (code 2)
make[2]: *** [CMakeFiles/opmoutput.dir/opm/output/eclipse/RestartIO.cpp.o] Error 2
make[1]: *** [CMakeFiles/opmoutput.dir/all] Error 2
make: *** [all] Error 2

EclipseWriter: Incomplete translation to EclipseGrid::compressedVector<>()

Commit 377ca48 (PR #87) switched the implementation of EclipseWriter::writeTimeStep() to using method EclipseGrid::compressedVector<>(). In doing so, the functionality of writeTimeStep() effectively regressed.

The previous version, which was based on helper function restrictAndReorderToActiveCells<>() would transparently handle the case of an input vector being defined on the active cells only. The new version (based on EclipseGrid::compressedVector<>()) fails (throws an exception) unless the input vector is defined on the global cells. At the moment I don't know where to handle the semantic mismatch, I only know that this is causing a Jenkins CI failure on the Norne case.

No summary vector names for 2D-polymer case after using Flow.

After running the commands

flow ~/opm-data/polymer_test_suite/simple2D/2D_THREEPHASE_POLY_HETER.DATA
summary.x ~/opm-data/polymer_test_suite/simple2D/2D_THREEPHASE_POLY_HETER

there is only one vector output, TIME.

When running the same DATA-file in eclipse these summary vectors are created:

FGIP                     FGIPG                    FGIPL                    FGIR                     FGIT
FGOR                     FGPR                     FGPT                     FOIP                     FOIPG
FOIPL                    FOIR                     FOIT                     FOPR                     FOPT
FPR                      FVIR                     FVIT                     FVPR                     FVPT
FWCT                     FWGR                     FWIP                     FWIR                     FWIT
FWPR                     FWPT                     GGIR:I                   GGIR:P                   GGIT:I
GGIT:P                   GGOR:I                   GGOR:P                   GGPR:I                   GGPR:P
GGPT:I                   GGPT:P                   GOIR:I                   GOIR:P                   GOIT:I
GOIT:P                   GOPR:I                   GOPR:P                   GOPT:I                   GOPT:P
GVIR:I                   GVIR:P                   GVIT:I                   GVIT:P                   GVPR:I
GVPR:P                   GVPT:I                   GVPT:P                   GWCT:I                   GWCT:P
GWGR:I                   GWGR:P                   GWIR:I                   GWIR:P                   GWIT:I
GWIT:P                   GWPR:I                   GWPR:P                   GWPT:I                   GWPT:P
TIME                     WBHP:INJE01              WBHP:PROD01              WGIR:INJE01              WGIR:PROD01
WGIT:INJE01              WGIT:PROD01              WGOR:INJE01              WGOR:PROD01              WGPR:INJE01
WGPR:PROD01              WGPT:INJE01              WGPT:PROD01              WOIR:INJE01              WOIR:PROD01
WOIT:INJE01              WOIT:PROD01              WOPR:INJE01              WOPR:PROD01              WOPT:INJE01
WOPT:PROD01              WPI:INJE01               WPI:PROD01               WTHP:INJE01              WTHP:PROD01
WVIR:INJE01              WVIR:PROD01              WVIT:INJE01              WVIT:PROD01              WVPR:INJE01
WVPR:PROD01              WVPT:INJE01              WVPT:PROD01              WWCT:INJE01              WWCT:PROD01
WWGR:INJE01              WWGR:PROD01              WWIR:INJE01              WWIR:PROD01              WWIT:INJE01
WWIT:PROD01              WWPR:INJE01              WWPR:PROD01              WWPT:INJE01              WWPT:PROD01
YEARS

flow_ebos default output directory

I observe that when using the current build of OPM and with default settings the flow_ebos output files(.PRT, .UNRST etc) are written out within the current/working directory instead of directory containing the .DATA file

where to MPI?

maybe this is already implemented, if yes please let me know: It seems like opm-output assumes a global (i.e., non-distributed) view on the grid, i.e., the calling code needs to deal with collecting all data to the rank which writes the output etc. since this is IMO quite clumsy for downstream code, the question arises if there are plans for opm-output to become MPI aware in the near future?

Does opm-output need both ert and libecl?

Somehow I was under the impression that opm should work without ert as libecl provides all that is needed? Is that assumption wrong?

With the version of May 26 I cannot buid opm-output if I only specify ECL_DIR and not ERT_ROOT:

No units from summary file when running flow

When running flow there are no units included in the summary files. I have tested on the cases SPE9_CP, SPE1CASE1, SPE3CASE1 and SPE3CASE2

When printing the units for each well with my compareSummary binary this is some of the output when using the opm-simulation-reference for SPE1CASE1.

~/opm-output/build/bin/compareSummary ~/opm-data/spe1/opm-simulation-reference/SPE1CASE1

WBHP:INJ unit: PSIA
WBHP:PROD unit: PSIA
WGIR:INJ unit: MSCF/DAY
WGIR:PROD unit: MSCF/DAY
...etc.

When using the new summary files:
~/opm-output/build/bin/compareSummary ~/spe1/SPE1CASE1

WBHP:INJ unit:
WBHP:PROD unit:
WGIR:INJ unit:
WGIR:PROD unit:
... etc.

The tendency for the four files I tested is that the units are included in the opm-simulation-reference and not in the new summary files created by flow. Is this intentional?

Test failure in release mode

For me, the test_EclipseWriter test fails:

Running 1 test case...
unknown location:0: fatal error in "EclipseWriterIntegration": signal: SIGSEGV, si_code: 0 (memory access violation at address: 0x00000000)

Unfortunately it succeeds in debug mode, so I have not been able to pinpoint the source of the error.

Open/shut well status for wells

OPM/opm-simulators#749 (comment)

As I see it the Right™ way to do this is that the simulator initialized/assigns the data:Wells structures correctly with open/shut status of wells and connections, and then that stumbles out to disk.

Great idea and put into TODO as a missing feature.

Cmake 3.0.2 complains about policy CMP0011

Not sure whether you are aware of this:

-- Writing version information to local header project-version.h
CMake Warning (dev) at CMakeLists.txt:93 (include):
  Policy CMP0011 is not set: Included scripts do automatic cmake_policy PUSH
  and POP.  Run "cmake --help-policy CMP0011" for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.

  The included script

    /home/mblatt/DUNE-2.5/opm-common/cmake/Modules/OpmLibMain.cmake

  affects policy settings.  CMake is implying the NO_POLICY_SCOPE option for
  compatibility, so the effects are applied to the including context.
This warning is for project developers.  Use -Wno-dev to suppress it.

This did not appear for opm-parser. That is why I posted it here.

Support for FPRP

Support for the summary keyword FPR (hydrocarbon pore weighed average) is implemented, but the simpler FPRP (pore volume weighted average) is missing.

fpr() in Summary.cpp implements sum(HCPV*p)/sum(HCPV) while FPRP would need only sum(PV*p)/sum(PV).

New function fprp() or should it be templatized?

Completion order for output

Currently data for completions are stored in the Well struct of opm/output/data/Wells.hpp as

std::map< Completion::active_index, Completion > completions;

This is problematic because order of completions is lost upon output (replaced with sorted-by-active-index). When restoring the original state the ordering should be the same as when writing.
The simplest solution is replacing the map with a vector. An alternative could be building a mapping from active cell index to local completion position on the simulator side, but I think that is a more complicated and therefore worse solution.

The output of relative permeability is problematic

For example, adding the following line to SPE1CASE2,

 RPTRST
  BASIC=2 KRO KRW KRG SWAT PRES SGAS SOIL /

The output of KRs is always problematic like the following

 4248  'GASKR   '         300 'REAL'
 4249    0.56199553E+15   0.32365058E+15   0.25250143E+15   0.15856476E+15
 4250    0.58609271E+14   0.00000000E+00   0.00000000E+00   0.00000000E+00
 4251    0.00000000E+00   0.00000000E+00   0.32365058E+15   0.26636632E+15
 4252    0.18484831E+15   0.95997619E+14   0.94232117E+13   0.00000000E+00
 4253    0.00000000E+00   0.00000000E+00   0.00000000E+00   0.00000000E+00
 4254    0.25250141E+15   0.18484831E+15   0.10912140E+15   0.23508053E+14
 4255    0.00000000E+00   0.00000000E+00   0.00000000E+00   0.00000000E+00
 4256    0.00000000E+00   0.00000000E+00   0.15856476E+15   0.95997603E+14

Compile failure

The following line (and many similar ones) fails (Summary.cpp line 252):

case WT::wat: return units.from_si( units.measure::liquid_surface_rate, p.WaterRate );

The error message is

/Users/atgeirr/opm-build-debug/opm-output/opm/output/eclipse/Summary.cpp:252:60: error: 'Opm::UnitSystem::measure::liquid_surface_rate' is not a member of class 'const Opm::UnitSystem'
        case WT::wat: return units.from_si( units.measure::liquid_surface_rate, p.WaterRate );
                                                  ~~~~~~~~~^

I have not tried to solve the problem yet. This also breaks on Travis, yet still slipped through the safety net. I do not know if that's worth investigating though (perhaps a compiler issue?.

Summary output not respecting output_dir

It seems that the output directory parameter is no longer used by the summary output facilities, and that summary files are always written to the current directory. Restart files are written to the correct dir however.

opm-output does not compile with current ert master

Have we switched to using ert releases, maybe?

When I try compile opm-output with the ert master I get:

[  3%] Building CXX object CMakeFiles/opmoutput.dir/opm/output/eclipse/EclipseWriter.cpp.o
/home/mblatt/src/dune/opm/opm-output/opm/output/eclipse/EclipseWriter.cpp: In function ‘ert_ecl_unit_enum Opm::{anonymous}::to_ert_unit(Opm::UnitSystem::UnitType)’:
/home/mblatt/src/dune/opm/opm-output/opm/output/eclipse/EclipseWriter.cpp:335:43: error: ‘ERT_ECL_METRIC_UNITS’ was not declared in this scope
         case ut::UNIT_TYPE_METRIC: return ERT_ECL_METRIC_UNITS;
                                           ^
/home/mblatt/src/dune/opm/opm-output/opm/output/eclipse/EclipseWriter.cpp:336:43: error: ‘ERT_ECL_FIELD_UNITS’ was not declared in this scope
         case ut::UNIT_TYPE_FIELD:  return ERT_ECL_FIELD_UNITS;
                                           ^
/home/mblatt/src/dune/opm/opm-output/opm/output/eclipse/EclipseWriter.cpp:337:43: error: ‘ERT_ECL_LAB_UNITS’ was not declared in this scope
         case ut::UNIT_TYPE_LAB:    return ERT_ECL_LAB_UNITS;
                                           ^
/home/mblatt/src/dune/opm/opm-output/opm/output/eclipse/EclipseWriter.cpp: In member function ‘void Opm::EclipseWriter::Impl::writeINITFile(const Opm::data::Solution&, const Opm::NNC&) const’:
/home/mblatt/src/dune/opm/opm-output/opm/output/eclipse/EclipseWriter.cpp:468:58: error: invalid conversion from ‘int’ to ‘ert_ecl_unit_enum’ [-fpermissive]
                                      this->sim_start_time);
                                                          ^
/home/mblatt/src/dune/opm/opm-output/opm/output/eclipse/EclipseWriter.cpp:468:58: error: too few arguments to function ‘void ecl_init_file_fwrite_header(fortio_type*, const ecl_grid_type*, const ecl_kw_type*, ert_ecl_unit_enum, int, time_t)’
In file included from /home/mblatt/src/dune/opm/opm-output/opm/output/eclipse/EclipseWriter.cpp:52:0:
/home/mblatt/src/dune/3rdParty/ert/include/ert/ecl/ecl_init_file.h:33:8: note: declared here
   void ecl_init_file_fwrite_header( fortio_type * fortio , const ecl_grid_type * grid , const ecl_kw_type * poro , ert_ecl_unit_enum unit_system, int phases , time_t start_date);
        ^

My ert version is

commit 6faca112a623b4c370a1f47925d0e136c803b7ce
Merge: 9143ca7 bee8772
Author: Joakim Hove <[email protected]>

    Merge pull request #1396 from joakim-hove/ecl-filename

opm-output version:

commit eff8f900530a3218205b1c9bcb7eddb1b5024d64
Merge: da30b8a cb9b4b7
Author: Joakim Hove <[email protected]>

    Merge pull request #151 from atgeirr/silence-warnings

Undefined symbol: ecl_sum_alloc_restart_writer: What is the error?

What does this error message mean?

**********************************************************************
*                                                                    *
*                       This is flow 2017.10.1                       *
*                                                                    *
* Flow is a simulator for fully implicit three-phase black-oil flow, *
*             including solvent and polymer capabilities.            *
*          For more information, see http://opm-project.org          *
*                                                                    *
**********************************************************************
===============Saturation Functions Diagnostics===============

System:  Black-oil system.
Relative permeability input format: Saturation Family I.
Number of saturation regions: 1

flow: symbol lookup error: /usr/lib64/libopmoutput.so.2017: undefined symbol: ecl_sum_alloc_restart_writer

The error message is unclear on how to fix this.

Eight corner points of each cell in the grid

Good morning everyone.

Is there an OPM output file that gives me the x, y, and z coordinates for the eight points (corners) of each cell in the grid?
The .FEGRID file only gives me COORD and ZCORN. Only with ZCORN I can't get the x and y points of the cells in the intermediate layers directly.

Thanks.

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.