# Quad mesh nodes reordered upon reading XDMF file **URL:** \ **Category:** dolfinx\ **Created:** [March 23, 2022, 5:56pm UTC](https://fenicsproject.discourse.group/t/quad-mesh-nodes-reordered-upon-reading-xdmf-file/7902 "2022-03-23T17:56:44Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![dokken](https://yyz2.discourse-cdn.com/free1/user_avatar/fenicsproject.discourse.group/dokken/32/1560_2.png) [@dokken](https://fenicsproject.discourse.group/u/dokken)\ **Post date:** [March 23, 2022, 6:20pm UTC](https://fenicsproject.discourse.group/t/quad-mesh-nodes-reordered-upon-reading-xdmf-file/7902/2 "2022-03-23T18:20:27Z")
> [@aherrema](#): > > Is this expected behavior? Said re-ording appears to occur on a pretty large scale for more complex meshes, which makes it much more difficult (unnecessarily so?) to integrate FEniCS alongside/within other tools/workflows. Most software reorder meshes (the topology) (usually to be able to use higher order Nedelec/DG spaces, see for instance the introduction of: [[2102.11901] Construction of arbitrary order finite element degree-of-freedom maps on polygonal and polyhedral cell meshes](https://arxiv.org/abs/2102.11901)). However, in DOLFINx, we use dof-transformations (see said paper, which in theory means that you do not need to reorder the mesh topology). The re-ordering you see in the geometry, is to increase data-locality, see: [https://github.com/FEniCS/dolfinx/blob/23c76248f0686a795f170927036f1331416c1876/cpp/dolfinx/mesh/Geometry.cpp#L73-L105](https://github.com/FEniCS/dolfinx/blob/23c76248f0686a795f170927036f1331416c1876/cpp/dolfinx/mesh/Geometry.cpp#L73-L105) @garth or @chris can probably provide you with more information regarding this. It would be helpful to know what kind of software you would like to interface with, and how you were thinking about making this interface (if we do not consider the reordering of the geometry). --- _[View the full topic](https://fenicsproject.discourse.group/t/quad-mesh-nodes-reordered-upon-reading-xdmf-file/7902)._