meshio++

Appearance

Format conformance ​

What every writable format keeps when meshio++ writes a file and reads it back. One canonical mesh — one cell of each linear type, float64/int32/vector point data, float64/int32 cell data, field data and one point, cell and side region — goes through write and read for each format, and the observed result must match the declaration in tests/python/conformance_spec.py exactly: tests/python/test_conformance.py fails when a format starts losing something or starts keeping something, so this page cannot drift from the code. It is generated by tools/gen_conformance_table.py; do not edit it by hand.

The per-format pages say why something is lost; this page says what. Region membership is checked in depth by the region round-trip matrix, and node-ordering by node ordering.

Legend ​

  • Cell columns: ✓ the cell comes back node for node; ↻ the same nodes in another order; → types written as other cells (a quad as two triangles, a volume as its skin); ✗ silently dropped when written next to the other types; blank: the writer refuses the type on its own.
  • Points: exact; approx (within 1e-6, single precision); 2d (z dropped); subset (the points of dropped cells are gone, the rest exact); none (a format with no geometry); changed.
  • Point data / cell data: the arrays that come back, with the dtype read (~: values only approximately equal; ?: shape or values changed). p_f64/c_f64 are float64, p_i32/c_i32 int32, p_vec a float64 3-vector.
  • F: the field-data array fd survives. Regions: the kinds (point, cell, side) whose region comes back under its own name.

Matrix ​

FormatvtxlinetriquadtethexwdgpyrPointsPoint dataCell dataFRegions
abaqus✓✓✓✓✓✓exact———cell, point, side
ansys✗✗↻↻✓✓exact———cell
ansysInp✓✓✓✓✓✓✓✓exact———cell, point
avsucd✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 float64, p_vec float64c_f64 float64——
cae✗✗→ tri→ tri→ tri→ trisubset————
cgns✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 float64, p_vec float64———
code_aster✓✓✓✓✓✓✓✓exact———cell, point
dex✗✗✗✗✗✗✗✗exactp_f64 float64———
dolfin-xml✗✓exactp_f64 float64, p_i32 int64c_f64 float64, c_i32 int64——
elmer✓✓✓✓✓✓✓exact———cell
ensight✓✓✓✓✓✓✓✓approxp_f64 float64, p_i32 float64, p_vec float64c_f64 float64, c_i32 float64——
exodus✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 int32, p_vec float64c_f64 float64, c_i32 int32—cell, point
febio✓✓✓✓✓✓✓exactp_f64 float64, p_i32 float64, p_vec float64c_f64 float64?, c_i32 float64?—cell, point, side
femap✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 float64c_f64 float64, c_i32 float64—cell, point
flac3d✓✓✓✓↻✓exact————
flux✓✓✓✓✓✓✓✓exact————
freefem✓✓exact————
gid✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 float64, p_vec float64c_f64 float64, c_i32 float64——
gltfwrite-only
gmsh????????fails: WriteError
gmsh22✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 float64, p_vec float64c_f64 float64, c_i32 float64✓cell
h5m✓✓✓exactp_f64 float64, p_i32 int32, p_vec float64———
hmf✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 int32, p_vec float64c_f64 float64, c_i32 int32——
ip✗✗✗✗✗✗✗✗exactp_f64 float64, p_i32 float64———
libmesh✓✓✓✓✓✓✓✓exact———cell, point, side
lsdyna✓✓✓✓✓✓✓✓exact———cell, point, side
mdpa✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 float64, p_vec float64———
med✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 int32, p_vec float64c_f64 float64, c_i32 int32—cell, point
medit✓✓✓✓✓✓✓exact————
mfem✗✓✓✓✓✓✓exact———cell
mff✗✗✗✗✗✗✗✗none————
mfm??????fails: WriteError
mphbin✓✓✓✓✓✓✓✓exact———cell
mphtxt✓✓✓✓✓✓✓✓exact———cell
nastran✓✓✓✓✓✓✓✓exact———cell
netgen✓✓✓✓✓✓✓✓exact————
neuroglancer✓exact————
obj✓✓exact————
off✓✓exact————
openfoam↻↻✓✓exact———cell, point, side
patran✓✓✓✓✓✓✓exact———cell, point
pcd✓→ vtx→ vtx→ vtx→ vtx→ vtx→ vtx→ vtxapproxp_f64 float64, p_i32 int32, p_vec float64———
permas✓✓✓✓✓✓✓✓exact————
ply✗✗✗✗→ tri→ quad→ quad+tri→ quad+trisubset————
pmsh✗✗✗✗✓→ tet→ tet→ tetapproxp_f64 float64, p_i32 int32, p_vec float64c_f64 float64, c_i32 int32✓—
pvd✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 int32, p_vec float64c_f64 float64, c_i32 int32✓—
pvtp✓✓✓✓exactp_f64 float64, p_i32 int32, p_vec float64c_f64 float64, c_i32 int32✓—
pvtu✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 int32, p_vec float64c_f64 float64, c_i32 int32✓—
stl✗→ tri→ tri→ tri→ trisubset————
su2✓✓✓✓✓✓exact————
svgwrite-only
tecplot✓✓✓✓✓→ hex→ hexexactp_f64 float64, p_i32 float64c_f64 float64, c_i32 float64—cell
tetgen✓exact————
tikzwrite-only
triangle✓exact————
ugrid✓✓✓✓✓✓exact————
unv✓✓✓✓✓✓✓exactp_f64 float64, p_i32 float64, p_vec float64c_f64 float64, c_i32 float64—cell, point
usd✗✗→ tri→ quad→ quad+tri→ quad+trisubset————
vtifails: no cell type round-trips
vtk✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 int32, p_vec float64c_f64 float64, c_i32 int32——
vtk42✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 int32, p_vec float64c_f64 float64, c_i32 int32——
vtk51✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 int32, p_vec float64c_f64 float64, c_i32 int32——
vtkhdf✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 int32, p_vec float64c_f64 float64, c_i32 int32✓—
vtm✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 int32, p_vec float64c_f64 float64, c_i32 int32——
vtp✓✓✓✓exactp_f64 float64, p_i32 int32, p_vec float64c_f64 float64, c_i32 int32✓—
vtrfails: no cell type round-trips
vtsfails: no cell type round-trips
vtu✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 int32, p_vec float64c_f64 float64, c_i32 int32✓—
wkt✓exact————
xdmf✓✓✓✓✓✓✓✓exactp_f64 float64, p_i32 int32, p_vec float64c_f64 float64, c_i32 int32——
xyz✓→ vtx→ vtx→ vtx→ vtx→ vtx→ vtx→ vtxexactp_f64 float64, p_i32 float64———
z88✓✓✓exact———cell, point
zarr✗✗✗✗✓→ tet→ tet→ tetapproxp_f64 float64, p_i32 int32, p_vec float64c_f64 float64, c_i32 int32✓—

Notes ​

  • ansys: A Fluent mesh stores volume cells and the faces that bound them; lower-dimensional cells that are not boundary faces of a volume cell are dropped with a warning.
  • cae: The physics-ML .npz stores the surface of the volume cells.
  • dex: DEX stores one nodal field over a node set: cells are not kept.
  • gltf: Written for viewers; meshio++ reads glTF only as the scene it wrote, not as a mesh round trip.
  • gmsh: The Gmsh 4.1 writer needs gmsh:dim_tags point data to place more than one cell type into entities, and refuses a mixed mesh without it; gmsh22 writes the same mesh.
  • ip: An integration-point cloud: points and nodal values, no cells.
  • mff: A field without geometry: one array of values, no points or cells.
  • mfm: MFM holds one element type per file, so the mixed canonical mesh is refused; each type alone round-trips.
  • pcd: A point cloud: every node is kept as a vertex, cells are not.
  • ply: PLY stores faces: volume cells are written as their skin.
  • pmsh: The physics-ML mesh stores tetrahedra: other volume cells are simplexified, and non-volume blocks dropped.
  • stl: STL stores triangles: volume cells are written as their skin, and other blocks are dropped when volume cells are present.
  • svg: A 2-D drawing, write-only.
  • tecplot: Tecplot has no wedge or pyramid zone type: both are written as degenerate bricks and come back as hexahedra.
  • tikz: A 2-D drawing, write-only.
  • triangle: Triangle reads and writes 2-D triangulations only, so this row is observed on the planar part of the canonical mesh.
  • usd: A UsdGeom mesh stores faces: volume cells are written as their skin.
  • vti: ImageData holds one regular hexahedral lattice; the canonical mesh is not one (VTI).
  • vtr: RectilinearGrid holds one axis-aligned lattice; the canonical mesh is not one.
  • vts: StructuredGrid holds one curvilinear lattice; the canonical mesh is not one.
  • xyz: A point cloud: every node is kept as a vertex, cells are not.
  • zarr: As pmsh: tetrahedra only, other volume cells simplexified.

Released under the MIT License.

meshio++ contributors