Skip to content

Retrieve NFace from NGon/ParentElements when reading CGNS meshes

couletj requested to merge (removed):cgnsreader_ngons into master

This merge request introduces a new feature regarding the load of the cells from a CGNS file.

Background

CGNS volumic elements can be described using one of the two following methods:

  • providing a list of typed elements (tetra, hexa, etc.) with their cell-to-vertex connectivities;
  • providing a list of arbitrary polygons (called NGON_n) defined by a face-to-vertex connectivity, together with a list of polyhedral (called NFACE_n) defined as a list of faces (cell-to-face) connectivity.

These two ways are mutually exclusive. In addition, the CGNS norm allows an additional data array in the NGON_n definition called "ParentElements" : this array, sized as 2*nb_of_faces, is a face-to-cell connectivity : each face provides the id of its two neighboring cells (or one for boundary faces).

Source : https://cgns.github.io/CGNS_docs_current/sids/gridflow.html#Elements

Current behaviour

Today, standard elements are well managed by VTK. For polyhedral elements, the runtime strategy is:

  1. If NGON and NFACE are present in file, use it to build volumic cells (mesh is 3d)
  2. If only NGON are present in file, use it to build surfacic cells (mesh has 3 spatial dimensions, but cells are surfacic)

New behaviour

This development make use, if necessary, of the ParentElements node in order to deduce the cell-to-face (aka NFACE) connectivity. Indeed,

  • For standard (typed) element meshes, nothing changes;
  • If NGON and NFACE are present in the datafile, nothing changes (see case 1. above);
  • If only NGON are present and if the ParentElements array does not exist, nothing changes (see case 2. above);
  • If only NGON are present and if the ParentElements array exists, this array is loaded and transposed to build internally the data that would have been read from the NFACE elements. Then we fallback to case 1.

Motivation

CFD solvers usually uses finite volume method for which the face-to-cell connectivity is more efficient than the cell-to-face connectivity. In order to save disk storage and memory use, the NFace elements are often removed from the mesh files once the ParentElement array have been created. But, when it comes to visualisation, the opposite transposition has to be done involving large i/o operations and cumbersome scripts. Taking care of this situation directly in VTK would be a great improvement in CFD workflows.

Implementation details

  • Even if NFACE elements are not present in the mesh, we assume that the ParentElements array refers to the global ids of the cells as stated by the CGNS standard. This means that the range of the NGON goes from 1 to nbFaces, and the ParentElements values are in the range [nbFaces + 1; nbFaces + nbCells], which is the implicit range of NFACE elements.

  • I am open to any change in the proposed implementation.

Merge request reports