-
Notifications
You must be signed in to change notification settings - Fork 89
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This patch reworks the `AbstractCell` interface (refer to #677 for motivation and discussion for alternatives to this patch). Specifically, this patch - introduces the reference dimension as a type parameter on `AbstractRefShape`, - introduces `RefInterval`, `RefTriangle`, `RefQuadrilateral`, and `RefHexahedron` as new subtypes of `AbstractRefShape{refdim}` (note that interpolations are not updated to this system yet since it can be done in a separate patch), - deprecates the old `Cell{refdim, nnodes, nfaces}` struct, - introduces new structs for all supported cell types, e.g. `struct Triangle <: AbstractCell{RefTriangle}`, - defines the unique vertex/edge/face identifiers for DoF-distribution in terms of the reference shape. The new parametrization makes it possible to dispatch on the reference shape instead of union of concrete implementations, i.e. `::AbstractCell{RefTriangle}` instead of `::Union{Triangle, QuadraticTriangle}`, and similarly for the reference dimension. One drawback is that it is no longer possible to use "anonymous celltypes" after this patch, i.e. using, e.g., `Cell{3, 20, 6}` and defining methods for that instead of explicitly naming it `SerendipityQuadraticHexahedron` or similar. Instead, you now have to define a struct and some methods. Arguably this is a good thing -- nobody understands the meaning of `Cell{3, 20, 6}`. For normal usage this patch is not breaking (see e.g. no required changes for examples), unless one dispatches on the `Cell` struct directly. Specific things that remain to be decided: - `struct Triangle <: AbstractCell{2, RefTriangle}` or `struct Triangle <: AbstractRefCell{2, RefTriangle} <: AbstractCell`? I don't know if it is too restrictive to "force" `{refdim, refshape}` on all subtypes of `AbstractCell`. On the other hand, if one implements a non-refshape based element one can define a dummy reference shape. For a real-world example, looking at e.g. https://github.com/kimauth/FerriteCohesiveZones.jl/blob/main/src/cohesive_cell.jl I think that would simply be implemented as ```julia struct CohesiveQuadrilateral <: AbstractCell{2, RefQuadrilateral} nodes::NTuple{4, Int} end ``` which I don't see a direct problem with, other than the fact that the cell will now have 4 edges (according to the fallback definitions). To solve this, one would have to implement a method for `faces(::CohesiveQuadrilateral)` that only return the upper and lower edge. I don't think this is too much to ask for custom elements like this. Alternatively, with #581 merged it is possible to distribute different number of dofs for different edges, so this can also be solved on the (default) interpolation level by distributing 0 dofs on the left and right edge. - `AbstractCell{refdim, refshape}` or just `AbstractCell{refshape}`? The dimension is implicit from the shape now, and you can dispatch on `AbstractCell{<:AbstractRefShape{refdim}} where refdim`. Personally I am in favor of including the dimension, even if redundant. It does not cost anything, and sometimes you want to dispatch on the dimension, sometimes on the refshape. Fixes #677.
- Loading branch information
1 parent
83b072c
commit 16d3ba3
Showing
9 changed files
with
275 additions
and
117 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters