On 2014-11-19 17:41, Jørgen Kvalsvik wrote:
On 2014-11-19 07:27, Alf Birger Rustad wrote:
Hello everybody,
I am guilty of creating yet another repository in opm. [...]
Honestly, I don't think it's that good an idea to have separate
repositories at all [...]
Noted.
3. Increased maintenance cost of the build system, cmake modules
especially.
http://rolk.github.io/2013/09/23/build-system-sync/
[...]
This is what I propose instead:
Remove the repositories all-together and replace with a single opm repo.
So, you're proposing to undo the (more or less) careful separation of
responsibilities of user-facing features into autonomous but related
modules for the sake of build-time convenience for the *very* few OPM
developers? That won't happen as long as I have any say in the matter.
Were it not for the fact that opm-core depends on opm-parser I would be
able to download "only" opm-core and get access to powerful grid
processing routines, an implementation of mimetic discretisations
(somewhat languishing but nevertheless working), partial support for the
multi-scale mixed finite-element method, time-of-flight solvers based on
the reordering technique, explicit and implicit solvers for two-phase
incompressible transport problems. In essence, fundamental tools for
doing simple calculations in porous media applications.
If we renege that ability in order to manufacture a single monolithic
package for black-oil applications, albeit with interesting physical
properties such as polymer and/or thermal effects, then the project has
lost its way.
[...]
For reference, the Linux kernel, which is a much larger project than
opm, only use one repo.
Clients are expected to use the entire Linux tree as whole when doing
anything with the Linux sources. That assumption doesn't hold in the
case of OPM.
--
Bård
(With hat: OPM project maintainer since project inception)
_______________________________________________
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm
