Draft: Improve Ordering Test suite and several Fix Bugs

IMPORTANT: This is work in progress. The description of this MR is still incomplete and the pipeline is still not passing

Summary

On the last months, I have been exposing (and creating) different bugs on the ordering. Some examples are:

• !555 (merged) Ordering was not able to give information about entity block sizes. This was fixed in !555 (merged) but still this was not thoroughly tested and there some know errors.
• !560 (merged) Entity blocking does not work properly on non fixed-size order.
• #179 There is no working version for fast FV orderings (1 DOF per entity).
• !558 Blocking size is miscalculated on complicated cases
• Blocking within grid view orderings is very buggy. In particular, the Grid View Ordering has a very strange handling of blocking that only work if the immediate local ordering is blocked.
• !559 (closed) There is no clear separation of concerns between Grid Function Spaces and Orderings and their instantiation and construction do not follow the same order.
• !557 (comment 81042) Entity Index cache, and therefore the Data Handler, is not able to handle multi-domain cases.
• Chunked ordering seems to be broken.
• The ISTL backends generate containers with field containers of size 1. This creates a mismatch between the container index generated by the ordering machinery and the one required by the backend. This has historical reasons but is not needed anymore.

I have pushed several fixes for some of these problems, but is was always hard to know what was tested and what not. Some times, these problems come bundled together and it does not make sense to treat them separately. For example, is hard to make a test case for !558 because is not entirely clear which blocked ordering cases are working. In other cases, the ordering may be producing the correct container indices, but the container is completely wrong.

Proposal

This is why I have been working in only one test suit for orderings that fixes most of these problems. The test suit is designed to have high coverage on ordering header files. Whenever I found a but I immediately fixed and went for the next bug. By the end of this, I got around 110 test cases including edge cases and nearly 100% coverage. This MR is not necessarily to be merged but to serve as a test coverage target for some of the problems listed above.

ISTL Container factory

In order to test the orderings, it is necessary to have a working container factory for the different tags. The current one is broken in different ways that are not compatible with all the possible orderings. Here I have an alternative factory. This is not necessarily a final one but it does the job for now.

Order of type instantiations

The container index depth (the size of the multi-index for container indices) is ideally the same as the block level. But currently it is not possible to use the block level because the vector container is not yet deduced at instantiation time of the ordering. That's why we have a -buggy- static accumulation of the container depth. The following change in type instantiation order allow us to reuse ISTL code for block level.

• Current instantiations order:
  1. Grid Function Space (incomplete) type that holds Traits.
  2. Container Index Depth from incomplete GFS traversal with TypeTree static size accumulation.
  3. Ordering type from TypeTree transformation machinery.
  4. Grid Function Space that holds an Ordering.
  5. Vector container from meta algorithm.
• Proposed instantiations order:
  1. Unordered Grid Function Space (complete) type that holds Traits. (see !559 (closed))
  2. Vector container from meta algorithm.
  3. Container index depth is equal to the block level of the vector container.
  4. Ordering type from TypeTree transformation machinery.
  5. Ordered Grid Function Space is basically an Unordered GFS that includes the ordering type.

The proposed instantiation order also has the advantage that it matches GFS and Ordering run time initialization.

Compiler

The compilers currently supported by PDELab (gcc-7 and clang-6) do not allow deduction of types on different function instantiations of the same template. Unfortunately that's precisely the way I programmed the template meta-program to deduce ISTL containers. Why? Because otherwise I would have to go to a very long template specialization of each of the possible combinations. Thus, just for testing this, I updated the dependencies in the CI to gcc-8 and clang-7

Dependencies

• !559 (closed)
• core/dune-common!995 (merged) A type trait for big unsigned integer is missing. This is needed to detect the block level of ISTL containers.
• core/dune-common!994 (closed) Scalar assignments for blockings where a FieldVector contains a dynamic vector.
• dune-functions ISTL backend is not able to cope with sparse vector patterns. It thinks that they are miss-sized.