inconsistent cell type names

[nschloe]

The naming of cell types in meshio is inconsistent. Perhaps we can fix that now.

Abbreviated:
quad*, tetra*,

Not abbreviated:
all the rest

Needless underscores:
hexa_prism, penta_prism

Edit: As pointed out by @tianyikillua, this pretty much follows the VTK convention.

Should we use abbreviations throughout or the full form? Vote now. (Heart ❤️ for abbreviations, rocket 🚀 for full form. Eyes 👀 : Keep what we have)

[tianyikillua]

The current cell type names are not completely insane since they follow the VTK convention right?

[nschloe]

Ah, indeed. 😄

It's still inconsistent though. I'll add another voting option for keeping the naming.

[gdmcbain]

Right, I wondered whether there might be some existing convention that might be followed (VTK, EXODUS, femtable.org). So the current strings are based on VTK. That makes sense, or rather doesn't as it's inconsistent, as you say.

An orthogonal idea: recording information in strings is not Pythonic. Why not use objects for cell-types? Constant (or at least predefined) instances of a class CellTyoe. That way type-checkers can make more sense of code, IDEs can provide tab-completion and hover-documentation, and relevant data can be flexibly extensibly carried by the thing indicating the cell type (dimension, number of nodes, representation in other systems, ASCII-art depictions of canonical orientation, …).

As for the names of the predefined cell-types, I'll suggest adding femtable to the list of candidates but won't vote just yet..

[tianyikillua]

But the femtable is for finite elements in the sense of Ciarlet...in meshio we are only interested in their geometrical shapes.

[gdmcbain]

Good point. Thank you, and for the reference.

But, I wonder, are we indeed only interested in their geometrical shapes? What about the data that's currently stored in node_data and cell_data? Isn't that more appropriately associated with the degrees of freedom of a finite element space?

[tianyikillua]

...Yes...but if we pursue further in this direction

1. we will be reinventing a new finite element data format...
2. the project name should be changed! It is currently mesh-io and not fem-io.

Note however that currently

• isoparametric fields (P1, P2, ...) are naturally supported since the number of nodes (including mid-nodes) correspond to that of the DoF's (scalar functions), as a point_data. Super- and sub-parametric fields no.
• DG0 (constant per cell) and DG1 (independently defined at the nodes of each cell) fields are also supported.

[gdmcbain]

Very interesting. Thank you.

But then is the conclusion that data (defined on a finite element space) should stored separately from the mesh, outside meshio?

[tianyikillua]

A mesh data is not necessarily a finite element data (the reverse is, on the other hand, true). We only provide the values at these discrete points (for point data), and let the users to decide how to interpret them and how to interpolate them.

[gdmcbain]

DG1 (independently defined at the nodes of each cell) fields are also supported

How's that? Cell data of shape (number of cells, number of nodes per cell)?

[tianyikillua]

Yes that's correct.

[gdmcbain]

On reflection, the femtable names aren't very readable anyway; I'll withdraw that suggestion. Also the table doesn't cover the vertex or the degenerate cells (wedges & pyramids).

[nschloe]

Okay, there is little interest and no actual consensus on the names here, so let's leave them as they are for now and remember our VTK heritage. 👻

Perhaps we'll come back to this at some point in the future.

[gdmcbain]

Agreed.

A thought for that future, following the idea that ‘recording information in strings is not Pythonic’: class enum.Enum.

[flutefreak7]

I just noticed that if I open an XDMF with pyramid elements, the ansys writer throws an error because it's expecting "pyra" instead of "pyramid." Not sure where the fix should be, but I fixed it by adding "pyramid" to the ansys writer cell type dict.

[nschloe]

@flutefreak7 Fixed in #1002.