Consider separating element template from field

[mclarsen]

Looking at a low order path, there is need to separate the element type from the field, but keep the template on polynomial order. The topology knows the element type and you can interpret the field based on that. The current implementation stores connectivity with the grid function, which has the benefit of not having to know about L2 versus H1. All that needs to be be done is read the connectivity. If we do indeed separate the two, we will need to deal with this.

[starintheuniverse]

If the field and topology have different polynomial orders e.g. 2nd order field and 5th order topology, and the connectivity is only stored in the topology, will the topology know how to interpret the data array of the field? It could work if we adopt an implicit ordering of shared dofs. Mfem does this. In order to follow suit we may have to understand what exactly mfem does for its convention(s).

[mclarsen]

@starintheuniverse I totally agree. On one hand, if we have 10 H1 fields of the same order, we are duplicating the connectivity, and on the other hand, if we have 10 H1 fields of different orders, its not clear who is responsible for managing all the different connectivities (could be the topology). Further, I don't know if we can have a non-shared dof that is in fact shared, i.e., its the same value but different memory locations. I think an implicit ordering is attractive, but it doesn't handle the fully unstructured case. Not sure what to do.

[mclarsen]

What we currently do, is more general and flexible, but uses more memory.