Coupling shells to solid faces

[lijas]

It is quite uncommon, but sometimes you want to add a "skin" of shell elements on the face of a solid. One example of this which I have encountered, is to model sandwich composites with shell elements on the top and bottom surfaces of a solid foam core.

At the moment, it is not possible to this for higher order shells/solids. The reason for this is because shells (e.g Quadrilaterals) do not share a consistent definition of faces and edges with solids (e.g hexaherons). Note that it works for linear shells/solids since dofs are only distributed on nodes in this case.

MWE:

# Ferrite grid: Beam attached to face
# 3 ____ 4  4
# |      |  |   
# |      |  | (Beam attached to face)    
# 1 ____ 2  2

dim = 2
grid = generate_grid(Quadrilateral, (1,1))
line1 = Line((2,4))
grid = Grid([grid.cells[1], line1], grid.nodes)

order = 2
ip_quads = Lagrange{RefQuadrilateral, order}()#^dim
ip_shell = Lagrange{RefLine, order}()

dh = DofHandler(grid)
sdh_quads = SubDofHandler(dh, Set(1))
add!(sdh_quads, :u, ip_quads)
sdh_coh = SubDofHandler(dh, Set(2))
add!(sdh_coh, :u, ip_shell)
close!(dh)

dofsquad = zeros(Int, ndofs_per_cell(dh, 1))
dofsbeam = zeros(Int, ndofs_per_cell(dh, 2))

celldofs!(dofsquad, dh, 1)
celldofs!(dofsbeam, dh, 2)
@show dofsbeam # dofsbeam = [2, 3, 10]

As you can see, the dofs on the shell (or beam since this in 2d), contains a 10th dofs, but it should be the 6th dofs shared with the quad. Note that #789 would solve this (however with some annoying breaking changes)

[termi-official]

Why does the mentioned PR solve the issue? We would have to make the "1D cell dofs" also edge dofs to make it work here, right?

[lijas]

I dont really understand what you mean by "1D cell dofs", but a line element would basically be considered as an edge, so if a Line element are attached to the facet (edge) of a quad, the dofhandler would distribute the dofs correctly

[termi-official]

Ah, sorry, I missed part of the diff. (This one:)

-facedof_indices(::Lagrange{RefLine,2}) = ((1,), (2,))
-celldof_interior_indices(::Lagrange{RefLine,2}) = (3,)
+edgedof_indices(::Lagrange{RefLine,2}) = ((1,2,3),)
+edgedof_interior_indices(::Lagrange{RefLine,2}) = (3,)

[KnutAM]

I haven't really thought this final through, but made some notes regarding this since it seems to be an issue also wrt. the interface elements (ref #767)

Wouldn't properly (but with different names to avoid the issues of not using face and edge as it is currently) defining with dim and codim (aka Ciarlet but with different names) solve these issues? For naming, I even first considered (dim0dof, dim1dof...) and (codim0dof, codim1dof...), but then thought of the following naming scheme.

"Dofs associated with 0-dimensional entities (Ciarlet: point)"
vertexdof_indices # Same as currently

"Dofs associated with 1-dimensional entities (Ciarlet: edge)"
curvedof_indices

"Dofs associated with 2-dimensional entities (Ciarlet: face)"
surfacedof_indices

"Dofs associated with 3-dimensional entities (Ciarlet: volume)"
volumedof_indices

"Dofs associated with codimension 2 entities (only applicable to 3d and 2d objects) (Ciarlet: ridges)"
edgedof_indices # ref meaning of edges(::AbstractCell)

"Dofs associated with codimension 1 entities (Ciarlet: facets)"
facedof_indices # ref meaning of faces(::AbstractCell)

"Dofs associated with codimension 0 entities (Ciarlet: cell)"
celldof_indices

# dof-distribution should go `vertex - curve - surface - volume`
# note1: The `xdof_internal_indices` versions are used for dof-distribution.
# note2: `edges` of 2d objects and `faces` of 1d objects should then return the `vertices` which enables dimension-independent code.  

[termi-official]

I think this is certainly another possibility, but it comes yet with another vocabulary which might come again with the issue of confusing new users, right? Is this naming scheme used somerwhere else?

[KnutAM]

I'm really torn here, it would be a very breaking change for many users, but could also make life much easier as we add more advanced features.

Not to hijack this specific issue / emphasize this discussion further, I'll open a separate issue on adopting the Ciarlet definition and mark it as breaking / needs descision before releasing 1.0.

[lijas]

TODO: add test for this?