This document contains a draft proposal for the storage of solutions, data and meshes for unstructured, finite element like solvers. The aim is to cater for the large ...
Proposal for the high order extension to CGNS 1 Introduction This document contains a draft proposal for the storage of solutions, data and meshes for unstructured, finite element like solvers. The aim is to cater for the large diversity of high order methods by including a description of the interpolation functions for both solution and mesh in the file, thereby only fixing the bare essentials: the coordinate system. This will: ● allow to use the native storage of the code, leading to ○ A simpler, more robust and generic implementation of the drivers; ○ More efficient I/O by straightforwardly dumping data blocks; ○ Avoiding the loss of precision for very specific interpolation functions; ● CGNS can provide the projection matrices from a given data set for another functional space, if the user provides the expressions during reading. In theory we could even directly perform the projection before handing the data. ● avoid the need to redefine the format for each new interpolation type/order/…; ● cater for space-time methods as well as for ALE computations by including time in the functional expressions. In a second time, CGNS can provide generic tools using the interpolation schemes ● (Approximate) conversion from a CGNS file in one to another set of functional bases; ● Recursive refinement from a high order format to a linear format for using currently available post-processing tools.
2 Overview of methods and general conclusions 2.1 Interpolation of solution and data By “high order finite-element like methods”, we mean methods that approximate the solution or any other data u in a functional space 𝓥, that is spanned by elementwise defined interpolation functions of arbitrary order or even function type. Within such an element e, the solution/data are defined by a linear combination of basis functions 𝜙ei
The aim of this note is to provide a flexible way to store both the expansion weights ue i and describe the elementwise interpolation / shape functions 𝜙ei. In most cases, the shape functions are the same for all elements of the same type so we continue with the notation 𝜙i, unless the functions explicitly depend on the element. There is a large variation in the definition of the solution interpolants. These can be categorized following four criteria: ● Function types. The functional space is usually composed of polynomial functions, although for some cases other functions are used, which eg. correspond to a solution of
the homogeneous equations, potentially involving trigonometric functions (eg. Discontinuous Enrichment Method); Pyramidal elements are a very specific case. It was shown by Bergot et al. [BCD10] that a specific rational space is required in order to provide compatible interpolation spaces between the pyramid and other elements employing polynomial functional spaces. ● Continuity of the functional space and location of the degrees of freedom. Here we distinguish essentially the association between the degrees of freedom and the regions / interfaces in the mesh1 . ○ The first important subclass concerns continuous finite element methods. These will associate part of the degrees of freedom to the regions, but also some to the interfaces; ○ A second important class uses a discontinuous interpolation. This is the case for the discontinuous Galerkin, the Flux Reconstruction, Spectral difference, … methods. In this case, all degrees of freedom are associated to the regions; ○ Hybrid DG methods use trace interpolants on and therefore degrees of freedom on the element interfaces. Potentially the interior solution inside the regions could be stored as well. ○ …? ● Coordinates. The elements of the functional spaces can be defined as functions of parametric or Cartesian coordinates. Parametric coordinates are defined in a reference element; the Cartesian coordinates of the real element are then defined by a mapping
. Space-time methods moreover also interpolate the solution in time. Typically the functional space is the vector product of a 3D “spatial” functional space and a 1D “temporal” space. ● Basis functions. One can distinguish two types: ○ Nodal bases are based upon the choice of a set of control points 𝛏ei . Often Lagrange interpolants are used, ie. for which we require
but there are also other approaches that use Bézier splines, NURBS (NEFEMS, IGA), … Nodal interpolation allows to ensure compatibility of interpolation spaces at the interfaces in a straightforward way, but this implies that the number of control 1
We denote as “regions” the elements of the same dimension of the mesh, and as “interfaces”, the elements linking two regions.
points and therefore the base and finally the restriction of the functional space itself to the element depend on the element type. ○ Modal bases are basically any other type. Popular choices are monomials (eg. {1, x, y, x2, xy, y2,...} in Cartesian coordinates) or orthonormal polynomials. By removing the link between basis and control points, the actual functional space can be chosen independently of the element type; this enables for instance the use of agglomerated or arbitrary elements. Conclusions: ● The coordinate system should include time in order not to lose precision when storing space-time solutions. ● For the sake of generality and because interpolation in parametric and Cartesian coordinates are not equal in general, we should cater for Cartesian (x,y,z,t) and parametric coordinate sets (u,v,w,t). ● Considering that nodal bases can also be written as particular functions, and that a solution can be transferred from one base to the other by projection without loss of accuracy, the same format can be used for nodal and modal basis, which consists of explicitly writing down the functions for any given element type and interpolation order. ● Allowing to specify freely all functions for each element type allows as well to cater for all types of continuity, by defining interpolation functions and data blocks to the elements that actually store data. Eg. for hybrid DG, one would provide solution storage on the element interfaces; the interpolation blocks would then be defined for those only. ● Within the modal basis approaches, some methods employ basis functions that are obtained by orthogonalisation on the element. Storing element specific bases would imply a large data set, which is not desirable, and add considerable complexity to the format. Therefore, it is proposed not to cater explicitly for this case. We then would require a conversion to a common set of functions per element type, which can still be chosen by the code developer. ● In the case of tensor product spaces, an important economy can be made on the function description block. Therefore it would be wise to allow to add a simple directive to indicate this and then only provide the 1D functions.
2.2 Curved elements For curved elements, typically the Cartesian coordinates of the elements are expressed as a function of the parametric coordinates, similar to the interpolation of the solution described above Due to the necessity to provide “watertight” meshes, usually the mesh interpolation base functions 𝜓i are defined using control points. Choosing common locations for control points on the interface between two regions then ensures continuity of the mesh. Most codes use Lagrange interpolants, but some methods are based upon splines, including Bézier, NURBS, … For the first case, only the point locations should be specified, and then the Lagrange interpolants can be found by inverting the Vandermonde matrix. In the case of splines, the order of the points is important. There are roughly two options once the (parametric) coordinate system is fixed ● specify the control points and the type of interpolation ● Describe the interpolation functions directly.
The first is an extension of the current format. Following discussions however, the last solution is preferred since ● This avoids having to specify the type of interpolant (Lagrange, Bézier, NURBS, …) and cater for all of the cases ● Allows for an easy inclusion of time in the element transformation, which can be exploited for ALE. ● Allows to reuse the machinery developed for interpreting/converting/… the solution A final remark concerns the current mesh storage format. We propose to keep this as the default approach to enable previous users to continue to use it.
2.3 Isoparametricity Many methods nowadays do not use isoparametric interpolation, ie. equal order for mesh and solution interpolation. Therefore, the description of the interpolation of both should be indicated separately and a global indexing strategy should be found if separate blocks per element type are created.
3 Proposal 3.1 General principles Instead of fixing the interpolation space, the description of the functional space is integrated as metadata in the CGNS file. The basic principles are 1. The standard fixes two element coordinate system types, for which it fixes the set of axes ○ parametric coordinate systems are shown in the next section; ○ Cartesian coordinates. In this case the axis system is aligned with the principal axes and centered in the arithmetic average of the principal vertices2 ; 2. For generic interpolation per each element type and interpolation subtype3 , a separate interpolation block is added which lists ○ The coordinate system type; ○ The number of functions; ○ the coordinate transformation from the standard system; ○ the functions that are associated to each degree of freedom, under the form of string expressions4 with respect to the indepented variables x,y,z and t. A proposal for the supported functions is outlined in the next section. 3. In case a tensor product space is used, another type of interpolation block should be used, which only provides specifications of the 1D base functions. 4. For each element type and interpolation subtype separate solution blocks or mesh coordinate blocks are created, which contain for each element of this category, the expansion weights in the order of the function description block; 2
The “principal” vertices are defined here as the vertices of the corresponding linear element. The interpolation subtype typically corresponds to interpolation order for polynomial interpolation, but may be used as a classification tag for more general interpolation choices. 4 Parsing and evaluating those should not be a problem, since a host of mathematical expression parsing libraries are available (see e.g. [mathex]), which support all standard mathematical functions. These should ideally be extended to include Legendre (P(n,x)) and Jacobi polynomials (J(n,a,b,x)) as these are often used. The extension of at least one (lGPL) mathematical parsing library (eg. mathex) would then be part of this work. 3
5. The categories are defined independently for solution and mesh, such that a separate indexing is required.
3.2 Description of the function description block API 3.3 Description of the data block API 4 Detailed specifications 4.1 Parametric coordinate systems The coordinate system for the line is given by 𝜉 ∊ [-1,1]; the other elements are specified below:
4.2 Supported functional expressions A shape form is described by a generic string expression containing sums/products/divisions/… of elementary functions defined with respect to x,y,z and t ● ● ● ● ●
Monomials; Commonly used orthogonal polynomials: Legendre “P(n,x)”, Jacobi “J(n,a,b,x)”; Exponential and related functions : ln, log, log10, exp, sinh, ... Trigonometric functions: Sin, Cos, … (smoothed) step H(x) and Dirac functions d(x)
At the exception of the orthogonal functions, these functions are supported by C and therefore by most expression parsing libraries.
5 Open points of discussion ● Modal methods with specific bases for each element separately (eg. generated by orthogonalisation on the element itself) - this has been discussed above; the proposal is to request a transformation to a generic base for all elements of the same type. ● High order XFEM, eg. for multiphase - here we need to store two solutions for the same region + the cut of the cell ● IGA methods ● Hybrid DG ● Local enrichment
6 References [BCD10] M.Bergot, G. Cohen et M. Duruflé, Higher-order Finite Elements for Hybrid Meshes Using New Nodal Pyramidal Elements, (2010), Journal of Scientific Computing 42, pp. 345–381, doi 10.1007/s10915-009-9334-9 [Mathex] The mathex library, written by S. Massago, is part of the small scientific library (SSCILIB) and can be found at http://sscilib.sourceforge.net
