On 11/19/14 12:35, Jørgen Kvalsvik wrote:
On 2014-11-19 11:11, Bård Skaflestad wrote:
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/
Wouldn't it be better if this wasn't necessary?
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
If you want to look at it that way, sure, but it's not really what I'm
suggesting. The separation will still exist, but the unit will be a
branch and not a repository. Since branches can be just as independent
as repositories it wouldn't really change anything except for
convenience in the right places.
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.
git clone -b opm-core github.com:opm-project
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.
I didn't suggest that at all.
[...]
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.
The argument was mostly related to size and code management.
You know, every one is tossing around sharp comments. These may seem
"sharp", but I have repeatedly posted to this project about structural
problems with fiefdoms.... (ymmv).
When I suggested to develop an overall (general) set of design
documents, it was mostly:
A) to explain how existing codes inter-operate
B) to get each module into standalone mode (..configure make makefile)....
C) make it easy for EVERYONE to understand the fundamental modules
D) support and encourage competing codes from every critical component
E) encourage new (possibly fringe) code development
F) encourage porting or supporting API interfaces to other relevant codes
G) Support parallelization of as many codes as possible
H) to facilitate migrating to a variety of cluster/ cloud/ HPC/ SIMD
/ GPU types of processors and environments
I) to break down what is a complex field and open it up to "Analytics
development and other related needs (I could go on and on).
I think you get the picture now. Is OPM just a fiefdom of warring
Vikings?
If not, how many platforms are supported?
REDHAT sucks for (source) code development! Y'll might want to think
about a more useful platform, such as ARCH or Gentoo linux, or another
"source coded based distro. Maybe support 3 or 4 platforms? That forces
functional commonality and limits "shenanigans" imho. Binaries are
always months to years behind downloading nightly patches and
recompiling the latest stuff for testing. We do that on Gentoo, everyday
and it really helps sofware development. Anyone using GCC-4.9.x ?
If not, why not?
Like I said before Gentoo has a very, flexible (albeit not perfected
yet) working solution to dependency hell. Folks that need/want to deploy
OPM (and other codes) would be well served by multi-platform support. If
that is ugly, it because of a lack of general overall architecture,
imho. ARCH linux is so open, regular users can create modules that
compile codes and a myriad of repositories for folks to download
sources, and compile; often with a variety of compilers, libraries and
other (openly) supporting tools. Anyone using Clang (llvm) on any of
these codes? If not, why not?
Anyone use Icedtea in lieu of proprietary Java crap binaries ?
If not, why not?
Several Gentoo developers have participated in developing ebuilds for
OPM. But the development environment is artificially challenging to
say the least. It does not have to be this way, imho. They all have
already left OPM; I'm the lone gentoo proponent left who is still
interested in OPM..... (thats a sad testament in and of itself).
I have pointed several mathematically astute coders to OPM that are
most interested in the mix of possibilities. After looking around, it
was a "no thanks". One I offered to pay; he still said no.
OPM is beginning to smell like old fish, imho. Open it up for everyone
to use, code and run as they like; or quite calling it opensource.
hth,
James
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
