# Problem using `GeometryType::none`

If the function

`Dune::ReferenceElements<ScalarType, dim>::general`

is used it returns the object with topology id 0.
Thus, I witnessed the failure of several codes, such as
https://gitlab.dune-project.org/fufem/dune-fufem/-/blob/master/dune/fufem/boundarypatch.hh#L135,
or
https://gitlab.dune-project.org/staging/dune-functions/-/blob/master/dune/functions/functionspacebases/subentitydofs.hh#L70,

Though the behavior is that in 2D I pass in `GeometryType::none`

and get the reference element of topolgy ID 0, which is the triangle, in the subsequent code this fails due to multiple reasons.

The crucial code is https://gitlab.dune-project.org/core/dune-geometry/-/blob/master/dune/geometry/referenceelements.hh#L156, which hands out in https://gitlab.dune-project.org/core/dune-geometry/-/blob/master/dune/geometry/referenceelements.hh#L66 the element with the topology ID 0.

This is due to the default construction of the GeoemtryType in https://gitlab.dune-project.org/core/dune-geometry/-/blob/master/dune/geometry/type.hh#L244.

Thus, at several places, the type at hand should be checked with `isNone()`

. I prepared a pull request for dune-fufem, but before I pollute every code with my isNone checks, I wanted to discuss, if we can cure this here.

For example, in 2D, the handed-out ReferenceElement is the triangle. Thus, if we create a Reference element that returns something better, which e.g. does nothing or returns zero in the case of geometryType::none in https://gitlab.dune-project.org/core/dune-geometry/-/blob/master/dune/geometry/referenceelement.hh#L153. Then, it could be cured maybe for all implementations.

I don't know the impact on perfomance here. @simon.praetorius @oliver.sander do you have an opinion here?