Changes in Gridap 0.17 required to implement high level API

[amartinhuertas]

In this issue I document issues/misc thoughs while exploring the implementation of the high-level API for hybridized solvers. In particular, what I did is to combine the skeleton code proposed here with the developments so far in ExploringGridapHybridization.jl.

Issues/Changes I had to make in Gridap

• Added type parameter to FacetoFaceGlue. gridap/Gridap.jl@af7d095
• Gridap.jl v0.17: MultiFieldCellField cannot be currently built out of fields which are defined on different triangulations, i.e., bulk versus skeleton. A check fails here. I commented out the check. See here
• Generalization of CellQuadrature member variables in Gridap.jl see here
• [ALREADY REFLECTED in Gridap 0.17.9] Generalization of CellPoint member variables in Gridap.jl see here
• Discuss overloads of Reindex + VectorBlock see here
• MultifieldFEComponentBasis assumes (it is hard-coded) that its cell array of arrays of Fields is created out of the result of applying BlockMap to an array of arrays of Fields. This prevents transformations required in Hybrid methods from [c][b] to [c][f][b]. Instead, following that workflow we first transform [c] into [c][f], and then [c][f][b], which is NOT equivalent to [c][b][f]. I converted the inner constructor to an outer constructor as a workaround. see here A more clean solution might be needed here.

Misc ideas

• I think it would be useful in several contexts to have FaceToCellGlue parameterized by {Df,Dc}, where Df is the topological dimension of the face and Dc the topological dimension of the cell. Would it be also useful for other types of glues, such as, e.g., FaceToFaceGlue ? To-think.