can this be removed for the sake of boundarytypes.hh?

Class Dumux::BalanceEquationOptions< TypeTag >

include useMoles here

include replaceCompIdx here

Class Dumux::BinaryCoeff::H2O_Component< Scalar, Component >

All other binary coefficient could be generalized like this

Member Dumux::BinaryCoeff::H2O_HeavyOil::gasDiffCoeff (Scalar temperature, Scalar pressure)

value is just an order of magnitude, please improve it

Member Dumux::BinaryCoeff::H2O_HeavyOil::henryOilInWater (Scalar temperature)

values copied from TCE, please improve it

Member Dumux::BinaryCoeff::H2O_HeavyOil::henryWaterInOil (Scalar temperature)

arbitrary value, please improve it

Member Dumux::BinaryCoeff::H2O_HeavyOil::liquidDiffCoeff (Scalar temperature, Scalar pressure)

value is just an order of magnitude, please improve it

Member Dumux::BlockDiagAMGBiCGSTABSolver::solve (const Matrix &m, Vector &x, const Vector &b)

Check whether the default accumulation mode atOnceAccu is needed.

make parameters changeable at runtime from input file / parameter tree

Member Dumux::CCMpfa::maxNumBoundaryVolVars (const FVElementGeometry &fvGeometry)

TODO What about non-symmetric schemes? Is there a better way for estimating this?

Member Dumux::CCMpfaHelper< GridGeometry >::findGhostVertices (const GridView &gridView, const VertexMapper &vertexMapper)

TODO: The name of this function is not so good, as these are not ghost vertices according to the Dune definition of ghost entities. Moreover, it should be tried to make MPFA work also with ghost entities.

Member Dumux::Components::Brine< Scalar, H2O_Tabulated >::liquidThermalConductivity (Scalar temperature, Scalar pressure)

TODO: For the thermal conductivity the salinity contribution is neglected. This contribution is probably not big, but somebody would have to find out its influence.

Member Dumux::Components::H2< Scalar >::vaporPressure (Scalar temperature)

implement the Gomez-Thodos approach...

Member Dumux::Components::O2< Scalar >::gasDensity (Scalar temperature, Scalar pressure)

: density liquid oxygen

Member Dumux::CompositionalFluidState< ScalarType, FluidSystem >::partialPressure (int phaseIdx, int compIdx) const

is this needed?

Class Dumux::DarcyDarcyBoundaryCouplingMapper< MDTraits >

how to extend to arbitrary number of domains?

Member Dumux::DiffMethod

automatic differentation is not yet implemented

Class Dumux::ElectroChemistry< Scalar, Indices, FluidSystem, GridGeometry, electroChemistryModel >

TODO: Scalar type should be extracted from VolumeVariables!

TODO: This shouldn't depend on grid and discretization!!

Class Dumux::ElectroChemistryNI< Scalar, Indices, FluidSystem, GridGeometry, electroChemistryModel >

TODO: Scalar type should be extracted from VolumeVariables!

TODO: This shouldn't depend on discretization and grid!!

Member Dumux::Experimental::MultiStageTimeStepper< PDESolver >::MultiStageTimeStepper (std::shared_ptr< PDESolver > pdeSolver, std::shared_ptr< const MultiStageMethod< Scalar > > msMethod)

TODO: Add time step control if the pde solver doesn't converge

Member Dumux::Experimental::MultiStageTimeStepper< PDESolver >::step (Variables &vars, const Scalar t, const Scalar dt)

: TODO: Add time step control if the pde solver doesn't converge

Member Dumux::FluidSystems::Base< ScalarType, Implementation >::getMainComponent (int phaseIdx)

Unfortunately we currently still have the assumption in some volume variables (e.g. 1pnc, 2pnc) that the main component index of a phase is equal to the phase index of that phase. This means changing this only works if the volume variables are written accordingly.

Member Dumux::FluidSystems::Brine< Scalar, H2OType >::binaryDiffusionCoefficient (const FluidState &fluidState, int phaseIdx, int compIIdx, int compJIdx)

TODO implement binary coefficients

Member Dumux::FluidSystems::Brine< Scalar, H2OType >::heatCapacity (const FluidState &fluidState, int phaseIdx)

TODO: The calculation of the isobaric heat capacity is preliminary. A better description of the influence of NaCl on the phase property has to be found.

Member Dumux::FluidSystems::Brine< Scalar, H2OType >::thermalConductivity (const FluidState &fluidState, int phaseIdx)

TODO: For the thermal conductivity of the phases the contribution of NaCl is neglected. This contribution is probably not big, but somebody would have to find out its influence.

Member Dumux::FluidSystems::BrineAir< Scalar, H2Otype, Policy >::thermalConductivity (const FluidState &fluidState, int phaseIdx)

TODO: For the thermal conductivity of the air phase the contribution of the minor components is neglected. This contribution is probably not big, but somebody would have to find out its influence.

Member Dumux::FluidSystems::BrineCO2< Scalar, CO2Table, H2OType, Policy >::heatCapacity (const FluidState &fluidState, int phaseIdx)

TODO Implement heat capacity for gaseous CO2

Member Dumux::FluidSystems::H2OAir< Scalar, H2Otype, Policy, useKelvinVaporPressure >::enthalpy (const FluidState &fluidState, int phaseIdx)

This system neglects the contribution of gas-molecules in the liquid phase. This contribution is probably not big. Somebody would have to find out the enthalpy of solution for this system. ...

Member Dumux::FluidSystems::H2OAir< Scalar, H2Otype, Policy, useKelvinVaporPressure >::heatCapacity (const FluidState &fluidState, int phaseIdx)

Check whether the gas phase enthalpy is a linear mixture of the component enthalpies and the mole fractions is a good assumption.

Member Dumux::FluidSystems::H2OAirMesitylene< Scalar, H2OType >::viscosity (const FluidState &fluidState, int phaseIdx)

Check the parameter phiCAW for the mesitylene case and give a physical meaningful name

Member Dumux::FluidSystems::H2OAirXylene< Scalar, H2OType >::viscosity (const FluidState &fluidState, int phaseIdx)

Check the parameter phiCAW for the xylene case and give a physical meaningful name

Member Dumux::FV3dPressure2P2CAdaptive< TypeTag >::update ()

maybe only do this if the grid changed

Member Dumux::GeometryIntersection< Geometry1, Geometry2, Policy, 2, 2, 2 >::intersection (const Geometry1 &geo1, const Geometry2 &geo2, Intersection &intersection)

implement this query

Member Dumux::GeometryIntersection< Geometry1, Geometry2, Policy, 3, 1, 1 >::intersection (const Geometry1 &geo1, const Geometry2 &geo2, Intersection &intersection)

implement this query

Member Dumux::GeometryIntersection< Geometry1, Geometry2, Policy, 3, 3, 2 >::intersection (const Geometry1 &geo1, const Geometry2 &geo2, Intersection &intersection)

implement overloads for segment or point-like intersections

Member Dumux::LinearPDESolver< Assembler, LinearSolver >::report (std::ostream &sout=std::cout) const

Implement some solver statistics output

Member Dumux::LoggingParameterTree::get (const std::string &key, const char *defaultValue) const

This is a hack so get("my_key", "xyz") compiles (without this method "xyz" resolves to bool instead of std::string)

Member Dumux::NewtonSolver< Assembler, LinearSolver, Reassembler, Comm >::solutionChanged_ (Variables &vars, const SolutionVector &uCurrentIter)

TODO: In case we stop support for old-style grid variables / assemblers at one point, this would become obsolete as only the update call to the backend would remain.

Member Dumux::NonEquilibriumFluidState< ScalarType, FluidSystem >::partialPressure (int phaseIdx, int compIdx) const

is this needed?

Class Dumux::Parameters

Doc me!

Member Dumux::PoreNetwork::SubGridData< HostGrid, SubGrid >::paramGroup () const

For now we don't support two different parameter groups for the subgrids

Member Dumux::PseudoOnePTwoCFluidState< ScalarType, FluidSystem >::partialPressure (int phaseIdx, int compIdx) const

is this needed?

Member Dumux::PseudoOnePTwoCFluidState< ScalarType, FluidSystem >::partialPressure (int compIdx) const

is this needed?

Member Dumux::RichardsLocalResidual< TypeTag >::addSourceDerivatives (PartialDerivativeMatrix &partialDerivatives, const Problem &problem, const Element &element, const FVElementGeometry &fvGeometry, const VolumeVariables &curVolVars, const SubControlVolume &scv) const

Maybe forward to problem for the user to implement the source derivatives?

Member Dumux::ShallowWaterFlux< NumEqVector >::flux (const Problem &problem, const typename FVElementGeometry::GridGeometry::GridView::template Codim< 0 >::Entity &element, const FVElementGeometry &fvGeometry, const ElementVolumeVariables &elemVolVars, const typename FVElementGeometry::SubControlVolumeFace &scvf)

The choice of the Riemann solver should be more flexible

Member Dumux::triangulate (const RandomAccessContainer &convexHull)

sort points and create polyline

Class Dumux::VtkMultiWriter< GridView, OutputValue >

This class can most likely be replaced by Dune::VTKSequenceWriter

File io/grid/gridmanager.hh

add Petrel grids with dune-cornerpoint