dune-localfunctions issueshttps://gitlab.dune-project.org/core/dune-localfunctions/-/issues2023-09-19T15:05:29Zhttps://gitlab.dune-project.org/core/dune-localfunctions/-/issues/22Thread safety.2023-09-19T15:05:29ZRobert KThread safety.It seems that the evaluation of shape functions is not thread safe. Is this something that can be fixed easily?It seems that the evaluation of shape functions is not thread safe. Is this something that can be fixed easily?Santiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/core/dune-localfunctions/-/issues/20Raviart Thomas 0 for 3D is only for tetrahedron2023-08-30T13:48:18ZSantiago Ospina De Los Ríossospinar@gmail.comRaviart Thomas 0 for 3D is only for tetrahedronI just want to point out that the current `RT03DLocalFiniteElement` seems to be miss-named. All the other RT elements follow the convention of `RT<order><geo><dim>DLocalFiniteElement` and something similar for the header names. The name ...I just want to point out that the current `RT03DLocalFiniteElement` seems to be miss-named. All the other RT elements follow the convention of `RT<order><geo><dim>DLocalFiniteElement` and something similar for the header names. The name chosen for the tetrahedron case does not follow this pattern so is a bit misleading.Santiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/core/dune-localfunctions/-/issues/16Cleanup LagrangeSimplexLocalCoefficients2019-08-27T07:31:10ZCarsten Gräsergraeser@math.fau.deCleanup LagrangeSimplexLocalCoefficientsThe implementation of `LagrangeSimplexLocalCoefficients` is very cluttered and inconsistent:
* [ ] Construction from permutation needlessly throws for dim=1.
* [ ] Text of thrown exceptions is misleading or incorrect.
* [ ] For dim>3 co...The implementation of `LagrangeSimplexLocalCoefficients` is very cluttered and inconsistent:
* [ ] Construction from permutation needlessly throws for dim=1.
* [ ] Text of thrown exceptions is misleading or incorrect.
* [ ] For dim>3 compile time failure should be preferred.
* [ ] Code duplication for dim=2: Constructor from permutation uses ´generateLocalKeys()` while default constructor is implemented separately.
* [ ] `LocalKey` generation for dim=1,dim=2,dim=3 are spread over multiple methods, dim=2 and dim=3 are implemented very differently.
* [ ] `LocalKey` generation code is completely undocumented. While dim=2 is easy to understand, this is not true for dim=3.
* [ ] `generateLocalKeys()` needlessly takes a its `std::array` argument by value.
* [ ] Ordering/position of Lagrange points is not documented.
* [ ] `LocalKey` ordering of surface DOFs is not documented.
* [ ] Semantics of permutation interface is not documented property:
* [ ] Is `vertexMap` a forward or backward permutation?
* [ ] How do the obtained finite elements differ?
* [ ] Which invariants (per-subentity `LocalKey` ordering) are guaranteed?
* [ ] This should also be documented in the `LocalSimplexFiniteElement`
Some of these are easy to fix. However, most need a deeper look into the code, maybe some refactoring of the 3d code, and careful testing.https://gitlab.dune-project.org/core/dune-localfunctions/-/issues/14Generic finite element implementations rely on undefined behaviour2022-09-23T13:11:09ZCarsten Gräsergraeser@math.fau.deGeneric finite element implementations rely on undefined behaviourAll 'generic' finite element implementations, i.e., those building up on the infrastructure in `dune/localfunctions/utility/` make heavy use of `reinterpret_cast` breaking strict aliasing rules.
As a consequence evaluation of the basis f...All 'generic' finite element implementations, i.e., those building up on the infrastructure in `dune/localfunctions/utility/` make heavy use of `reinterpret_cast` breaking strict aliasing rules.
As a consequence evaluation of the basis functions leads to undefined behaviour.
For those not aware of strict aliasing errors: A typical manifestation of this is, that optimized code may silently compute wrong numbers in special cases because the compiler makes wrong assumptions on when to sync register values with memory.https://gitlab.dune-project.org/core/dune-localfunctions/-/issues/10doxygen documentation is currently toatally useless2018-04-20T06:22:39ZChristian Engwerdoxygen documentation is currently toatally uselessThe doxygen documentation was cleaned up in order to hide unnecessary information, but now it hides nearly all information.
It provides a list of finite element implementations, but there is no documentation of classes like LocalKey or ...The doxygen documentation was cleaned up in order to hide unnecessary information, but now it hides nearly all information.
It provides a list of finite element implementations, but there is no documentation of classes like LocalKey or LocalBasis. At least it very hard to find it starting from the module page.https://gitlab.dune-project.org/core/dune-localfunctions/-/issues/6Provide dynamic information of derivatives implemented by `partial()'2017-12-03T03:06:18ZCarsten Gräsergraeser@math.fau.deProvide dynamic information of derivatives implemented by `partial()'When we needed the number of implemented partial derivatives statically for `evaluate()` this was encoded in the enum `diffOrder`. Since the static interface of the new `partial()` method is independent of this number, we should provide ...When we needed the number of implemented partial derivatives statically for `evaluate()` this was encoded in the enum `diffOrder`. Since the static interface of the new `partial()` method is independent of this number, we should provide this information dynamically. To this end I propose to introduce the method
```cpp
bool hasPartial(usigned order) const
```
returning true if _all_ partial derivatives up to the given order are implemented. By not returning the max-order itself, this allows to implement an arbitrary number. If we want to provide refined information in case only some derivatives are implemented, we may also provide
```cpp
bool hasPartial(const std::array< unsigned int, dim> &order) const
```
to check for an individual partial derivative. While the latter alone would already provide all information it's cumbersome to use. Hence this is only a possible add-on in case someone has a use case (I'm currently not aware of one).