Skip to content

Allow asking a Primitive for its type

Marcus Mohr requested to merge mohr/primitiveType into master

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 Cell, Face, Edge or 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 PrimitiveStorage::getFaces().

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 INVALID.

The idea of this MR is to equip the Primitive class itself with a PrimitiveTypeEnum type that only has the values CELL, FACE, EDGE and 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.


Merge request reports