Some comments about current surface coupling approach

[santiagobadia]

Hi @fverdugo

I think that the constructor of the InterfaceTriangulation

Gridap.jl/test/GridapTests/SurfaceCouplingTests.jl

Line 70 in 57c08cd

trian_Γ = InterfaceTriangulation(model,cell_to_is_fluid)

should take as arguments two sets of cells. We can keep this one, but we need another one in which we take two sets of sub-cells. Or even better, two triangulation restrictions. The thing is that, when we will have three domains Ω1, Ω2 and Ω3, we want to be able to define Γ12, Γ13 or Γ23.

I would even think further, what about the edges between Ω1, Ω2 and Ω3, let us say Γ123. I think this algorithm is just extract geometrical entities given some labels, right? It can be very general...

On the other hand, do we need in

Gridap.jl/test/GridapTests/SurfaceCouplingTests.jl

Lines 96 to 102 in 57c08cd

	Q = TestFESpace(
	triangulation=trian_fluid,
	valuetype=Float64,
	order=order-1,
	reffe=:PLagrangian,
	conformity=:L2,
	restricted_at=trian_fluid)

triangulation and restricted_at? It is weird. I would create a constructor with only one restricted triangulation.

On the other hand, for the restricted FE spaces, you use a triangulation

Gridap.jl/test/GridapTests/SurfaceCouplingTests.jl

Lines 96 to 102 in 57c08cd

	Q = TestFESpace(
	triangulation=trian_fluid,
	valuetype=Float64,
	order=order-1,
	reffe=:PLagrangian,
	conformity=:L2,
	restricted_at=trian_fluid)

whereas for the standard ones a model

Gridap.jl/test/GridapTests/SurfaceCouplingTests.jl

Lines 76 to 82 in 57c08cd

	V = TestFESpace(
	model=model,
	valuetype=VectorValue{2,Float64},
	reffe=:QLagrangian,
	order=order,
	conformity =:H1,
	dirichlet_tags="dirichlet")

This is also very odd. That is the reason why I originally proposed a ModelRestriction. I think we should also fix this problem. In fact, I thought that the reason why we need a model are the boundary conditions (labels, etc). Can we enforce labels in the extended FE spaces you have defined? In this particular case, the pressure has no boundary conditions, but what about other cases?

And finally, we also want to be able to read restrictions from e.g. GMesh, don't we?

Apart from these minor things, great job!

[fverdugo]

The interfaceTriangulation constructor currently assumes that you want to split the entire domain into two sub-domains which are a partition of the original one. Of course, one could extend it to find the interface of two arbitrary sub-domains that are not necessarily a partition of the original domain.

About the construction of FE Spaces:

• Now it is possible to construct discontinuous FE spaces that have no Dirichlet bcs from a triangulation instead of a model (its just an optimization since in this case a model is not really needed, but you can still use a model if you wish)

• I have implemented the DiscreteModelPortion constructor that returns a model that inherits the labels from the original model.

• The new kw argument restricted_at is to signal that we want return an ExtendedFESpace. I agree that it is redundant in some cases (e.g., if you provide an ExtendedTriangulation object in the triangulation argument) .

I think we have to discuss these topics face to face since they are quite advanced with a lot of small details...

[fverdugo]

• Add a properties inward and outward to skeleton related objects
• Implement this API

rtrian = Triangulation(trian,list_of_cells)
# equivalent to 
rtrian = RestrictedTriangulation(trian,list_of_cells)
rmodel = DiscreteModel(model,list_of_cells)
# equivalent to 
rmodel = RestrictedDiscreteModel(model,list_of_cells)

• Remove restrticted_at kw-argument

• Further APIs

# From GMesh
fmodel = DiscreteModel(model,"fluid")
smodel = DiscreteModel(model,"solid")
imodel = InterfaceModel(fmodel,smodel)
itrian = InterfaceTriangulation(model, labels,"fluid","solid")
itrian = InterfaceTriangulation(model,fluid_cells,solid_cells)
itrian = InterfaceTriangulation(fmodel,smodel)
ftrian = Triangulation(fmodel)

[fverdugo]

Fixed via PR #209