DUNE-ACFEM (2.5.1)

Bug List
Class Dune::ACFem::BinaryModelExpression< MultiplyOperation, FactorFunction, ModelType >
Due to a bug in the ModelInterface the localFactor_ has to be tagged as "mutable".
Class Dune::ACFem::BinaryOperatorPartsExpression< MultiplyOperation, FactorFunction, OperandType >
Due to a bug in the OperatorParts the localFactor_ has to be tagged as "mutable".
Class Dune::ACFem::BoundaryIndicatorInterface< Implementation >
This should probably be changed in a way that there is only one classificator class per condition; complex operations with indicators could then be simplified at compile time (the classificators would be required to do the same if they belong to the same class). The BoundaryIdClassificator is one example ATM where this is NOT the case.
Class Dune::ACFem::DirichletBoundaryModel< GridFunction, Indicator >
ATM, the product of Indicator and GridFunction (which may already be a BoundarySupportedFunction) determine the part of the bounday subject to Dirichlet-conditions. This should perhaps be changed s.t. that only Indicator carries this information.
Member Dune::ACFem::EllipticEstimator< DiscreteFunctionSpace, Model, Norm >::estimateIntersection (const IntersectionType &intersection, const ElementType &inside, const LocalFunctionType &uInside, const ElementType &outside, const LocalFunctionType &uOutside) const
Rather a bug of the ModelInterface: ModelInterface.setEntity() should be replaced by a proper local operator-germ. Otherwise computing jump-residuals is too costly because we have to flip between inside and outside all the time.
Member Dune::ACFem::makeRestrictProlongDefault (const tuple< Rest &... > &arg)
Rather a remark: C++14 will add index-sequences which can be used to unpack tuples into template parameter packs.
Class Dune::ACFem::ModelInterface< ModelType >
The setEntity() method is evil, because it in principle prevents models from being tagged as "const", or is the reason for the evil use of the "mutable" keyword in several places. Way out would be an "OperatorGerm"-class which is constructed from a given entity and/or intersection.
Class Dune::ACFem::OperatorPartsInterface< PartsImpl >
The setEntity() method is evil, because it in principle prevents models from being tagged as "const", or is the reason for the evil use of the "mutable" keyword in several places. Way out would be an "OperatorGerm"-class which is constructed from a given entity and/or intersection.
Class Dune::ACFem::P_LaplacianOperatorParts< FunctionSpace >
This is totally untested. Cross check before using and then remove the comment.
Class Dune::ACFem::ParabolicEulerEstimator< OldSolutionFunction, TimeProvider, ImplicitModel, ExplicitModel >
The estimator reuses code from the EllipticErrorEstimator. We should somehow try to find some common base class for this.
Module GridFunctionExpressions
Expression templates for wrapped or adapted non-discrete functions have some potential to be inefficient because the local-to-global coordinate mapping potentially is evaluated too often. The WrapperExpressionOptimizations reduce this inefficiency by grouping adapted or wrapped non-discrete functions together. Another good idea would be to optionally cache the global coordinates for quadrature rules (like the values of the basis-functions are precomputed at quadrature points)
Member gridWalkTest (const ModelInterface< Model > &model, const DiscreteSpace &dfSpace)
Currently the flux- and source-methods are not evaluated and hence not instantiated.
Creative Commons License   |  Legal Statements / Impressum  |  Hosted by TU Dresden  |  generated with Hugo v0.80.0 (May 1, 22:29, 2024)