OPM reorg 2015

From opm
Jump to: navigation, search

Ideas for reorganisation (modules/repositories) of OPM.

Tip: sign your contributions by using three tildes (~). Atgeirr (talk)

Governing Principles

  • modules should be self contained (what does that mean, exactly? Atgeirr (talk))
  • the domain of modules should be well defined
  • not too many modules
  • not too deep hierarchy (as a rule of thumb, no more than four modules to get any one module?) Atgeirr (talk)

Concrete Measures

Alternative A

  • rename the "dune-cornerpoint" to "opm-grid"
  • rename the "opm-autodiff" to "opm-flow" (?)
    • What about just "flow"? Atgeirr (talk)
      • probably we should keep the "opm-$FOO" convention for module names andlaus
    • I think opm-flow should also contain opm-material. Minor disadvantage for eWoms, advantage for everything else.Atgeirr (talk)
  • fold the "opm-polymer" module into the others:
    • merge the AD-based simulators with "opm-flow" and the IMPES ones with opm-porsol
  • officially put the opm-poresol, opm-upscaling, opm-verteq and opm-benchmark modules into maintenance mode (?), i.e., they won't see any new developments for now and won't be mentioned in the release notes but they will be kept in compilable state with passing unit tests.
  • rename "opm-cmake" to "opm-common" and add fundamental infrastructural code to it
  • The intention of "opm-common" is that it does not inflict any cost for to dependent modules:
    • it should be useful in a wider context than just the simulator (e.g. it should be useful for the parser, the material relations, etc.)
    • it should not require to link to external libraries (except maybe boost)
      • This is a hard question: I think we should allow boost in there (installation procedures for boost are good enough). What about Eigen? It is a header-only lib so it is very easy to install. But I see this is a slippery slope. Atgeirr (talk)
    • it should not represent a library on its own
      • I like libraries:Joaho Me too! Atgeirr (talk)
        1. Compile time of (other modules) go down
        2. We can have small C functions
        3. It will be somewhat easier to enforce internal correctness in opm-common if it is a standalone compilation unit.
    • Examples: build system, exception classes and macros, Opm::Evaluation, ...
  • retire the opm-core module
    • move the grid code to opm-grid
    • move the simulator classes to their respective consumer modules (i.e., opm-flow and opm-porsol)
    • move the *really* basic infrastructural code to opm-common

Discussion: I really do like this alternative proposed by Andreas, I think that using opm-common as the central module upon which all others depend makes sense, as it allows us to re-think what goes into it (whereas using opm-core would carry some baggage). Atgeirr (talk)

Joakim

All in all I think Andreas suggestions are generally good - just some more comments/questions:

  1. Where does the well stuff from opm-core go?
    • long term, I propose it should be disbanded and its pieces should go to opm-common, opm-grid, opm-porsol and opm-flow Andreas
  2. Should we create opm-simulator: containing the flow simulator, the simulators from opm-core and opm-porsol?
    • I think it is better to keep the simulator module as small as possible, i.e., IMO we should probably leave the legacy code where it is Andreas
  3. Rename opm-parser -> opm-io and:
    1. Move the logging to opm-common
    2. Renama ParseMode -> ErrorHandler and move it to opm-common
    3. Move the EclipseWriter++ from opm-core to opm-parser (i.e. opm-io)
    • In general, I agree. it would be better to call the module "opm-eclio" though because everythig in there is very ECL specific Andreas
  4. For opm-common I think it could be a design principle that nothing goes into opm-common before it has at least two other opm modules using it; if it is only used by one module - it can stay in that other module. In that way the other modules can all serve as a 'staging area' for code which might end up in opm-common?


Action points

I suggest the following actions to be taken, in order:

  1. Complete the opm-cmake -> opm-common renaming.
  2. Move initial code to opm-common (initially nothing that requires third-party libs, so not AutoDiffBlock yet). In particular the parts of opm-core needed by dune-cornerpoint should be moved there.
  3. Creation of opm-grid from dune-cornerpoint and grid parts of opm-core. After this, opm-core depends on opm-grid.
  4. Rename opm-parser into something with i/o.
  5. Move some parts of opm-core to other modules (such as to the i/o module, a new, standalone diagnostics module [assuming it is sufficiently application-ish] etc.).
  6. Create opm-flow (or other name) from remaining parts of opm-core, and all of opm-autodiff and opm-polymer.
  7. Move simulators from opm-porsol to opm-flow.
  8. Unify opm-porsol and opm-upscaling (unclear at this point if it must depend on opm-flow or not).

Atgeirr (talk)