Curvilinear elements

[sbadrian]

PR #58 shows an example implementation of a 1D curvilinear mesh with general simplices

The simplices ares general, in the sense, that I do not assume equal spacing. Currently, I only work with equal spacing, because Gmsh results in equal spacing, but the code is not optimized for it.

I think a next step some type should be introduced to allow optimization for equidistant layout.

abstract type AbstractLineLayout end

struct EquidistantLayout{N,T} <: AbstractLineLayout
    # optionally precomputed denominators, etc.
end

struct GeneralLayout{N,T} <: AbstractLineLayout
    ζnodes::SVector{N,T}
    # optionally precomputed denominators, etc.
end

Curious of your thoughts. I guess my specific questions are:

1. How general should the code be?
2. Where to we store the information regarding the barycentric coordinates of the control vertices given a CurvilinearMesh? Would that be something for the typed_cells data types?

[sbadrian]

Some additional comments after todays discussion:

• The typed-cells will not contain information of position in parameter space. For now, we will focus on the standard case of equi-spaced Lagrange elements, though the CurvilinearSimplex will be able handle both.

• The way skeleton function is used in some of the default constructors of the Lagrange Basis in BEAST implicitly assumes that it receives the information of the topology, while actually the skeleton function is supposed to extract a submesh that would include the control vertices of the geometry representation. The higher order implementation of GWP function shows how to correctly to do it.

• The chart function should in future be restricted to chart(msh, integer pointer), where the integer pointer could be typed.

[sbadrian]

PR #62 supersedes PR #59

As discussed, we only focus on Equi-spaced Lagrange Elements. Jacobians, tangents etc are now also available for triangles up to order 10.

I think for anything practical, however, we must stamp out order-specific implementations to avoid any sorts of allocations. I did exemplify it for the line element of order 2. This saves roughly an order of magntitude in time for the unitarybase function call (the function that provides the tangents).

Major blocking point
However, what is missing is a correct implementation of the skeleton function.

The skeleton function is supposed to return a CurvilinearMesh (when presented with a CurvilinearMesh). For the standard Mesh, it resorts to the SimplexGraph methodology. I am not sure if it makes sense to introduce a CurvilinearSimplexGraph (I need to better understand what is all relying upon the SimplexGraph and what else is done with it). I did not check yet out the GWP implementation.

The ordering of the (control) vertices is using the Gmsh one (for not having a reason to use anything else). One could think of hardcoding the order in files such as curvilinear_gmsh_triangle.jl to quickly pick, the indices of the control vertices, for example, of edge 2 of a triangle. Still the question is if we need a GmshSimplexGraph{O} with enshrined order O.

Minor points
A minor point (in the sense that it does not prevent usage) is the MeshPointNM structure. I wanted to recycle the meshpoint type as is. However, MeshPointNM does not allow the storage of volume, tangents, Jacobians, normal etc. Unlike the standard Simplex case, we cannot store this information in the CurvilinearSimplex as the values depend on the barycentric coordinates (except for the volume).

Should we store such information in future in MeshPointNM? This would increase currently the data used in the linear code, but would allow to use only one structure. I am not sure if the NeighborhoodLazy structure provides a good way out.