OPM / opm-simulators

OPM Flow and experimental simulators, including components such as well models etc.
http://www.opm-project.org
GNU General Public License v3.0
112 stars 122 forks source link

Too many example programs #601

Open joakim-hove opened 8 years ago

joakim-hove commented 8 years ago

I am now close to complete the replacement of SimulatorState from opm-core with SimulationDataContainer from opm-common. During the work I have made the following observations- which I would like to discuss:

  1. Doing the replacement in the main flow chain was quite simple - good.
  2. In both opm-core and opm-autodiff there are numerous small example programs / tutorials which also must be updated. Doing the update in these example programs was not difficult, but it was a quite large, repetetive and error prone process which took far more time than the flow part of the work.

The end result of this is that the effort required to refactor/support a part of the codebase people do not care so much about, far outweighed the effort required to refactor our main piece of software - i.e. flow. This summary only applies to the effort required to make the code compile; but that is of course only the start. I fear the various sim_xx_yyy_zzz example applications do not even work:

  1. There are limited (no ??) unit tests for special functionality not covered by flow.
  2. The programs are generally not used/tested by developers. For manual testing I assume flow gets 9x% of the attention.

So in the current form I feel the various sim_xxx_yyy_zzz applications are a drag on the codebase, and something should be done. Possible approaches - listed in order of increasing effort and "goodness":

  1. Just remove most of them.
  2. Refactor the sim_xxx2p_yyy in the same way as has been done with FlowMain.hpp.
  3. Refactor as with FlowMain.hpp - and create unit tests for the functionality we actually care about.
joakim-hove commented 8 years ago

Ping?

atgeirr commented 8 years ago

Did not notice there was a lot of stuff here (my email said the message was just "XX"), looked at it now.

I think a refactoring would be good, but we could also remove some that are no longer needed. We should not remove the incompressible two-phase stuff, that is a quite useful and common simplification, well suited as a starting point for students etc.

I'll look at this next week.