## Support for unit types

I would like to propose a grid that can convert any of the known dune-grids into a grid that "uses" *unit safe types*. I could propose it here in an MR if you are interested or I can just create a module for it. However, there is a type in the dune-grid interface that can't be aligned with *unit safe types*: it is the return type of the method `volume()`

which is `ctype`

.

Say that `ctype`

represents the values of `\mathbb{R}`

. Then, all the methods that return values in other dimensions (e.g. `local()`

, `center()`

, etc.) are effectively converted into a tuple of the type of the `ctype`

. As is usual in dune, this concept is covered by the `FieldVector`

s so that `\mathbb{R}^d = \mathbb{R}\times ... \times \mathbb{R} =`

`FieldVector<ctype,d>`

. However, this does not happen with the volume which should be represented as the resulting type of the product of a `ctype`

value `d`

times. In c++, that is `using Volume = decltype(declval<ctype>()*...*declval<ctype>());`

.

There are two ways to fix this:

- Asking the implemented geometry to provide the type of the volume as is done for all the other types.

```
template< int mydim, int cdim, class GridImp, template< int, int, class > class GeometryImp >
class Geometry
{
// ...
typedef typename Implementation::Volume Volume;
// ...
};
```

- Although 1. is what makes more sense to an interface like dune-grid, I can imagine that it will break many codes downstream. So another possible implementation can be as follow:

```
template< int mydim, int cdim, class GridImp, template< int, int, class > class GeometryImp >
class Geometry
{
template<class ctype, int dim>
struct VolumeTypeHelper;
template<class ctype>
struct VolumeTypeHelper<ctype,1>
{
using type = ctype;
};
template<class ctype, int dim>
struct VolumeTypeHelper
{
using VolumeTypeCodim1 = typename VolumeTypeHelper<ctype,dim-1>::type;
using type = decltype(std::declval<ctype>()*std::declval<VolumeTypeCodim1>());
};
// ...
typedef typename VolumeTypeHelper<ctype,mydim>::type Volume;
// ...
};
```

- Yet a third alternative would be to combine the two options asking whether the implementation provides
`Volume`

definition.

Notice that even the jacobians do not assume anything about the underlying type.

So, please let me know if a change like this is possible and desirable. If so, I can push a MR with the corresponding alternative.