Nonlinear (Curved) Meshes

[termi-official]

Hi folks,

as discussed on Slack it might be a good idea to extend the geometry interface for visualization purposes regarding mesh-based PDE discretizations methods like FEM, FVM, ... in Makie.jl. The current interface should already be a good basis for conforming linear geometry. Let me recap some of the discussion. (Note that I included some discussion about the solution fields for completeness, although this part of the interface should not be part of GeometryBasics.jl interface.)

Nonlinear geometry

Let me motivate nonlinear geometry first for those unfamiliar with it. When using e.g. the finite element method (FEM) to solve mechanics problems it is often beneficial to use an non-linear ansatz. Also for computations on designed geometries (i.e. IGA), a nonlinear ansatz is required. Especially when using a very high order ansatz the geometry can deform rather drastically (see e.g. the following MFEM blast simulation with 4 elements).
Having a nonlinear representation of the solution field and mesh available for simulation and post-processing has a big advantage - we can utilize shaders (especially tessellation shaders) to adapt to the solution field, suppressing issues with the nonlinearities while being very performant. It certainly is possible to first discretize the nonlinear field and mesh sufficiently in each framework supporting nonlinear solutions, but this approach has the disadvantage of having similar codes across the different frameworks and doing the tessellation manually at the CPU can get problematic when visualizing large simulations.

Nonconforming geometry

Having some infrastructure to represent nonconforming data on the mesh and nonconforming geometry can also be helpful. Some examples of nonconforming data is the representation of discontinuous coefficients coming from experimental measurements or the solution field itself can be discontinuous due to the utilized method. Nonconforming geometries usually originate from space-adaptive simulations, where we do not want to waste computational resources in regions where nothing happens. While the former is primarily a concern of the renderer, it might be helpful to have information about nonconformity available in the mesh itself.

Open issue

The issue I run into is to find a suitable interface that works across the different exising frameworks.

The first problem that I see is that linearity is assumed at several positions. This should be rather easy resolvable by moving around types in the type hierarchy in a non-breaking way. To be specific, I was thinking about proposing to make the Polytope a GeometryPrimitive (instead of a AbstractGeometry-type) and AbstractMesh dependend on GeometryPrimitive instead of on Polytope. This way we can define nonlinear entities as specific GeometryPrimitives.

Handling the presented kinds of nonconformities is problem of the utilized visualization library. These libraries should be able to overcome this issue rather easily by proving an element-centric view on the mesh, i.e. if the renderer "just" renders out element after element, as if there is no connectivity between them.

Now let me explain an approach on how I think we could tackle the derivation of a general representation of geometric nonlinearities. My proposal is to start with geometries represented via Lagrange basis functions, as they are typically the most common ones and try to derive a more abstract interface from this specific use-case. (If it is unclear what I mean by "representable via Lagrange basis functions", a nice introduction is given by Kitware's blog post about Lagrange elements in ParaView.) .

If someone is more proficient than me in geometric nonlinearities and/or already has a better idea on what a general interface for nonlinear geometries could look like (at least for visualization purposes), then I am to learn about it. I am also happy to discuss additional issues, points which I may have forgot and any suggestion for improvements!