messy and hardcoded types in alias defintions in datatypes.h

[klappi-s]

1

In src/manager/datatypes.h we have leftover code inherited form the old alpine/ExamplesWithoutPicManager/chargedparticles.hpp, where an alias for a partially specialized ippl::field template with hardcoded type double is set.

This should be avoided:

template <typename T, unsigned Dim = 3, class... ViewArgs>
using Field = ippl::Field<T, Dim, Mesh_t<Dim>, Centering_t<Dim>, ViewArgs...>;

template <unsigned Dim, class... ViewArgs>
using Field_t = Field<double, Dim, ViewArgs...>;

template <typename T = double, unsigned Dim = 3, class... ViewArgs>
using VField_t = Field<Vector_t<T, Dim>, Dim, ViewArgs...>;

2

Further the template defaults and the use of the subscript _t in the whole file seem to be somewhat inconsistent...

3 minimal fix preposition:

Create meaningful distinction between Field and Field_t and Vector and Vector_t, we could include default template specialisations for aliases with subscript _t similar to the different other aliases in datatypes.h:

e.g:

template <typename T, unsigned Dim >
using Vector = ippl::Vector<T, Dim>;

template <typename T = double, unsigned Dim = 3>
using Vector_t = ippl::Vector<T, Dim>;

template <typename T, unsigned Dim, class... ViewArgs>
using Field = ippl::Field<T, Dim, Mesh_t<Dim>, Centering_t<Dim>, ViewArgs...>;

template <typename T=double, unsigned Dim=3, class... ViewArgs>
using Field_t = Field<double, Dim, ViewArgs...>;

template <typename T = double, unsigned Dim = 3, class... ViewArgs>
using VField_t = Field<Vector_t<T, Dim>, Dim, ViewArgs...>;

3.1

good -> with this the use in our examples in alpine, cosmology etc with Field_t<3> should still be valid?
bad -> need to check we don't rely on default of alias of Field<T, Dim=3>
(+ maybe issue deprecation warning of default? )

template <typename T, unsigned Dim = 3, class... ViewArgs>
using Field = ippl::Field<T, Dim, Mesh_t<Dim>, Centering_t<Dim>, ViewArgs...>;

4 in General

create "uniform meaning" for the use of _t in type aliases and maybe extend this concept further tothe other type aliases...