add member variable "name" to ParticleAttribute Base class

[klappi-s]

Added:

ParticAttribBase

• private member std::string name
• virtual getter and setter

ParticleAttrib:

• defined getter and setter override
• added default Constructor to set default name to "UNNAMED_attribute"

ParticleBase:

• Set default Names for ID and position in ParticleBase

Alpine:

• set names in alpine particle container constructor

[klappi-s]

dont merge yet, I realised I probably should change something

[biddisco]

General question - the kokkos::View has a label https://kokkos.org/kokkos-core-wiki/API/core/view/view.html#_CPPv4NK4View5labelEv would it make sens to simply use the view's label for the attribute (assuming the data is always available from a view somewhere)?

[klappi-s]

Yes, that could make sense, but I am not so sure how straight forward such an implementation would be. I looked into this a bit. The Kokkos::View label/name needs to be set during construction.
For PariicleAttrib we mainly use it's default constructor, so it's underlying Kokko::View dview_m is as well constructed via default, where no allocations are made.

Data is only allocated when we call

    void realloc(size_type n) { Kokkos::realloc(dview_m, n); }

for the attribute.

Kokkos doesn't seem to have a constructor that let's us set the name but on all matters else behaves like the default constructor (which is non allocating). I am not too experienced with Kokkos so I am not quite sure if we are allowed to use one of the standard allocating constructor to serve this purpose by just not passing any variables for it's extent?

template<class IntType>
View(const std::string &name, const IntType&... extents)

It sais it has the following requirement:

Requirements:
" sizeof(IntType...) == rank_dynamic() or sizeof(IntType...) == rank()
In the latter case, the extents corresponding to compile-time dimensions must match the View type’s compile-time extents. "
But since we are using Kokkos::realloc() soon afterwards I am not sure if this is relevant.

I tried this by defining constructors for ippl::ParticleAttrib and changing get_name():

        ParticleAttrib( ) : dview_m("UNNAMED_attribute"){}
        ParticleAttrib(const std::string& name) : dview_m(name){}
        
        ...
        template <typename T, class... Properties>
        std::string ParticleAttrib<T, Properties...>::get_name() const {return dview_m.label();  }

and using it in the constructor of particleBase and particleContianer:

template <class PLayout, typename... IP>
    ParticleBase<PLayout, IP...>::ParticleBase()
        : layout_m(nullptr)
        , localNum_m(0)
        , totalNum_m(0)
        , nextID_m(Comm->rank())
        , numNodes_m(Comm->size())
        , R("position")
        , ID("ID") {
        if constexpr (EnableIDs) {
            addAttribute(ID);
        }
        addAttribute(R);
        // ID.set_name("ID");
        // R.set_name("position");
    }



  ParticleContainer(Mesh_t<Dim>& mesh, FieldLayout_t<Dim>& FL)
        : pl_m(FL, mesh) 
        , P("velocity")
        , q("charge")
        , E("electric_field")
        {
        this->initialize(pl_m);
        registerAttributes();
        setupBCs();
    }

I shortly tested this on my current insitu-vis-steer branch running serial and this seems to work.
So if we are sure this is a safe use of the Kokkos::View standard constructors and we prefer this approach I can change this.

[aaadelmann]

use name_m

[aaadelmann]

What John mentioned is indeed the best solution. In have a feeling that in the interest of time (my SC milestone) we maybe do this in 2 steps: first the easy simple one with name_m and the later on the one with the view name.