opm/opm-parser

opm-parser

THIS MODULE IS DEPRECATED. The code is now integrated in the opm-common module.

opm-parser is a small library for parsing ECLIPSE datafiles.

Dependencies

• boost version 1.45 or newer.
• libecl 2.2 or newer.

Build instructions

We assume boost is installed in BOOST_INCLUDE=/opt/software and that you wish to install opm-parser in INSTALL_PATH=/opt/software.

Obtaining the data:

git clone https://github.com/Statoil/libecl
git clone https://github.com/OPM/opm-parser

Configure the paths:

export INSTALL_PATH=/opt/software
export BOOST_INCLUDE=/opt/software/include
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$INSTALL_PATH/lib:$INSTALL_PATH/lib64

Build and install libecl:

cd libecl
mkdir build
cd build/
cmake -DENABLE_PYTHON=OFF -DBUILD_TESTS=OFF -DCMAKE_INSTALL_PREFIX=$INSTALL_PATH ..
make install
cd ../..

Build and install opm-parser (you may omit the flag to Boost_INCLUDE_DIR if it is installed at a standardized location):

cd opm-parser/
mkdir build
cd build/
cmake -DBoost_INCLUDE_DIR=$BOOST_INCLUDE -DCMAKE_INSTALL_PREFIX=$INSTALL_PATH ..
make install

opm-parser's Issues

Test failure on case-insensitive file systems

I get the following error in runParserIncludeTest:

fatal error in "ParserKeyword_includeValid": std::runtime_error: Input file
'testdata/parser/includeValid.data' does not exist or is not readable

The parser does not support defaulting the connection factor of a well completion

By explicit design, the COMPDAT handling code (.../Schedule/Completion.cpp) does not support defaulting the connection factor of a completion. Specifically, the following block in lines 63--67 of the .cpp file (method Completion::completionsFromCOMPDATRecord()) prevents defaults

{
    DeckItemConstPtr CFItem = compdatRecord->getItem("CF");
    if (CFItem->defaultApplied())
        throw std::invalid_argument("The connection factor item can not be defaulted");
}

Is there a technical reason for this restriction?

Despite its many shortcomings there is a fall-back method to compute connection factors in module opm-core's WellManager class. Would it be possible to lift the restriction, or possibly make it conditional on some criterion?

Build failure

Current master gives me this error:

/Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp:120:23: error: use of undeclared identifier 'ecl_grid_alloc_dx_dy_dz_tops'

I suspect the root cause is un-updated ert libraries.

Update: issue has been reopened, but the problem is different (see comments below the reopening).

MULTREGT requires MULTNUM keyword in the deck.

When run with the currently available NORNE deck I get the following exception:

Program threw an exception: MULTREGT record is based on region: MULTNUM which is not in the deck
terminate called after throwing an instance of 'std::logic_error'
what(): MULTREGT record is based on region: MULTNUM which is not in the deck
Aborted

This could either be an issue with my deck or and issue with the parser. I'm not sure which one it is, I just wanted to report this problem.

BUILD_TESTING is ignored in opm-parser.

No matter which value is set to BUILD_TESTING={ON,OFF} the tests are being built. Maybe this is an easy fix. In any case, this is a non-critical issue.

Norne does not run

I get the following error when I run Norne (in opm-data/norne) with the updated parser.

Program threw an exception: Index must be smaller than 0 but is 0
terminate called after throwing an instance of 'std::out_of_range'
what(): Index must be smaller than 0 but is 0
Aborted

I reset the wellCompletion commits but the error is still there. So I guess it is related to default values.

ENPTVD table in eclipse state - some issues:

a) Fully defaulted columns does not work (causes a throw in SingleRecordTable::applyDefaultsLinear) This essentially makes the functionality useless as defaulting one or more columns to signal default behavior is common procedure.

b) The look-up in the tables are triggered by the explicit appearance of the associated scaling keyword in the deck (e.g will not look for SWL in table unless SWL also appears as kw in the deck). Again this renders the functionality essentially useless as standalone table is the rule rather than exception.

c) Also a few trivialities:

• EnptvdTable::init: ParentType::applyDefaultsLinear not called for tag SWMAX
• GridPropertyEndpointTableLookupInitializer: For SWU/ISWU selectValue is called with "SWCO" as tag instead of "SWMAX"

Can't run NORNE anymore.

When I run the NORNE case I get the following exception:

Program threw an exception: IOConfig: Reading GRIDFILE keyword from GRID section: Output of GRID file is not supported

This seems to happened in some file called IOConfig.cpp in opm-parser. All modules are at the latest state. Either the deck in opm-data needs an update or this might be a bug.

(Potential) use of uninitialized variables

Hi,

as this module seem to be heading for 2014.03 inclusion, and I will be tasked with releasing the packages, I've been doing some preliminary stuff on opm-parser.

One particular thing I always do prior to releasing anything is to run available tests through valgrind. I also did that for opm-parser. Found some naughties.

While I could send diffs, I am not in a position to choose initialization values for these variables.

Thus, the easiest way to convey this to you is to allow you to run things yourself; please see https://github.com/akva2/opm-parser/tree/run_tests_through_valgrind

grab and compile this and configure with -DTEST_MEMCHECK_TOOL=valgrind, build, then run ctest -V to see the valgrind output.

Where is OIL_COMPRESSIBILITY?

Attempting to parse a data file (essentially https://raw.githubusercontent.com/OPM/opm-verteq/master/examples/3d/data/tube.data but with an empty TABDIMS added) which was previously accepted by the old EclipseGridParser in opm-core, I now get the exception:

Itemname: OIL_COMPRESSIBILITY does not exist.

but it doesn't say where it is missing this, let alone why it wants this (for an incompressible case). Grepping through the source files, there is only one match on _COMPRESSIBILITY and that is for the PVTW keyword, which defines one for water.

I reckon that there could be one in PVCDO, but there is it apparently called C_OIL_REF?

Unit conversion error for GAS RESV limits

In Schedule::handleWCONINJE(), the rates are converted with the same routine and arguments for both the RATE (surface volume rate) target and RESV. For GAS injectors, this is wrong: RATE should be in MScf/day (with M meaning Mille, 1000, not Mega...) while RESV is in barrels/day. Both are however converted as if in MScf/day.

This may point to related bugs when using FIELD units, I have not checked that (Rs factors could be wrong as well, but I don't think they are or we would have failed long ago).

With SPE1, this leads to very touchy controls that are susceptible to random changing, as observed in OPM/opm-simulators#300.

EclipseGrid::assertCornerPointKeywords() has bogus error reporting.

Building error: DeckItem

I get a building error:

Program threw an exception: This implementation of DeckItem does not support double terminate called after throwing an instance of 'std::logic_error'
what(): This implementation of DeckItem does not support double

If I reset to: SHA: 9e4bdf6
it works again.

The value has: ConnectionTransmissibilityFactor has not been initialized

I met this issue when I tried run a test data which COMPDAT has default connection transmissibility,
does that mean that connection transmissibility is required?

Problem with Control mode.

Program threw an exception: [/home/robertk/work/OPM/release/opm-core/opm/core/wells/WellsManager.cpp:620] Control mode type 0 not present in well B-4H
terminate called after throwing an instance of 'std::runtime_error'
  what():  [/home/robertk/work/OPM/release/opm-core/opm/core/wells/WellsManager.cpp:620] Control mode type 0 not present in well B-4H

I'm not exactly sure what the problem is, so I would like other to comment on that.

packaging issue

hi,

you are probably very little worried about packaging just yet and that is fine. just listing things that will be an issue when we get there;

1. no install targets
2. the internaldata tests needs to be disabled by default. the packaging requires all tests to pass.
3. bundling of upstream sources (cjson) should be avoided. at least you should support external supply of this to facilitate distro-acceptable packaging.

BHP limit for historical mode

From the manual: "For control modes other than BHP the BHP lower limit is automatically set to
atmospheric pressure when the well is first declared a history matching well (the first
time it appears in a WCONHIST keyword)."

I don't think this is implemented. I.e. we allow for negative BHP.

Feature request: make wells appear in WELSPECS order, not alphabetical

For simpler comparison of results to MRST, it would be nice if the Schedule class would expose the wells in the order given in the deck. I think this would also be the order used by eclipse, but I am not certain.

opm-polymer simulator threw an exception due to keyword "PLYVISC"

The original issue was posted in opm-polymer OPM/opm-polymer#68
Maybe the other keywords relate to polymer also have such problem, since PLYVISC was the first keyword in POLY.inc.

Test failures

I get the following test failures in opm-parser:

With debug mode:
The following tests FAILED:
70 - runPORVTests (Failed)
Errors while running CTest

With release mode:
The following tests FAILED:
26 - runParseTOPS (Failed)
66 - runGridPropertyTests (Failed)
70 - runPORVTests (Failed)
Errors while running CTest

The only failure I have investigates is the PORV test, and while I have not found the error, it seems strange to me that a call:

            auto porv = state.getDoubleGridProperty("PORV");

(at line 258 of PORVtest.cpp) eventually results in a different call to getDoubleGridProperty() again, inside the application of a post processing. I do not know if this is related to the error or not, just wanted to remark on it in case it can help.

Improved unit conversion

Currently, the unit conversion factors in ConversionFactors.hpp are not quite consistent with those in opm/core/utility/Units.hpp (or with MRST for that matter). A source of small, unnecessary differences is for example that the conversion from psia to Pascal is given as a constant with 6 digits in opm-parser, whereas it is computed at full precision in opm-core. This gives me a small but annoying pressure difference (~13 Pascal) when comparing initial simulator states of MRST vs. those given by opm-parser.

I suggest that the facility in opm-core is more or less copied into opm-parser, at least those parts that are relevant to the conversions needed, then one can say that Field::Pressure = psia, instead of using a magic constant.

This is not critical, but would be nice for consistency. Please tell me if you agree that this should be done, I may find the time to do it if you agree.

Missing support for KRW family of keywords

For some reason these keywords are not supported any more ...

Unused function in ParserTests.cpp?

The function setupParserKeywordInt() seems to be unused, and could be removed, or perhaps incorporated into a test if it is considered useful.

Compile error, perhaps due to boost filesystem changes

I get compile errors building Parser.cpp, that may have something to do with boost filesystem interfaces changing from version 2 to 3. I believe you need to use the string() method for conversion path->string now if I am not mistaken.

I have not made a PR because I have not yet forked the repo (will do...) and because I am not sure if the fix (inserting a .string() on line 214) works with your version of boost. I have run into some such issues before, but always managed to find a way to write the code to work with both versions (so far).

(Also, there is a function getKeyword() that sometimes fail to return anything.)

Here is the error message (sorry for formatting):

[ 21%] Building CXX object opm/parser/eclipse/CMakeFiles/Parser.dir/Parser/Parser.cpp.o
/Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/Parser/Parser.cpp: In member function ‘void Opm::Parser::loadKeywordsFromDirectory(const boost::filesystem3::path&, bool, bool)’:
/Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/Parser/Parser.cpp:214:74: error: no matching function for call to ‘Opm::ParserKeyword::validName(boost::filesystem3::path)’
/Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/Parser/Parser.cpp:214:74: note: candidate is:
In file included from /Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/Parser/Parser.hpp:32:0,
from /Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/Parser/Parser.cpp:21:
/Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/Parser/ParserKeyword.hpp:42:21: note: static bool Opm::ParserKeyword::validName(const string&)
/Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/Parser/ParserKeyword.hpp:42:21: note: no known conversion for argument 1 from ‘boost::filesystem3::path’ to ‘const string& {aka const std::basic_string&}’
/Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/Parser/Parser.cpp: In member function ‘Opm::ParserKeywordConstPtr Opm::Parser::getKeyword(const string&) const’:
/Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/Parser/Parser.cpp:66:4: warning: control reaches end of non-void function [-Wreturn-type]

Serious compiler warning

/Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/EclipseState/Schedule/Well.hpp:62:65: warning: declaration shadows a field of 'Opm::WellProductionProperties' [-Wshadow]
/Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/EclipseState/Schedule/Well.hpp:69:66: warning: declaration shadows a field of 'Opm::WellProductionProperties' [-Wshadow]
/Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/EclipseState/Schedule/Well.hpp:75:65: warning: declaration shadows a field of 'Opm::WellProductionProperties' [-Wshadow]
/Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/EclipseState/Schedule/Well.hpp:104:64: warning: declaration shadows a field of 'Opm::WellInjectionProperties' [-Wshadow]
/Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/EclipseState/Schedule/Well.hpp:111:65: warning: declaration shadows a field of 'Opm::WellInjectionProperties' [-Wshadow]
/Users/atgeirr/opm-build-debug/opm-parser/opm/parser/eclipse/EclipseState/Schedule/Well.hpp:117:64: warning: declaration shadows a field of 'Opm::WellInjectionProperties' [-Wshadow]

Tenkte først at dette skal eg fikse kjapt, men etter å ha kikka på koden er eg meir usikker, og trur denne åtvaringa peiker på eit reelt problem.
Det er nemleg både funksjonsargument og eit datamedlem som heiter 'controlMode' i desse metodane. Datamedlemmet brukast ikkje i Wells.[ch]pp, men i Schedule.cpp(!). Det er i alle fall forvirrande for meg å skjønne korleis datamedlemmet er tenkt brukt, og kva som er semantikken til det versus funksjonsargumentet. Samspelet med injectionControls/productionControls-medlemmet er og ganske uklårt (det er dette som manipulerast av funksjonane over). Forresten: Kvifor ikkje unsigned int for injectionControls/productionControls?

WCONINJE - GRUP

Placing a well under group control currently causes a throw:
(opm/parser/eclipse/EclipseState/Schedule/Schedule.cpp, line 340)

WCONINJE
'F-3H' 'WATER' 'STOP' 'GRUP ' 13000.000 1* 450.000 1* 19 1* /
/

For Norne: a single occurrence, might well be neglected?
Consider what functionality actually supported by opm-core...

keyword WPOLYMER

First, I must admire that I am not quite sure it is right or not to open the issue about this keyword in opm-parser, but this issue bother me a lot.

The data fromat looks like as follow:

WPOLYMER
"INJEC" 1.0 0.0 /

for a polymer flooding, usually we use water flooding first, after some time, we employ polymer flooding for a period and finally stop polymer flooding. The schedule part looks like

WPOLYMER
"INJE" 0.0 0.0 /

TSETP
10*1
2
3
/

WPOLYMER
"INJE" 1.0 0.0 /
TSTEP
3
4/

WPOLYMER
"INJE" 0.0 0.0 /

The problem is that how could I get proper polymer injection rate at right time point. The original (before opm-parser)opm-polymer/opm/polymer/PolymerInflow.cpp can get the correct value, but now I found that whenever you start injecting polymer, the parser find deck has keyword WPOLYMER, then it will inejct polymer at the very beginning, no matter what time point you inject polymer! anther strange issue is even you set schedule part as above, the parser always use vaule in the first WPOLYMER.

I also wonder whether it is my fault to get polymer inflow in an inpropriate way, I just following the opm-polymer/examples/sim_poly2p_com_reorder.cpp to set polymer inflow. So I hope someone that farmiliar with this part can help me, since I am new to opm-parser.... If opm-parser get set a test case to get the right value that will be great! Thanks!

config.h does not get generated

the "config.h" file is not generated using the current build system. I suspect that is the reason why I get the following error when trying to compile the unit tests under some circumstances:

Linking CXX executable ../../../runjsonTests
cd /home/and/src/opm-parser/opm/json/tests && /usr/bin/cmake -E cmake_link_script CMakeFiles/runjsonTests.dir/link.txt --verbose=1
/usr/bin/clang++   -pipe -Wall -Wno-unknown-pragmas -std=c++0x -g   -O0 -DDEBUG  -ggdb3    CMakeFiles/runjsonTests.dir/jsonTests.cpp.o  -o ../../../runjsonTests -rdynamic ../libopm-json.a -lboost_filesystem-mt -lboost_date_time-mt -lboost_system-mt -lboost_unit_test_framework-mt ../libcjson.so -lboost_filesystem-mt -lboost_date_time-mt -lboost_system-mt -lboost_unit_test_framework-mt -Wl,-rpath,/home/and/src/opm-parser/opm/json 
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/crt1.o: In function `_start':
/home/abuild/rpmbuild/BUILD/glibc-2.18/csu/../sysdeps/x86_64/start.S:118: undefined reference to `main'
clang-3.3: error: linker command failed with exit code 1 (use -v to see invocation)

(at least, a forgotten #include "config.h" was the cause for this error last time in a different module.)

Packagin issues

issues discovered:

1. no doxy installed/generated
2. no pkgconfig file installed *
3. no cmake config mode files installed *
4. all libraries are unversioned *
5. libopm-json.so does not link to its dependencies (in particular libm) *
6. no debug symbols generated **
7. the only reason libParser.so does not conflict with something else is that nobody else has been fresh enough to grab such a general name. *
8. no end user applications (probably not an issue but i mention it).

* show stopper issue in my opinion ** - not a showstopper - i just use the tools instead of manual objcopy as the other modules do.

opm-parser building problem

Waiting for help!
I was trying to build opm-core on my computer, which the OS is ubuntu 14.04. I have installed every prerequisites recommended on the download-page of OPM.
In the process of "cmake", I am told that "Couldn't find TinyXML and ERT". After I installed both the packages of TinyXML and ERT, new problems appear, which says "Couldn't find CJSON and opm-parser". When I am trying to build opm-parser, I am stopped at the "make" process. While the "cmake" process is OK, error appear at the "make" process, which says as below:
[ 45%] Building CXX object opm/parser/eclipse/CMakeFiles/Parser.dir/EclipseState/Grid/FaceDir.cpp.o
[ 46%] Building CXX object opm/parser/eclipse/CMakeFiles/Parser.dir/EclipseState/Grid/TransMult.cpp.o
[ 47%] Building CXX object opm/parser/eclipse/CMakeFiles/Parser.dir/EclipseState/Grid/MULTREGTScanner.cpp.o
[ 47%] Building CXX object opm/parser/eclipse/CMakeFiles/Parser.dir/EclipseState/Grid/EclipseGrid.cpp.o
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp: In constructor ‘Opm::EclipseGrid::EclipseGrid(const ecl_grid_type_)’:
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp:56:52: error: ‘ecl_grid_alloc_copy’ was not declared in this scope
m_grid.reset( ecl_grid_alloc_copy( src_ptr ) , ecl_grid_free );
^
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp: In member function ‘void Opm::EclipseGrid::initDVDEPTHZGrid(const std::vector&, Opm::DeckConstPtr)’:
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp:229:148: error: ‘ecl_grid_alloc_dxv_dyv_dzv_depthz’ was not declared in this scope
m_grid.reset( ecl_grid_alloc_dxv_dyv_dzv_depthz( dims[0] , dims[1] , dims[2] , DXV.data() , DYV.data() , DZV.data() , DEPTHZ.data() , NULL ) , ecl_grid_free);
^
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp: In member function ‘void Opm::EclipseGrid::initDTOPSGrid(const std::vector&, Opm::DeckConstPtr)’:
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp:239:138: error: ‘ecl_grid_alloc_dx_dy_dz_tops’ was not declared in this scope
m_grid.reset( ecl_grid_alloc_dx_dy_dz_tops( dims[0] , dims[1] , dims[2] , DX.data() , DY.data() , DZ.data() , TOPS.data() , NULL ) , ecl_grid_free);
^
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp: In member function ‘bool Opm::EclipseGrid::equal(const Opm::EclipseGrid&) const’:
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp:485:82: error: too many arguments to function ‘bool ecl_grid_compare(const ecl_grid_type_, const ecl_grid_type_, bool, bool)’
ecl_grid_compare( c_ptr() , other.c_ptr() , true , false , false ));
^
In file included from /home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.hpp:30:0,
from /home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp:28:
/usr/include/ert/ecl/ecl_grid.h:115:19: note: declared here
bool ecl_grid_compare(const ecl_grid_type * g1 , const ecl_grid_type * g2 , bool include_lgr, bool verbose);
^
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp: In member function ‘void Opm::EclipseGrid::exportACTNUM(std::vector&) const’:
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp:532:64: error: ‘ecl_grid_init_actnum_data’ was not declared in this scope
ecl_grid_init_actnum_data( c_ptr() , actnum.data() );
^
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp: In member function ‘void Opm::EclipseGrid::exportMAPAXES(std::vector&) const’:
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp:537:42: error: ‘ecl_grid_use_mapaxes’ was not declared in this scope
if (ecl_grid_use_mapaxes( c_ptr())) {
^
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp:539:73: error: ‘ecl_grid_init_mapaxes_data_double’ was not declared in this scope
ecl_grid_init_mapaxes_data_double( c_ptr() , mapaxes.data() );
^
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp: In member function ‘void Opm::EclipseGrid::exportCOORD(std::vector&) const’:
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp:546:56: error: ‘ecl_grid_get_coord_size’ was not declared in this scope
coord.resize( ecl_grid_get_coord_size( c_ptr() ));
^
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp:547:65: error: ‘ecl_grid_init_coord_data_double’ was not declared in this scope
ecl_grid_init_coord_data_double( c_ptr() , coord.data() );
^
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp: In member function ‘void Opm::EclipseGrid::exportZCORN(std::vector&) const’:
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp:551:56: error: ‘ecl_grid_get_zcorn_size’ was not declared in this scope
zcorn.resize( ecl_grid_get_zcorn_size( c_ptr() ));
^
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp:552:65: error: ‘ecl_grid_init_zcorn_data_double’ was not declared in this scope
ecl_grid_init_zcorn_data_double( c_ptr() , zcorn.data() );
^
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp: In member function ‘void Opm::EclipseGrid::resetACTNUM(const int_)’:
/home/abcxin/workspace/opm-parser/opm/parser/eclipse/EclipseState/Grid/EclipseGrid.cpp:559:54: error: ‘ecl_grid_reset_actnum’ was not declared in this scope
ecl_grid_reset_actnum( m_grid.get() , actnum );
^
make[2]: *** [opm/parser/eclipse/CMakeFiles/Parser.dir/EclipseState/Grid/EclipseGrid.cpp.o] 错误 1
make[1]: *** [opm/parser/eclipse/CMakeFiles/Parser.dir/all] 错误 2
make: *** [all] 错误 2

EclipseGrid::createDVector() potential problems

1. The following test

if (D.size() >= area && DKey == "DZ") {
    /*
      Special casing of the DZ keyword where you can choose to
      only specify the top layer.
    */
    ...
}

looks like it should be using D.size() == area. Furthermore, the special case for the DZ keyword is not necessary, as DX and DY also may have the same behaviour.
2. The line (in the same section).

for (size_t targetIndex = D.size(); targetIndex < volume; targetIndex++) {

should probably initialise targetIndex to area instead of D.size() (which makes the loop a no-op).
3. Both zeros below should probably be replaced with dim.

if (DV.size() != (size_t) dims[0])
    throw std::invalid_argument(DVKey + " size mismatch");
D.resize( volume );
scatterDim( dims , 0 , DV , D );

Of course, if my last point is correct, the dim argument must be reinstated (I removed it in a previous PR). The warning that was generated caused this investigation.

should PLYADS strictly check monotonic?

Since I have a following PLYADS table which get from lab,

PLYADS
0.00    0.0 
0.25    0.000010
0.50    0.000018
0.75    0.000023
1.00    0.000027
1.25    0.000030
1.50    0.000030
1.75    0.000030
2.00    0.000030
3.00    0.000030 /

In the last of that table, the AdsorbedPolymer stay the same, this maybe due to the mechanism of this polymer, and eclipse can accept this table, but OPM throw an exception, so I wonder whether OPM can change a little bit to accept such table? just change the operator from < to <=?

COORDSYS keyword

@AlexAV94: It would be of great help if you added keyword "COORDSYS".

Reading PVDO

The new parser does not read PVDO. I need it for running SPE3. Is there a plan to include in the near future?

Minor build issue: CMAKE_CXX_FLAGS and friends are ignored.

I use a cache preload file (via the cmake -C option) that sets CMAKE_CXX_FLAGS, CMAKE_CXX_FLAGS_DEBUG and CMAKE_CXX_FLAGS_RELEASE. These flags seems to be ignored/overwritten by the opm-parser build system.

I noticed this because I got warning-free builds in opm-parser, yet the same code generated many warnings from opm-core.

WCONHIST - RESV

In Schedule.cpp (line 254) we find the following comment:

/*
This is an awkward situation. The current control mode variable
points to a control which has not been specified in the deck; i.e. a
situation like this:

   WCONHIST 
      'WELL'      'OPEN'      'RESV'      0.000      0.000      0.000  5* /
   /

 We have specified that the well should be controlled with 'RESV'
 mode, but actual RESV value has been defaulted. ECLIPSE seems to
 handle this, but the well machinery in OPM-Core keeps close track of
 which controls are available, i.e. have a value set, and will be
 confused by this. We therefor throw here; the fix is to modify the
 deck to set an explicit value for the defaulted control, or
 alternatively change control mode.

*/

Actually, there does not appear to be any entry available for an explicit value of RESV under WCONHIST. The volume is to be computed during simulation from the given phase composition representing historical well rates. Not very exciting (all zero) in the example chosen above, but the combination of WCONHIST and RESV is extensively used for the Norne case, see INCLUDE/BC0407_HIST01122006.SCH.
This issue must of course be considered in connection with current or future functionality available from opm-core ...

“make test” final test fails, seemingly just missing test data file

When running “make test”, the final test fails with:

19/19 Test #19: runIntegrationTestsInternalData ...***Failed 0.03 sec

Examining the appropriate section of Testing/Temporary/LastTest.log reveals:

unknown location(0): fatal error in "ParseFileWithManyKeywords": std::invalid_argument: Failed to open file: testdata/statoil/gurbat_trimmed.DATA

So it seems that the file “testdata/statoil/gurbat_trimmed.DATA” has simply been accidentally omitted from the repository.

keyword PVTG: unit for gas formation volume factor?

In field units this is rb/Mscf, thus "OilDissolutionFactor" should probably replace "1".

Unit system of the default values

Currently, the defaults in the JSON files seem to use a mix of the metric unit system (e.g. the "ROCK" keyword) and SI units (e.g. the "WCONINJE" keyword). My question is: what should be used and is the unit system for the default values considered in the current code? (i.e. do the DeckItems default to the same values independently of the unit system which is used by a given deck?)

No “make install” target.

emmet@arugula:/opt/src/OPM/BUILD/opm-parser$ sudo make install
make: *** No rule to make target `install'. Stop.

I'm pretty sure this is an oversight, since other code (including, possibly, my own) will surely want to include the headers and link against the libraries provided.

Faulty handling of WCONHIST/RESV

The handling of keyword WCONHIST, and especially the RESV control mode is currently wrong and I don't think the situation can be corrected without non-local code changes either.

Consider the following example from opm/parser/eclipse/EclipseState/Schedule/Schedule.cpp (ca. line 260).

WCONHIST
-- Name     Open?    Mode    ORAT    WRAT    GRAT
  'WELL'    'OPEN'   'RESV'  0.000   0.000   0.000  5* /
/

The surrounding comment states that this is undefined because the RESV control is defaulted (and the code throws an exception in this case). Unfortunately, that reasoning is not true. If this were WCONPROD then the RESV control target (item 8) would indeed be defaulted and terminating the process would be appropriate.

In the case of WCONHIST, however, the RESV control mode is a bit more subtle. In this case the simulator must translate the surface rates (ORAT, WRAT, GRAT) to reservoir conditions (by means average conditions calculated at the beginning of the time step) and then sum the resulting (reservoir) rate values to compute the actual RESV target. As the above values are all zero this would correspond to RESV=0 irrespective of field conditions, but non-zero values of the surface rates will lead to a non-zero RESV target.

I'm afraid I don't have a suggested solution to this problem, but it may be that we cannot use a single function (Schedule::handleWCONProducer()) to handle all aspects of both WCONPROD and WCONHIST.

I also apologise for providing incorrect information during the initial design and implementation of the WCONHIST support.

Change FaceDirEnum values such the *MINUS < *PLUS

The values are currently defined as:

enum DirEnum {
  XPlus  = 1,
  XMinus = 2,
  YPlus  = 4,
  YMinus = 8,
  ZPlus  = 16,
  ZMinus = 32
};

Is there a special (algorithmic) reason why {X,Y,Z}MINUS > {X,Y,Z}PLUS? For me this was kind of counter intuitive.

I am aware that one should not rely on these values, but in the rest of OPM it is the other way around. E.g. For UnstructuredGrid faceTag is in [0, ..., 5] meaning [I-, I+, J-, J+, K-, K+]. Similar (+1) for CpGrid.

In the current situation translating the UG values to FaceDirEnum is

Opm::FaceDir::DirEnum faceDirection =
    Opm::FaceDir::DirEnum(1<<(faceTag-faceTag%2+(faceTag+1)%2));

which seems much uglier as for switched values (_MINUS<_PLUS):

Opm::FaceDir::DirEnum faceDirection =
    Opm::FaceDir::DirEnum(1<<faceTag);

If there is no special reason for the current situation I would propose to change to:

enum DirEnum {
  XMinus  = 1,
  XPlus = 2,
  YMinus  = 4,
  YPlus = 8,
  ZMinus  = 16,
  ZPlus = 32
};

Default values for SWL-family in the case of a non-global 'box'

From the Norne deck:

COPY
  'SGU'   'ISGU'    1 46 1 112  5  22 /   -- i.e not defined for layer 1-4,   need to pick default values from saturation tables ...
/

By changing default value to be outside 0-1, e.g.

SupportedDoubleKeywordInfo( "ISGU"   , -0.1, "1" )

it will be possible later to identify defaulted values and replace them with table look-ups as needed.

Is this a reasonable fix???

build: cannot find DefaultKeywordList.cpp

on a fresh copy of opm-parser, I get the following at the end of the CMake run:

CMake Error at opm/parser/eclipse/CMakeLists.txt:180 (add_library):
  Cannot find source file:

    /home/and/src/opm-parser/generated-source/DefaultKeywordList.cpp

problems reading completion data

I tried to run SPE9. If I look at the well data all production wells penetrates the same cells. A closer look at the WellsManager.cpp under the compdat handling (line 469) shows i = -1, and j = -1 for all wells. The input deck uses 2* for the i and j coordinates in COMPDAT. When I manually add i and j coordinates from the WELSPECS, the first well 'INJE1' correctly returns the i and j coordinates, but not the remaining 25 producers.

missing CJSON

When I try to build opm-parser with cmake I get:

Could NOT find CJSON (missing: HAVE_CJSON)

I have tried to build opm-parser within the same tree and in a sibling directory opm-parser-build.

Do I need to install json independently?

I am using SUSE 12.1 (x86_64).

Failure to read spe9 test deck.

This is a very recent failure, an exception is now thrown in DeckItem.cpp line 50 where none was thrown before (the size is apparently zero here). Can this have anything to do with changes to default handling?

Optional TABDIMS keyword must be present

(HEAD(opm-parser) = 5a097b3, HEAD(opm-core) = 55427b2)

Consider the following example program, called whereismytabdims.cpp:

#include <opm/parser/eclipse/Parser/Parser.hpp>
#include <memory>
#include <string>

int main () {
    std::string s ("SWOF\n0 0 0 0\n/\n");
    //s = "TABDIMS\n/\n" + s;
    auto parser = std::make_shared <Opm::Parser> ();
    auto deck = parser->parseString (s);
    return 0;
}

with the following build file, CMakeLists.txt:

cmake_minimum_required (VERSION 2.8)
project (wheresmytabdims)
enable_language (CXX)
find_package (opm-core REQUIRED)
include_directories (${opm-core_INCLUDE_DIRS})
link_directories (${opm-core_LIBRARY_DIRS})
add_definitions (${opm-core_DEFINITIONS})
add_executable (wheresmytabdims wheresmytabdims.cpp)
target_link_libraries (wheresmytabdims ${opm-core_LIBRARIES})

(I include opm-core instead of opm-parser because the latter does not generate an opm-parser-config.cmake file; by include opm-core, I get all the settings).

Running this program results in the following error:

terminate called after throwing an instance of 'std::invalid_argument'
  what():  Keyword: TABDIMS is not found in the container
Aborted (core dumped)

If I uncomment the second statement, it works.

On the unit of the oil/water rate in the output summary file.

I had problems in finding the conversion factor between the water/oil rate in the output summary files between Eclipse and OPM.

The DATA file is for METRIC, I assume that the unit from Eclipse should be m^3/day and the unit from OPM should be m^3/s. The conversion factor should be something like day (86400).

But finally the conversion factor turned out to be day^2.

I think there should be a bug in the output functions.

WCONPROD seems to confuse pressure and gas rate control

If I specify this keyword in the SCHEDULE section:

WCONPROD
    p1   OPEN   BHP   -1    -1   -1   -1   -1   97   /
/

I get the exception/error message:

Gas phase not active and GRAT control specified.

(thrown in https://github.com/OPM/opm-core/blob/master/opm/core/wells/WellsManager.cpp#L484). It is correct in that there is no gas phase in the simulation, but not that gas rate control is specified.