Grid inconsistencies

[koehlerson]

There are a few inconsistencies related to the Grid type

• We have in Grid the cellsets defined as Dict{String,Set{Int}}, but I guess we should use Dict{String,Set{CellIndex}} https://github.com/Ferrite-FEM/Ferrite.jl/blob/a8b06904d15946483cc14e3656217ed2c279777e/src/Grid/grid.jl#L105

• compute_vertex_values should probably renamed to compute_nodal_values since the vertex is defined as the corners of a cell and neglects the "higher order" nodes https://github.com/Ferrite-FEM/Ferrite.jl/blob/a8b06904d15946483cc14e3656217ed2c279777e/src/Grid/grid.jl#L246-L260 I don't know who or what part of Ferrite uses this function, but strictly speaking this would be a breaking change. Although easy to fix for everyone.

  @termi-official edit the issue or write me if I forgot something

[termi-official]

Let us use this issue to gather general problems with the grid and its interface.

I will pick documenting part of this this. My vote would go for defining different entity types. For example we have partial entities local to a cell (currently named FaceIndex, EdgeIndex and VertexIndex) where I am not sure if vertex cosistently refers to an actual vertex and not also too notes. Further we have the global entities which are defined by sorted tuples of vertices.

nnodes_per_cell has one dispatch which does not work correctly in the case of mixed grid. Probably we should make this two dispatches and add some counter to the grid (e.g. a dict which maps from cell types to an integer counting the number of entities occuring in a grid). I think there are multiple ways to resolve this.

Another issue is that for large grids the recommended way for boundary integrals is O(N), which can become surprisingly slow.

[termi-official]

We also should check for more definition inconsistencies in what edges and faces are.

[lijas]

I dont think CellIndex is used anywhere in ferrite, and one reason to not use it is because then you cant do stuff like cellid + 10 (though, I dont know how common this is either)

[KnutAM]

I tried to get a bit of an overview of the grid interface and figured I could share my notes/thoughts here. I found a few (probably known) inconsistencies and made some suggestions on how they could be fixed. Also related to the get*(...) vs *(...) issue...

Grid interface

Coordinates

• getcoordinates

  • Grid, Int -> Cell coordinates
  • Node -> Node coordinates
  • Grid, FaceIndex -> Cell coordinates
  • CellCache -> Cell coordinates

• getcoordinates!

  • x, Grid, Union{Int,Cell,CellIndex,FaceIndex}: x -> Cell coordinates

• Ferrite.cellcoords!

  • x, Union{[Mixed]DofHandler,Grid}, n::Int: x->Cell coordinates

• Ferrite.get_coordinate_eltype(::Union{Grid,Node}) returns the T in Vec{dim,T}

Nodes

• getnodes

  • Grid -> ::Vector{Node}
  • Grid, Int -> Node
  • Grid, Union{String,Vector{Int}} -> Vector{Node}

• Ferrite.cellnodes!

  • ids::Vector{Int}, Union{Grid,MixedDofHandler}, Int: ids -> The cell's node numbers

Cells

• cellid
  • CellCache -> cell index in the grid
  • PointLocation -> cell index in the grid
• getcells
  • Grid -> All Cells in the grid
  • Grid, id::Int -> Return Cell nr id
  • Grid, v::Union{Vector,String} -> Return all Cells in the set described by v
  • Various EntityNeighborhood -> Returns the cell id, ::Int
• getcelltype
  • Grid -> The grid's celltype (possible abstract)
  • Grid, id::Int -> The concrete celltype of cell id

Ideas for changes

Deprecation and replacement

• getcoordinates->
  • get_node_coordinates(::Node), get_node_coordinates(::Grid, n::Int)
  • get_cell_coordinates(::Grid, ::Int)
• getcoordinates! -> cellcoords! (only get-function with ! ?) (Except Ferrite.get_or_create_dofs! which isn't pure get)
• cellnodes! -> cellnodeids!
• cellid -> getcellid. Add getcellid(Union{FaceIndex,EdgeIndex}
• getcells(::EntityNeighborhood) -> getcellid

Suggestion for new methods

• get_face_coordinates(::Grid, ::FaceIndex)
• get_edge_coordinates(::Grid, ::EdgeIndex)
• getnodeid(::AbstractCell, n::Int) -> As name says
• getfaceid(id::FaceIndex)=id[2]
• get_coordinate_type(::AbstractGrid[, i::Int]), i.e. Vec{3,Float64}

Personal thoughts on naming

• get* is good for getting things, e.g. getnodes
• *! is good for mutating methods, e.g. cellnodes!

I have often wanted to write ndofs=ndofs(dh) ...

Faces, edges, vertices

Tackled in #581, notes here for reference

Edit based on @termi-official's clarification below ([ref](https://github.com/Ferrite-FEM/Ferrite.jl/issues/394#issuecomment-1382419257)) and discussion in [581](https://github.com/Ferrite-FEM/Ferrite.jl/pull/581#discussion_r1070295453) * `vertices` * `Interpolation`: Return the local (algebraic) node indices for the vertices in the reference shape * `Cell`: Return the global node numbers for the vertices in the `Cell` * `edges` (only 3d) * `Interpolation`: Return the local (algebraic) node indices on each edge. Order is (vertex 1, vertex 2, in-betweens...) * `Cell`: Return the global node numbers for the vertex nodes that describe each edge in the `Cell` * `faces` * `Interpolation`: Return the local (algebraic) node indices on each face. Order is (vertex_nodes..., edge_nodes..., face_nodes...) * `Cell`: Return the global node numbers for the vertex nodes that describe each face in the `Cell` (The local (algebraic) node index refers to the coordinate number in the `ip::Interpolation`'s `reference_coordinates(ip)`. However, this is rarely used (currently only in `BCValues` and `apply_analytical!`) Following [581](https://github.com/Ferrite-FEM/Ferrite.jl/pull/581#discussion_r1070295453), this behavior might change in the future and actually refer to the local dof-number.

[termi-official]

Note that I suggest a renaming of vertices, faces and edges in #581 to disambiguate.

Edit: Also note that vertices, faces and edges have different semantics for cells and interpolations.

[KnutAM]

Note that I suggest a renaming of vertices, faces and edges in #581 to disambiguate.

Nice change!

Edit: Also note that vertices, faces and edges have different semantics for cells and interpolations.

Im not sure if I follow, do you mean something else than that they return global vs local indices?

[termi-official]

For cells the corresponding vertex node indices are returned while for interpolations all local dof indices on the closure of the entity are returned. E.g. for a quadratic triangle with quadratic Lagrange interpolation faces(cell) would return something like ((1,3),(3,2),(2,1)) while faces(ip) returns something like ((1,3,4),(3,2,5),(2,1,6)).

[KnutAM]

Aha, I missed that completely now. Even more important to have different names as you suggest!

[termi-official]

Related comment for reference https://github.com/Ferrite-FEM/Ferrite.jl/pull/743#discussion_r1254353892 : Is the vertex in 1D a face?