Fails to build

[EmmetCaulfield]

All OPM project pulled into separate directories in /opt/src/OPM.

After creating build directory and doing 'cmake', 'make' fails with:

/opt/src/OPM/opm-core/opm/core/io/eclipse/EclipseGridParser.cpp: In member function ‘void Opm::EclipseGridParser::saveEGRID(const string&, int, const int_) const’: /opt/src/OPM/opm-core/opm/core/io/eclipse/EclipseGridParser.cpp:976:61: error: too many arguments to function ‘bool ecl_util_fmtfile(const char)’ /usr/include/ert/ecl/ecl_util.h:172:17: note: declared here /opt/src/OPM/opm-core/opm/core/io/eclipse/EclipseGridParser.cpp: In member function ‘void Opm::EclipseGridParser::saveINIT(const string&, const ecl_gridtype)’: /opt/src/OPM/opm-core/opm/core/io/eclipse/EclipseGridParser.cpp:1052:55: error: too many arguments to function ‘bool ecl_util_fmtfile(const char)’ /usr/include/ert/ecl/ecl_util.h:172:17: note: declared here /opt/src/OPM/opm-core/opm/core/utility/Units.hpp: At global scope: /opt/src/OPM/opm-core/opm/core/utility/Units.hpp:104:22: warning: ‘Opm::unit::liter’ defined but not used [-Wunused-variable] make[2]: * [CMakeFiles/opmcore.dir/opm/core/io/eclipse/EclipseGridParser.cpp.o] Error 1 make[1]: * [CMakeFiles/opmcore.dir/all] Error 2 make: *\ [all] Error 2

[bska]

I can't reproduce this issue locally. What version of the ERT (or its libecl component) do you have? If I recall correctly, there was an interface change to a number of the libecl files earlier this year (maybe around April) and we (i.e., opm-core) had to play catch-up. Looking through the logs, it appears that we caught up to the interface change in early May, specifically in commit a6e3bbd.

Maybe you just need a more recent edition of the libecl?

[rolk]

@bska Do we need a version test in FindERT, or is this issue soon to be moot once opm-parser gets off the ground?

[bska]

@rolk

Do we need a version test in FindERT, or is this issue soon to be moot once opm-parser gets off the ground?

I'm not really sure how we would perform such a check. I may be wrong, but as far as I know, the ERT software exists only as a Git repository at the moment (i.e., no official, numbered .tar.gz). Trying to use Git during FindERT to test for the presence of a particular commit sounds to me like a recipe for hair pulling. We could of course use check_c_source_compiles() to test for all possible variations of all ERT functions used in all OPM modules, but I think that would be asking too much of the build system. No to mention brittle. At the moment, the best we can do is state that OPM's ERT support targets the upstream master branch. At least the API (of the functions we use) is moderately stable.

is this issue soon to be moot once opm-parser gets off the ground?

The opm-parser will certainly be a game changer, but I think it too depends on libecl so we will need to detect and enable that software in the foreseeable future.

[rolk]

We could of course use check_c_source_compiles() to test for all possible variations of all ERT functions

I was more thinking about using check_c_source_compiles to find the change in the latest commit that we know works with OPM, and declare every other as "too old" and issue a warning/error.

[bska]

I was more thinking about using check_c_source_compiles to find the change in the latest commit that we know works with OPM, and declare every other as "too old" and issue a warning/error.

That's a good idea. Lets pick it up once the roll-ups are done. Agree?

[joakim-hove]

Hello;

sorry I'm late to the discusssion. I guess the best(TM) solution would be to have proper version on the ert libraries? I have been a bit uncertain on versioning, to me it seems one needs to support two different version numbers, one for the features and one for the the A(PB)I? With some assistance from the local gurus I guess we can come up with a good scheme.

The coming of the parser is quite independent of this; the existing ert code is mostly related to binary files, whereas the parser is currently only related to ASCII input. There is currently no ERT dependence in the parser, but that might come when we extend the parser library to include a EclipseReservoir class.

Joakim

[bska]

The coming of the parser is quite independent of this;

Don't you mean the Second Coming ?-)

Jokes aside. Thank you for the information on parser prerequisites and ERT independence. I suppose one might consider binary file support if one wants to support 'IMPORT' and/or restarting, but that is probably some ways away. I look forward to playing with it.

[bska]

I forgot about this

I guess the best(TM) solution would be to have proper version on the ert libraries?

"Maybe". In general, one should test for features rather than version numbers, but on the other hand it does happen that a particular test is only available when using a numbers test.

[andlaus]

"Maybe". In general, one should test for features rather than version numbers, but on the other hand it does happen that a particular test is only available when using a numbers test.

Conceptually that's certainly the right approach. the problem is that it tends to be very slow and error-prone at configure time...

[rolk]

using check_c_source_compiles to find the change in the latest commit that we know works with OPM

it appears that we caught up to the interface change in early May, specifically in commit a6e3bbd

So, if the signature is ecl_util_fmt_file (char*, bool*) then we are good to go?

[bska]

So, if the signature is ecl_util_fmt_file (char*, bool*) then we are good to go?

That's a necessary condition. I'll need a bit more time to establish if it is sufficient too (i.e., we may be using other ecl_*() functions that changed signatures at around the same time). Maybe @joakim-hove recalls the details?

By the way, as a C++ bool is not necessarily the same as a C99 _Bool (bool if one #includes <stdbool.h>) this signature is strictly speaking unportable. In practice, though, I can't imagine a toolchain for which the types aren't bit-wise exact copies.

[joakim-hove]

So, if the signature is ecl_util_fmtfile (char, bool_) then we are good to go?

Yes :-)

[EmmetCaulfield]

The offending header file belongs to the libert.ecl-dev v.1.04 .deb package, installed from the Ubuntu 12.04 (“Precise”) OPM PPA.

If there's a dependency on this, which there appears to be, it might be worth mentioning where it can be obtained in the download/install instructions.

[bska]

@EmmetCaulfield remarked

installed from the Ubuntu 12.04 (“Precise”) OPM PPA.

@akva2: Do you know if that PPA is current? I know we (i.e., you) definitely did a lot of work getting the packages off the ground when we created 2013.03, but I don't know if there have been any changes to the prerequisites over the past months.

[bska]

Sorry. I forgot about this part of the comment

If there's a dependency on this, which there appears to be

The ERT is supposed to be an optional extra component that enables support for outputting binary ECLIPSE result files. OPM is supposed to be functional without the ERT. If that's not the case, then that's a bug and we'd very much welcome a report.

it might be worth mentioning where [the ERT] can be obtained in the download/install instructions.

Good point. We'll add it to the list of items that must be resolved prior to the next release (currently scheduled for September).

[EmmetCaulfield]

Maybe a beginner's perspective might be useful here, as I'm guessing that you guys probably don't have much need of referring to the documentation much. As far as I can tell, OPM is really a source-code level reservoir simulator “erector set”. At least, that's the impression that I get from the examples/tutorials which immediately dive into C++ source code. I'm not sure that it's worth the effort for you to prepare binary distro packages (.deb, .rpm, etc.) if one ultimately has to install the source to do anything, which is the way it seems to me.

If, on the other hand, there is something useful that one can do, having installed only the binary distro packages, that would be worth documenting. As far as I can tell, there are two binaries installed, (sim_2p_incomp and sim_2p_comp_reorder), but I had to drill down into the source code to figure out how to get these to do anything other than their default behavior, since their argument processing is non-standard, there is no '--help' option, manpage, or anything else explaining their operation and use. It's still not clear to me that I can actually do anything with these other than trivially play around with, say, the dimensions of a homogeneous Cartesian reservoir model.

There also seems to be a lot of emphasis on ECLIPSE files to the extent that I don't have any idea what the “native” format of OPM might be (if it has one). I've figured out how to set certain values via XML parameter group files (although I still haven't figured out why you bother with XML), but how do I load porosity or permeability fields/maps?

I don't mean to sound hypercritical, but I guess I'm saying that, as a newbie, I'm finding OPM to be very under-documented at the user level of “I want to set up and simulate a problem”, although I must admit that the source code I've browsed so far has been considerably better commented than my own :)

[bska]

@EmmetCaulfield You make a lot of valid points and I'll reply more thoroughly later. At the moment, I'll just grant you the fact the OPM does not feature (anywhere near) enough documentation directed towards users. We're well aware of that and are hoping to improve as time passes.

[rolk]

@EmmetCaulfield

installed from the Ubuntu 12.04 (“Precise”) OPM PPA

Unfortunately, we haven't had the capacity to update those between the releases. You'll have to build a newer version of ERT from source, too. Do you build in /opt/src/OPM or are the builds in a separate directory?

how do I load porosity or permeability fields/maps?

I think the easiest way to do that is to start with an existing Eclipse model (i.e. set a deck_filename in the input to sim_2p_xxx)

[alfbr]

@EmmetCaulfield the user documentation is under construction. You will find the current state here: http://www.opm-project.org/wiki/index.php/Main_Page

Generally speaking, the reservoir simulation part is under construction, and we have a preliminary goal of being able to run a standard simulation within Christmas with standard input/output. Eclipse is today the industry standard for reservoir simulation, with a dominating market position. Hence, all pre- and post-processing tools in the industry is adapted to that situation. It does not currently make sense to make a new format, what we have somewhat discussed, but postponed due to resources, is supporting Rescue. This is an open project, and you are of course free to implement another format. The current work on opm-parser is done generic to make supporting other formats easier.

You will find that all upscaling codes are ready for users without any source code dive. Feel free to expand the wiki :)

What do you envision using opm for?

[EmmetCaulfield]

@rolk and @bska: I found, git-cloned, built and installed ERT and the latest git pull of opm-core builds successfully against it. I pull the git repos into separate subdirectories of /opt/src/OPM (i.e. /opt/src/OPM/opm-core, etc.) and do out-of-source builds in /opt/src/OPM/BUILD/opm-core, etc.

@bska, regarding ERT being optional: a simple "cmake, make" of a git clone of opt-core fails with the error-message related to ERT, so either it's included unconditionally or the conditional inclusion is not sensitive to the version (and the version I had installed from .deb packages was too old).

@alfbr, regarding what I envision using OPM for: I've written a tool that graphically presents hardware counter data (from the Linux perf_events kernel subsystem) in a number of different ways, and I'm going to use OPM as a “large” subject. It would take quite a bit of explaining to give you a good picture, but, for the time being, I want to set up SPE-10 Case 2a as a model problem.

Also, I do understand Eclipse's market position, but I doubt that anyone would actually choose the Eclipse input format over something less painful, like, say, stabbing oneself repeatedly in the eyeball with a fork ;o)

[rolk]

@EmmetCaulfield

I found, git-cloned, built and installed ERT and the latest git pull of opm-core builds successfully against it

Good. The question was to prepare a response on how you could best do that, but it seemed that you were indeed capable to do it on your own. :-)

the conditional inclusion is not sensitive to the version

Indeed that was the case, but I believe issue #349 (which was opened as a result of this one) fixes that.

I'm going to use OPM as a “large” subject

You could also take a look on opm-benchmarks module, which is more "pre-canned" for this purpose.

[EmmetCaulfield]

@rolk: yes, I'll certainly do that now; I'm in the process of removing the packages that I had installed so there's no ambiguity about what headers are used or what's linked against what.

[bska]

but I doubt that anyone would actually choose the Eclipse input format over something less painful, like, say, stabbing oneself repeatedly in the eyeball with a fork ;o)

I prefer using a spoon myself. From a pragmatical point of view, supporting ECLIPSE input is merely a necessity for the type of work we've mostly been doing before. Much, although certainly not all, of the OPM code base is the current incarnation of resarch and development work that's been ongoing for the better part of a decade. It's been largely targeted towards single-phase and steady state (relperm) upscaling on rough grids represented in the corner-point format. As such, we have comparably mature support for those types of models whereas more traditional descriptions like Cartesian grids and individual arrays representing the permeability tensor have not received as much attention.

It is true that OPM at present is more of a "collection of tools" than an integrated whole. As @alfbr said earlier, we are working towards creating more complete simulators, but we are not there yet. I have personally used (and viewed) OPM as a library of subroutines that I can put together to solve a particular problem rather than a large box that will solve "all" problems. This developer-focused nature does require a certain familiarity with compilers and C++ which I guess makes the entry threshold somewhat high. It also means that the sim_2p_xxx utilities are more like examples than complete, polished products. That is unfortunate for the person trying to become familiar with the code base.

The XML files are an historical artifact. We just needed some way of putting together a consistent and repeatable set run parameters (e.g., tolerances, number of time steps, location of output files, names of input files) and XML was the most convenient format at the time. If we were creating something similar from scratch now we would probably end up using something else. In fact the opm-parser alluded to earlier uses JSON as its configuration format. There has been some discussion about transitioning away from XML, but no decision has been made as yet.

I hope this provides a bit of background on how the project has turned out to be the way it is. Please do not hesitate to ask any further questions and, by the way, welcome to the community! New contributors are always welcome.

[EmmetCaulfield]

@bska: Thank you for your help; if nothing else, the community response to my “hey, I couldn't compile this thing” has been tremendous. Incidentally, it's not so much that I've anything against XML for the representation of naturally hierarchical data, quite the contrary (I've used XML myself very extensively), it was more that I didn't see the point of it for the kind of data it seemed to be being used for. Perhaps as I become more familiar with the code base, it will make more sense to me. I presume that the preferred way of asking questions is the mailing list, which I've joined, so I'm sure we will have many more interactions there.

Thanks again.

[bska]

if nothing else, the community response to my “hey, I couldn't compile this thing” has been tremendous.

I suppose we're being particularly sensitive to build issues at the moment because we're in the closing stages of entirely rewriting the build system of all the modules and there are a lot of pieces to get right. We're hoping that it will become more robust and friendly to new users (and existing contributors alike).

Thanks, anyway, for the kind words.