Additional notes on exploring non-conforming meshes

[amartinhuertas]

• Move inner constructor of GridapDistributed.GenericDistributedModel as outer constructor. One may need to pass the full set of d-dimensional gids from an existing GenericDistributedModel instance to the inner constructor.
• I am positive that refine(::OctreeDistributedDiscreteModel, args...) should return an OctreeDistributedDiscreteModel with a GenericDiscreteModel made of local AdaptiveDiscreteModel. At present, this is not the case for some of the variants of refine, and thus, among others, we need to do the following in GridapSolvers.jl: https://github.com/gridap/GridapSolvers.jl/blob/47955a82d55958cc0585780325c005db3755efe2/src/MultilevelTools/ModelHierarchies.jl#L200, that can be definitely avoided. Besides, we also want the user to be able to transfer functions among FE meshes outside the model hierarchy subsytems, thus needing this feature.
• After porting GridapP4est.jl to PArrays v0.3, I have needed to add MPIVectorVoid type and i_am_in function. In regards to the latter function, shouldn't it go to PArrays? UPDATE: [They already went to GridapDistributed]
• If I execute rdmodel,glue=refine(dmodel,ref_coarse_flags); twice, then Gridap generates an error the second time. The cause of the error is that we are trying to create the hanging tag in the face labeling associated to dmodel, but this does not make sense as refine should not modify dmodel. [Solved in cf93940]
• Added a test to RefinementRulesTests.jl that fails and should not Gridap.jl#921
• GridapDistributed does not export redistribute. Why not?
• When to use setup_non_conforming_distributed_discrete_model versus setup_distributed_discrete_model ?
• I am positive that the contents of https://github.com/gridap/GridapP4est.jl/blob/eff06a337e2f1b95d62c3d1fcbbde24dc6d2b670/src/FESpaces.jl should be moved to GridapDistributed.jl. However, the issue, as we have with RedistributeGlue, is that we would have to create a mock NonconformingGlue. Seems feasible though. [DONE] in GridapDistributed.
• I have ported RedistributeTools.jl from GridapSolvers.jl to PArrays v0.3 and put it temporarily into GridapP4est.jl. Thus, PLEASE, when porting GridapSolvers.jl to PArrays v0.3 let us start from here. On the other hand, I am positive that the contents of RedistributeTools.jl should go to GridapDistributed.jl. We will also need mock tests, though. [DONE] in GridapDistributed.
• TO-THINK: better strategy to deal with "orphan" hanging dofs on ghost cells. See, e.g.,:
  

  GridapP4est.jl/src/FESpaces.jl

  Line 56 in c7d4762

  ptrs[fid_hanging+1] = ptrs[fid_hanging] + 1

  or

  GridapP4est.jl/src/FESpaces.jl

  Line 72 in c7d4762

  s = ptrs[fid_hanging]

• TO-THINK: a better/cleaner alternative to the get_cell_dof_ids_inner_space function

  GridapP4est.jl/src/RedistributeTools.jl

  Line 228 in c7d4762

  function _get_cell_dof_ids_inner_space(s::FESpace)

  . Also to think how the problem that this approach solves can impact other scenarios.
• Mods to AdaptivityGlue required to support mixedRefinement will go to corresponding Gridap branch. [DONE]
• [TO-INVESTIGATE] New quadrants created by p4est as by-product of the refeniment process have quadrant.p.user_data == C_NULL and they should NOT accordingly to p4est documentation and also the tests of P4est_wrapper.jl that I run, which look correct. So far I am using a workaround to bypass this problem. See

  GridapP4est.jl/src/OctreeDistributedDiscreteModels.jl

  Line 1375 in b87d15a

  # I have noticed that new quadrants created as by-product

  for more details.