- start with an initial "do nothing" episode of 100 days to get
hydrostatic conditions.
- after that, produce oil and inject water for 900 days. (thereafter
the reservoir will be empty.)
- make the problem work with element centered FV discretizations. this
requires to make the width of the injection/production areas at
least one cell wide. This is achieved by using the new "WellWidth"
property which specifies the with of wells as a factor of the total
domain width.
- make the problem work with fully compositional models. This implied
to calculate the full composition for the fluid states which specify
the initial condition and the thermodynamic state at the wells.
- add tests and reference solutions for any combination of the {ECFV,
VCFV} discretizations and the {black-oil, NCP} models.
- the residual now does not consider constraints anymore
- instead, the central place for constraints is the linearizer:
- it gets a constraintsMap() method which is analogous to residual()
but it stores (DOF index, constraints vector) pairs because
typically only very few DOFs need to be constraint.
- the newton method consults the linearizer's constraint map to update
the error and the current iterative solution. the primary variables
for constraint degrees of freedom are now directly copied from the
'Constraints' object to correctly handle pseudo primary variables.
- the abilility to specify partial constraints is removed, i.e., it is
no longer possible to constrain some equations/primary variables of
a degree of freedom without having to specify all of them. The
reason is that is AFAICS with partial constraint DOFs it is
impossible to specify the pseudo primary variables for models which
require them (PVS, black-oil).
because of this, the reference solution for the Navier-Stokes test
is updated. the test still oscillates like hell, but fixing this
would require to implement spatial discretizations that are either
better in general (e.g., DG methods) or adapted to Navier-Stokes
problems (e.g., staggered grid FV methods). since both of these are
currently quite low on my list of priorities, let's just accept the
osscillations for now.
* github.com:OPM/ewoms:
adaptation works, needs revision.
[dune-fem] using discrete function works.
some further work on grid adaptivity
dune.module: add dune-fem as a noptional dependency
Conflicts:
ewoms/common/start.hh
ewoms/io/basegridmanager.hh
ewoms/parallel/mpihelper.hh
this is not needed anymore because the grid manager is no longer a
singleton and the grid is thus is always destructed before
MPI_Finalize() is called.
i.e., removing redundant namespace open- and closings due to the fact
that the property system now resides in the 'Ewoms' namspace instead
of in 'Opm', and making the headercheck work for all headers.
for the Richards model we can't use the CO2 injection problem because
this problem cannot be simulated by the Richards model. (Well,
strictly speaking the Richards model *can* simulate it, but it would
only produce garbage because the assumptions of the Richards model are
violated by that problem.)
this works by introducing a splice called "LocalLinearizerSplice". The
the current local linearizer (which is based on the finite difference
method) is the default and can be set explicitly by setting the splice
to "FiniteDifferenceLocalLinearizer", the new linearizer using
automatic differentiation can be selected by setting the splice to
"AutoDiffLocalLinearizer".
now the generic part of the update of the solution vector is done in
the base class and the derived classes can chose to only do the update
of the primary variables of the individual DOFs.
This reverts commit c6c271f3ee. After a
more thorough investigation, the cannonical name of these quantities
turned out to be "* formation volume factor"...
this also fixes the SuperLU backend with __float128 on Dune 2.4. The
problem is that due to some hacks within dune-istl, the AMG solver
can't be used because it calls the direct solver directly without an
option to disable this. (This could be fixed in a similar fashion as
the SuperLU backend by copying everything into data structures which
use 'double' before calling into ISTL, but this is a thing for another
time.)
... and use the parallel AMG solver for the CO2 injection problem.
this makes performance comparisions with Dumux much easier as the
solver performance should be more similar.
