meshio
meshio copied to clipboard
nschloe
polyMesh
Wishlist stub for a new format to support: OpenFOAM's polyMesh.
By default OpenFOAM defines a mesh of arbitrary polyhedral cells in 3-D, bounded by arbitrary polygonal faces, i.e. the cells can have an unlimited number of faces where, for each face, there is no limit on the number of edges nor any restriction on its alignment. A mesh with this general structure is known in OpenFOAM as a polyMesh.
Having arbitrary polyhedral cells bounded by arbitrary polygonal faces is not a great fit for meshio, but in practice many meshes consist purely of hexahedra bounded by quadrilaterals (e.g. those built with blockMesh) so even supporting just that subset might be worthwhile.
Given the importance of OpenFOAM in contemporary computational fluid mechanics, it's a mesh format that often has to be dealt with; e.g. for coupling OpenFOAM with finite element solvers. As mentioned in #555, I've done a bit of this (unpublished) in pyparsing (which is expressive but slow) but it might be worth porting to meshio and sharing.
OpenFOAM does provide a foamToVTK utility which is often used to view results in ParaView &c.; it's output might be a helpful guide in developing a meshio polyMesh module.
Totally upvote for this. As I understand it, the OpenFOAM mesh is not just composed of one file but a folder of files: nodes, cells, faces...
Yes. In the top directory of an OpenFOAM ‘case’ not involving dynamic meshing, the polyMesh is stored in the directory constant; e.g.
tree constant/polyMesh
gives
constant/polyMesh/
├── boundary
├── cellZones
├── faces
├── neighbour
├── owner
└── points
points are nodes and isomorphic to meshio.Meshio.points but rather than then defining the highest-dimensional (i.e. three-dimensional, polyMesh is always three-dimensional) cells in terms of their support by those points, it defines the faces as (possibly skew?) polygons in terms of a sequence of indices into points. Then the polyhedral cells are defined implicitly by the files owner and neighbour. All faces have an ‘owner’ cell but only internal faces also have a ‘neighbour’ cell. The numbers of faces and internal faces are recorded inside a string tagged note in both these files.
Subdomains are defined in constant/polyMesh/cellZones as a list of zones, each with a name and a list of indices of cells. I imagine that this will map to meshio.Mesh.cell_sets but I haven't had to deal with subdomains yet myself.
Boundaries are defined in a list in boundary in terms of uints startFace and nFaces. So I guess the faces constituting each boundary ‘patch’ have to be contiguous. These don't map directly to anything in meshio as we don't yet have a concept of facets—all Mesh.cells are defined in terms of Mesh.points, never each other—although there was a tantalizing comment from @nschloe 2020-01-07 in #615: ‘I think it makes sense to first think about tags/sets because this is what a "boundary" is.’ Perhaps one follows Gmsh in creating lower-dimensional cells (e.g. 'quad') for those faces that aren't internal faces and belong to a boundary patch and then supporting both the domain cells and boundary cells independently on the common array of points?
Data is kept outside the constant/polyMesh tree. Data is generally cell-based, for the three-dimensional cells. Data for initial conditions and solutions appears in directories numbered according to time, usually 0 for the initial condition, next to constant in the top-level directory. One might see:
tree 0
give something like
0
├── p
└── U
for the pressure and velocity in a Navier–Stokes problem. These cell-data files are usually complicated by the specification of boundary conditions, but I suppose meshio can ignore that or if two-dimensional cells are defined for the noninternal faces, they might be assigned to them somehow.
To begin with, the data might be ignored and just the mesh attempted. I would also suggest assuming and asserting to begin with that all faces are 'quad' and all cells 'hexahedron' as this is both such an important special case and one that best fits meshio.
This would make my life SOOOO much easier, right now I am trying to use Meshio to convert another SimScale mesh download (an .h5m fmesh file which OpenFoam will not run 'checkmesh' on) so that OpenFoam can run 'checkmesh on the converted file and I have not been successful yet.
I just created an issue here about that conversion problem, but it would be great if Meshio could convert to/from both mesh file types that can be downloaded from SimScale.
A BIG +1 for a direct support of OpenFOAMS's polymesh format.
Who really enjoy to use utilities to convert from/to other formats, conversion is just a pain in the ass especially if you deal with large meshes.
As mentioned earlier OpenFOAM is nowadays unmissable in the CFD landscape: a direct support of its polymesh format will greatly enhance the visibility of meshio and make users more and more attracted to it.
Many of the formats managed by meshio also have existing conversion tools. Why forget OpenFOAM rather than another one when it is precisely now widely recognized as the open source CFD standard ... that would be a tactical misstep.
Yes. One of the hurdles is that having
arbitrary polyhedral cells bounded by arbitrary polygonal faces is not a great fit for meshio
but that might be solved by extension to the Mesh class attributes proposed in the discussion of the vtu polyhedra #916.
@nschloe what's the best way to start implementing a new format ? Sorry I'm new to meshio.
hello, by any chance any progress in the addition of the polymesh format to meshio? thanks in advance, @nschloe In case that you are interested in adding it at one time in the future, please have a look at this script at least it could help https://github.com/EastEriq/salomeToOpenFOAM best regards
Yes. One of the hurdles is that having
arbitrary polyhedral cells bounded by arbitrary polygonal faces is not a great fit for meshio
but that might be solved by extension to the
Meshclass attributes proposed in the discussion of the vtu polyhedra #916.
Another file format that supports this kind of mesh is OpenVolumeMesh .ovm, there's some mismatches in representation I touched on here: https://github.com/nschloe/meshio/pull/1391
Hope we can find some solution :)
