Hi all, I've recently been trying to install OPM, and have been experiencing great difficulty, so it seems like an opportune time — with all the activity going on surrounding the imminent release version — to make a comment or two that you might consider for the future.
The short version is this: I think it would be very worthwhile doing a “dependency audit”, documenting required support for dependencies. Very very long version (sorry): First, it's great that OPM is out there and in active development. Second, I don't think there's necessarily anything wrong with 10 year old software if it cannot be improved upon (I say this because some of the “deep dependencies” of OPM are very, very old). I hoping that this comes across as constructive, rather than just me whining (it's a concrete suggestion that I think I can help with), so I'll tell my story... I have come to OPM looking for open source reservoir simulation software. In a nutshell, my research is about novel methods of performance assessment and enhancement applied to scientific simulation software, particularly reservoir simulators. For this purpose, OPM seems to be, pretty much, the only game in town. After installing the Ubuntu packages, I discovered that OPM is more of a source-level toolkit, so packages seem to be of limited value. Consequently, I decide to install from source, but that's OK: I'm a “non-traditional” grad. student with not far off 20 years of Unix/Linux software development experience under my belt, so I'm not phased by a tough install. The problem here is, what I can only describe as, “dependency option snowballing” (with a little bit of “dependency obscurity” and obsolescence in there as well), as I've been trying to build OPM, I've been documenting the dependencies I've found. Ultimately, I hope to be able to show a full dependency graph, but for the moment, let me just give you an example: In order to install OPM, I need to install DUNE, so now I'm into DUNE's dependency graph. Climbing up from 'dune-common', one arrives at 'dune-grid', which has many optional dependencies including 'Alberta', 'AluGrid', 'UG', 'Amira', and 'psurface'. Wanting a reasonably comprehensive installation (I don't want to have to reinstall everything later because I forgot to include an “option” here), I try to install Alberta. Luckily, there's a Debian/Ubuntu package for Alberta (libalberta2-dev), but it's version 2.0, which, apparently, doesn't cut the mustard. Even if it did, it wouldn't matter, because it, in turn, is dependent on OpenDX (libdx4-dev), whose libraries are not linked properly (this is the reason for the DUNE caveat about building Alberta statically), so I have to rebuild them from source if anything further up the tree is going to build (this kind of thing often happens in the darker corners of distributions that we sometimes inhabit). It turns out that OpenDX has been abandoned for 6 or 7 years, and the canonical links to download the source are all broken, but I manage to get the source from the original tarballs used by various Linux distros. I'm compiling it now to see if the library mislinking is still a problem. Now, you can probably say, “Don't be crazy, Emmet, OPM doesn't use the Alberta-related features in DUNE, why are you bothering with all that?”. My answer comes in the form of another question: “How could one possibly know that?”. So, I hope you can see how *enormously* helpful even a simple piece of information like “OPM does not use Alberta support in DUNE” would be. That sentence would have saved me a couple of days' work. I understand the temptation to say that all of the above is really more about DUNE than OPM. The DUNE guys will tell me that it's really more about Alberta than DUNE. The Alberta guys (if they're still alive) will tell me that it's really more about OpenDX than Alberta. They're all strictly correct, of course, but their answers are all perfectly useless. But it does strike me that everyone who wrote a DUNE-dependent module in OPM knew what s/he was doing, knew exactly what features of that DUNE module s/he needed and didn't need. If that information were collected in one place, it would make life a lot easier for people to work with OPM. And this brings me full circle back to the short-form suggestion of a “dependency audit”. Once the dust has settled on the upcoming release, I think it would be very worthwhile indeed for those knowledgeable about these dependencies to document them in some way. I'm not sure what the best way of doing that is, but I'm hopeful that my dependency graph might make some contribution. Thank you all, Emmet. _______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
