Towards ALE with simplex elements

[nfehn]

This PR redesigns the class MappingDoFVector in order to allow the use of simplex elements for ALE problems.

Previously, the class MappingDoFVector was derived from dealii::MappingQCache (so that ALE mappings have always been of type dealii::Mapping), while the present PR suggests to change the design from inheritance to composition, in order to allow both hypercube and simplex elements. In consequence, the class MappingDoFVector has now a member function get_mapping() returning a dealii::Mapping.

What makes this PR a somewhat bigger effort is the fact that we have used dynamic casts to dealii::MappingQCache in the multigrid preconditioner, triggering certain function calls (i.e. initialization of coarse mappings) if this dynamic cast is successful. Since dynamic casting is no longer possible with the composition-design suggested above, we need to make the multigrid algorithm explicitly aware of a mapping of type MappingDoFVector, e.g. via additional parameters passed to the multigrid preconditioner.

I created a new class MultigridMappings to be initialized on the Application or Driver level. This will require changes in interfaces and will require to touch many many files. I did not do this so far in order to first discuss the basic design. A straightforward extension of existing interfaces would be to extend

• Application::setup(grid, mapping) (see ConvDiff module with PR Move grid and mapping to driver for ConvDiff module #596, other modules have not been changed accordingly so far ... @richardschu maybe let's discuss how / when we want to do this change for other modules) to
• Application::setup(grid, mapping, multigrid_mappings)

with similar changes for Operator::setup() and MultigridPreconditioner::initialize().

Please note that ALE is not the only use case of MappingDoFVector. There are applications where we want to prescribe the static mapping as a MappingDoFVector, and there might be applications where we cannot construct the mappings for coarse multigrid levels via "standard" MultigridTransfer utilities, but need to create the mapping explicitly for every coarse triangulation (via an application-specific implementation).

@kronbichler @richardschu @peterrum It would be great if you could share your ideas on this PR / topic before I run through all the files to be changed.

[richardschu]

I think this is a good step towards using simplex in ALE, more complex applications requiring higher-order meshes and coarse mappings on an application level. Getting away from inheritance in this case in mandatory due toMappingQCache; I support this change! #610 addresses the first point in your list already, and the second one will follow within this PR, right?

[nfehn]

@richardschu In commit 407eb93, I finally adapted the interfaces of Application::setup() and Application::create_grid(), for now only for the Poisson module. Maybe we could discuss if this fits our needs (or all the use cases we have in mind currently), and then I can roll this out to the remaining applications in ExaDG.

Background info: The idea is that in Application::create_grid() we have the possibility to reset the fine-level Mapping to whatever mapping we want to have, and afterwards re-initialize MultigridMappings, using either the default procedure to create coarse level mappings or some user/application-specific implementation provided via the lambda MultigridMappings::lambda_create_coarse_mappings(). This should allow us to deal with both application scenarios of MappingDoFVector in the context of multigrid, namely (i) ALE methods, and (ii) (biomedical) applications with a fine-level mapping of type MappingDoFVector (without ALE). In case we want to combine both use cases (i.e. both "static" mapping and ALE mapping of type MappingDoFVector), the software design should principally allow this, even though we would need additional implementations in case we do not want to use the default constructing of coarse multigrid mappings (via standard multigrid transfer operations), because we would then need a vector of PDE-type ALE solvers for all the coarse h-levels. However, I don't know if this is something we want to use at all. We should rather aim at more "generic" routines for the construction of coarse multigrid mappings (in this context, see also issue #615).

@bergbauer The changes of this PR might affect other test cases we had in the past with a "static" mapping of type MappingDoFVector created/initialized in Application::create_grid().

[richardschu]

The proposed design fits my intended applications - in fact, I think I have a case at hand, where we might be able to improve the quality of the mappings on the coarser levels, just by allowing them to be read from a file rather then interpolated from the fine grid.

Regarding the vector of ALE solvers, we will have to see how the impact is, but that is definitely an interesting topic for the future! ATM, my focus is on getting valid static mappings for more complex geometries that undergo strong maps from some undeformed piecewise linear grid, but I think this is anyways strongly connected to the coarse grid mappings in the dynamic (ALE) case.

[nfehn]

the fundamental change of this PR.