My noob random walk in the world of FEniCS/dolfinx has recently allowed me to generate 2D meshes with gmsh, which I then import with dolfinx.io.gmshio.read_from_mesh.I have even managed to get PyVista up and running inside my jupyter notebook.
However, when I recently tried to use a 2D mesh with a mixture of (2nd order) tri and quad elements, read_from_mesh stopped and complained. The code comment at the point of the assert(in gmshio.py), states that “Assumes that each entity only have one cell-type“.
So, is it just read_from_mesh which cannot handle this, or is this a limitation of, say, the implementation of the function spaces? That is, can I hope for a workaround, or should I keep my paws away from mixed meshes?
The GMSH interface does not support reading in mixed cell meshes (yet). There is experimental support for these meshes in DOLFINx, see for instance: Poisson equation — DOLFINx 0.10.0.post0 documentation
but the API is subject to change and is not super-clean at the moment.
Following up on this since it’s been about a year — has the situation around mixed-topology meshes (demo_mixed-topology) become more stable in the meantime, or is the API still considered experimental/subject to change?
I’m asking somewhat generally/in advance: I’m planning a FEniCSx-based post-processing pipeline that needs to work across a number of pre-computed CFD cases (looking at surface roughness effects), and these cases come from different sources/solvers. I haven’t fully audited each mesh yet, so I don’t know for certain whether any of them mix element types within a single mesh (e.g. tets + hexes, or tris + quads) versus just differing in element type from one case to the next — but I want to know upfront whether designing around possible mixed-topology meshes is realistic right now, or whether I should just plan to homogenize/split each mesh to a single cell type as a preprocessing step regardless.
So, a few questions:
Is dolfinx.mesh.create_mesh with multiple cell types (built manually, not via Gmsh/gmshio) stable enough now to build a general-purpose pipeline on top of, or still mainly proof-of-concept / likely to change API-wise?
Does dolfinx_mpc (periodic constraints) currently support mixed-topology meshes at all, or is that combination untested/unsupported?
More generally — if I do end up with mixed element types in some cases, would you currently recommend just splitting everything down to a single cell type (e.g. quads/hexes → triangles/tets) as the safer default, rather than relying on native mixed-topology support?
Mainly trying to figure out whether it’s worth designing the pipeline to natively support mixed meshes, or whether homogenizing per-case up front is still the more robust path.
The API for creating meshes for mixed topology has stabilized more, and the dolfinx.mesh.Mesh class has been rewritten in 0.11 to have a unified way of accessing properties of mixed topology grids. See for instance: Release notes — DOLFINx Python 0.11.0.post0 for an overview of the improved feature set.
There are also support for mixed topology output, see: Release notes — DOLFINx Python 0.11.0.post0
