On Monday 07 October 2013 11:36:59 Joakim Hove wrote: > > > I am certainly open to the possibility that opm-parser should be part of > > > opm-core. > > > > To me it seems natural that parsing input files belongs to the core > > library. > > I can see that keeping opm-parser and opm-core as separate repositories > > long term can be convenient from a maintainer perspective, but I have a > > hard time seeing that it can be beneficial from any other perspective. > > Please enlighten me if there are important aspects here that I don't see. > > > > ie, the only aspect that matters? user issues are solved through other > > means, buildsystems are there for developers and should be optimized for > > developer convenience. the more you can split, the less bug prone the > > development get in my experience (though setting up a build tree is > > slightly harder). > > > > furthermore, opm-core is already bloated with tons of stuff that for my > > eyes > > do not appear to belong there (linear solvers, model parsing, a strategy > > for dog walks, etc). some of the stuff is misplaced there to the extent > > that is has been duped where it is more natural to put it (linear solver > > interfaces are duplicated in porsol). > > imnsho*, the core library should just be a set of core utilities which are > shared between modules, not a dump to avoid having to deal with more > modules. parser should use core. core should not use parser. there is > absolutely no requirement to use .grdecl files to use the rest of opm. why > should it then sit in the core? > > Well - I have very limited experience developing with opm-core, but my gut > feeling is to agree strongly with Arne Morten. IMNSHO opm-core is way too > large. Ultimately opm-parser should use opm-core in the sense of low level > core routines, but the scenario where opm-parser uses opm-core is quite far > away from the current incarnation of opm-core. I realize my weight of say > in these matters is quite limited, but in my opinion it would be healthy > for OPM as a whole to refactor the module organization?
Just to put my insignificant opinion into the discussion: I tend to agree. What I envision the purpose in opm-core to be is something akin to the dune-common module: A collection of useful generic utilities which do not come with a high/any burden if you don't use them. (In this special case, it might also be worth to note that one fine day, OPM will hopefully not just about reservoir engineering anymore and the eclipse parser would not make much sense for e.g. groundwater problems.) But actually, that issue is not too important to me :) > Well - I'll put on my asbesto underwear :) No reason to do so: There do not seem to be too many people who care in a flaming way ;) cheers Andreas -- A programmer had a problem. He thought to himself, "I know, I'll solve it with threads!". has Now problems. two he -- Davidlohr Bueso
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
