get/set tags with Topo_type vs dimension (integer) about omega_h

[jacobmerson]

@joshia5 I understand that there is a different set of functions when using topo_type or the dimension. What I'm saying is that is very surprising from the API perspective. As a user the only way that you would know this is by reading the code.

Do you have a lot of users using mixed meshes? It would probably make sense to break the mixed mesh functionality into a separate class since the current state is two orthogonal ways of working with the data mashed into a single class.

If you have only a few internal users for that functionality making some changes may be feasible and I can propose something.

Just bringing stuff up as I find it that catches me up. I'm open to discussion here.

[joshia5]

The storage/retrieval of tags for mixed meshes works based on topology type. It is not based on dimension. Following are the enum associated with the topo types:

enum class Topo_type : int { vertex, edge, triangle, quadrilateral, tetrahedron, hexahedron, wedge, pyramid };

[joshia5]

There are different query/storage functions for mixed mesh which accept topo_type as argument. For example if a tag is requested on entities of type "quadrilateral" it will return the tags that were set on quads only

[joshia5]

sounds good.. afaik i don't think I have active users right now for the mixed mesh. I am open to discussions on improving the api design

[joshia5]

I think some level of support at the back-end exists for such an API to deal with tags for mixed mesh and transforming tag data between Topo_type and dimension. It was developed to support file i/o for vtk files. The missing link would be the APIs to get/set tags that are exposed to the user.

[cwsmith]

resolved with #82