Dune 2.2 is just around the corner, the release is planned to be in three week and the branch is already created. Are there any plans to move DuMuX from Dune 2.1 to 2.2?

I\'d like to make the move as soon as possible because for coupling we use some hand-picked versions from SVN which is annoying and error prone.
We would all profit from the bugfixes done by the Dune devs.

I\'d propose to start the transition for dumux (stable) directly after the Dune release. If we decide that, it would be a good idea to commit changes during the next three weeks.

I volunteer to do the work for dumux and dumux-lecture. For dumux-devel changes, I can help on request.

What are your thoughts?

Let us chase a new pig through the village, and I would like to thank Philipp for bringing this up: There is a lot of unification potential for the flux variables. I propose two stages:

1. Establish a base class, e.g. BoxFluxVariables providing and implementing the following interface:
face():
The (sub-control-volume) face to which the flux variables are referring.

up/downstreamIdx(int phaseIdx):
Obvious. We could default phaseIdx to 0 admitting a shortcut for single-phase models.

normalVelocity(int phaseIdx):
The normal component of the phase velocity. A default implementation using Darcy\'s law is provided which can be used by all standard porous media models. It could be overwritten by e.g. Stokes or extended by the possibility to use Forchheimer.

These are the only face quantities which are necessary for calculating the advective fluxes. Inheriting the model-specific flux variables from the base would greatly simplify all box flux variables. Plus greatly simplify the calculation of the advective fluxes in the computeFlux routine.

This sounds great, but there is a catch: for the calculation of Darcy\'s velocity, one has to upwind the mobility. For the calculation of the mass or enthalpy fluxes afterwards, one has to upwind again, e.g. density. If the upwind weight alpha is different from 1, this gives a different result as we would currently get. I think we can live with this since we anyway almost never choose the upwind weight different from 1. It also is rather a matter of interpretation than doing something better or worse.

2. Diffusive fluxes: This will require a bit more discussion, since this is handled rather differently among the individual models. We should discuss this after finishing 1.

Please contribute your thoughts.

Improve consistency for gradients whether it is a FieldVector<Scalar, dim> or a FieldVector<Scalar, worlddim>. We should investigate what would be correct and what we have to change.

After the release, it is time to remove the deprecated methods from the trunk. They are listed below. Please let me know if you have objections. Methods for which no objections arise will be removed April 5th.

dumux/material/spatialparameters/boxspatialparameters1p.hh:
extrusionFactorScv and extrusionFactorScvf, now part of the volume variables

dumux/material/idealgas.hh:
concentration, replaced by molarDensity

dumux/material/fluidmatrixinteractions/2p/efftoabslaw.hh:
pC(const Params &params, Scalar Sw, const Scalar temperature)

dumux/common/start.hh:
startFromDGF, startWithGrid, startWithParameters, all replaced by start

dumux/common/spline.hh:
set(const ScalarArray&, const ScalarArray&, Scalar, Scalar), replaced by setXYArrays,
set(const PointArray&, Scalar, Scalar), replaced by setArrayOfPoints

dumux/common/variablelengthspline_.hh, dumux/common/fixedlengthspline_.hh:
various set routines, replaced by more descriptive names

dumux/io/vtkmultiwriter.hh:
VtkMultiWriter(const std::string&, std::string), replaced by VtkMultiWriter(const GridView&, ...),
beginTimeStep, replaced by beginWrite,
createField, replaced by allocateManagedBuffer,
addVertexData, replaced by attachVertexData,
addCellData, replaced by attachCellData,
endTimeStep, replaced by endWrite

dumux/decoupled/2p2c/2p2cproblem.hh:
IMPETProblem2P2C(const GridView&, bool) replaced by IMPETProblem2P2C(TimeManager&, ...),
IMPETProblem2P2C(..., SpatialParameters&, ...) replaced by IMPETProblem2P2C(TimeManager&, ...),
initSat(const GlobalPosition&, const Element&) replaced by initSat(const Element&)
initConcentration(const GlobalPosition&, const Element&) replaced by initConcentration(const Element&)

The "stable class documentation" on the website still seems to be for the 2.0 release. It should probably be updated to the state of affair of Dumux 2.1.

Dumux handbook appears as generated from different sources.
Make graphics appear more coherent through the text, especially used colors in them.
Improve the latex writing of String DuMuX that it appears more like the logo on web site.
Write C++ with smaller +. If not exists write, a style guidefor content and layout. Add a glossary. Add documentation as own category in flyspray.

This task collects all tasks that are closed only because already implemented in the eWoms branch.
We must not forget these tasks.

Currently:
 FS#100  - Specify initial and boundary conditions independently of the physical model

 FS#103  - Specify problems and spatial parameters independently of the discretization

Currently dumux cannot be compiled with clang. It would be nice to change this because it has better understandable error messages and can compile a little bit faster.
Currently it is said that Dune can be compiled with clang.

At svn://svn.iws.uni-stuttgart.de/DUMUX many folders exist and seems to be orphaned. We should get rid of superfluous stuff.

I'd expect that with "make doc" we create the handbook and the Doxygen documentation. Currently only the Doxygen is run, not LaTeX. In any other case I would not build the both.

Do we still need the --enable-documentation flag? I think the documentation should only build when explicitly called "make doc".