-
-
Notifications
You must be signed in to change notification settings - Fork 398
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
inconsistent cell type names #630
Comments
The current cell type names are not completely insane since they follow the VTK convention right? |
Ah, indeed. 😄 It's still inconsistent though. I'll add another voting option for keeping the naming. |
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 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.. |
But the femtable is for finite elements in the sense of Ciarlet...in meshio we are only interested in their geometrical shapes. |
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 |
...Yes...but if we pursue further in this direction
Note however that currently
|
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? |
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. |
How's that? Cell data of shape (number of cells, number of nodes per cell)? |
Yes that's correct. |
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). |
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. |
Agreed. A thought for that future, following the idea that ‘recording information in strings is not Pythonic’: |
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. |
@flutefreak7 Fixed in #1002. |
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)
The text was updated successfully, but these errors were encountered: