QuadratureRuleFactory are cleaned up in style, using static map for storing rules and modern enum classes. The quadrature rules are put into a common programming style, e.g. no intermediate point/weight construction, but directly storing coefficients in the quadrature rule.
Four major changes are introduced in this MR:
- Quadrature rules (points and weights) are constructed directly and not via an intermediate c-array.
- The quadrature rules are stored in a cache in form of a
thread_local std::map. This allows to easily extend the key types (currently to topology-id, the quadrature order and quadrature type). In some initial tests there was no performance different measurable. It could be discussed whether it would be better to use a
static std::map+ locking, or whether another map, like an
std::unordered_mapwould be the better choice.
QuadratureTypeenum is now an
enum class. This might be a breaking change in some use-code, if the quadrature type is stored somewhere. Needed changes in user code: replace
- Instead of repeating all quarature points and weights for flating-point numbers and for string construction, a utility function/macro
DUNE_NUMBER -> Dune::Impl::numberis introduced to cover both cases at once. The macro takes a type and a floating-point literal and expands the latter into a
const char*. In the
Dune::Impl::numbertemplate, it is then decided whether to construct from a string or returning the double value directly.
This is the second step of a cleanup and redesign of the quadrature rules: 1.) put all rules into a similar structure. 2.) cleanup of the classes QuadratureRules and QuadratureFactory, 3.) Automatically generate coefficients for all rules with higher precision
The implementation intends to establish a common style that can be generated automatically in step 3 from a database.
The simplexquadraturerule is transform from the old code using the attached python convert_rule.py and some postprocessing.