In most of our current algorithms we (implicitely) know what type of primitive we are dealing with, i.e. whether we are working on a
Vertex. This largely results from the fact that we ask a
PrimitiveStorage object to provide us with all local primitives of a certain type, e.g. via
Still to me it feels strange that we can neither query an object of type
Primitive to obtain its type, nor that this is encoded in its associated
PrimitiveID. There are some situations, where we might not (implicitely) know what kind of primitive we are dealing with. An example at the moment would be the migration of primitives between MPI processes. As a consequence of this the
PrimitiveStorage class defines its own
PrimitiveTypeEnum and provides a
getPrimitiveType() method, which, presented with a
PrimitiveID will return the type of the primitive, if this is either present locally, or in the immediate neighbourhood. If not, it will return
The idea of this MR is to equip the
Primitive class itself with a
PrimitiveTypeEnum type that only has the values
VERTEX and a pure virtual function
Primitive::getType() that can be used to query this. The latter is then easily implemented in the child classes.
The MR preserves
PrimitiveStorage::PrimitiveTypeEnum, because I did not want to add a special situation
INVALID enum to
Primitive::PrimitiveTypeEnum. The former quasi extends the latter, based on fixed int values, so that we can cast the former into the latter.
That feels not ideal, but I am too unfamiliar with the details of primitive migration to understand, why we might want to send a nullptr together with an
INVALID from one process to another, to change that.