opm / opm-output Goto Github PK
View Code? Open in Web Editor NEWThis 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
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
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.
(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.
In the light of /OPM/opm-simulators#768 /OPM/opm-simulators#769 I would love to see some checks for the input parameters to detect usage problems. The following come to mind:
I assume NTG should be written to the INIT file, but the documentation is missing.
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.
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
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.
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
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.
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
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.
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.
FPR is off by a factor approx 1 bar. The case uses METRIC units.
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?
-- 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
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
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?.
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.
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.
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.
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.
Repo link not found
http://www.opm-project.org/packages/current/redhat/6/opm.repo
404 error
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?
I just did a run with a model and output_dir set. Judging from the file modification time, .PRT got written to the current directory and not the ouput_dir. Is that a feature?
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:
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.
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.
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
.
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...
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?
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?
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.
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
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.
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.
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.
Currently it is not obvious to non Eclipse format experts what that is and how it is used during output.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.