#533 GenericReferenceElements are buggy
Metadata
| Property | Value |
|---|---|
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Apr 7, 2009 12:16 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Last edited at | May 7, 2009 10:57 |
| Closed by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Closed at | May 7, 2009 10:57 |
| Closed in version | Unknown |
| Resolution | Fixed |
| Comment | Christian fully implemented the singleton pattern. |
Description
The singelton GenericReferenceElements::general seems not to be defined anywhere.
Activity
Sven Marnach (sven@pantoffel-wg.de) commented on the issue:
This issue is really important. It is effectively impossible to use the new reference elements, and the old reference elements are incompatible with the current version of dune-localfunctions.
@Martin: Do you think you will find the time to fix this isuue very soon? If not, please say so!
-
Sven Marnach (sven@pantoffel-wg.de) commented on the issue:
As Carsten did before, I also tried to track this down by explicitly defining general like this:
#include "config.h"
#include<dune/grid/common/genericreferenceelements.hh> #include<dune/common/geometrytype.hh>template<class ctype, int dim> Dune::GenericReferenceElementContainer<ctype, dim> Dune::GenericReferenceElements<ctype, dim>::general;
int main() { Dune::GenericReferenceElements<double,2>:: general(Dune::GeometryType(Dune::GeometryType::simplex, 2)); }
This code results in several pages of compiler errors. For example, the constructors of GenericReferenceElementContainer and all its specializations are private, so these classes can't be constructed at all. There are many more issues, some of which I don't understand. Since there is no documentation for this part of the code, I don't feel up to fix these bugs. Obviously, this part of the code has never been even compiled.
In the doc of the (old, the new have none) reference elements the i-th subentity of codim c is denoted by (i,c), The call type(i,c) is supposed to return the type of the i-th subentity with codim c. If you look at the output that you introduced in the test this is exactly what it does. I.e. type(i,c) for a (simplex,d) is a (simplex, d-c). The new reference elements return always the type of the element itself and not of any subentity.
Now the type is OK. But the (implicitly) given orientation of subentities is different from the old orientation, e.g. for the 1st edge of (simplex,2). Thus we have in general for an element e and the corresponding GenericReferenceElement gref
e.geometry().corner(gref.subEntity(i,codim,j,dim)) != e.subEntity(i,codim).geometry().corner(j)
This can only be fixed sufficiently by keeping the old orientation in GenericReferenceElement. Reorienting the subentities would also require to change the geometry and thus the jacobian. Hence old and new numbering could no longer coexist.
We don't consider the different "orientation" a bug but rather a feature, since it is generated by a simple, generic algorithm. The change was also stated before we decided on the change, To make things more complicated, there is no documentation how the old "orientation" was generated, let alone a generic algorithm that extends to the n-dimensional simplex.
Furthermore, I don't actually see where this is already used (except the grid implementations). The Jacobian of the geometry transformation is not influenced by this. Actually a grid implementation with the generic subentity relations works perfectly (except for the grid check, of course).
If you want the old "orientation", you have to specialze the generic reference element (hence making it non-generic).
Oh - the consistency I assumed is just not given, thus whatever orientation is OK. The only use of the subEntity method in reference elements is to provide any subsubentity numbering since the grid entities can anyway not provide a consistenten subsubentity numbering. I'll make the orientation test optional again - it shows the orientation change which is not documented elsewhere.
mentioned in issue #834 (closed)
mentioned in issue #980 (closed)
mentioned in issue core/dune-grid#155
