Support for node and edge sets

[sebastianpech]

Addresses #6. I know there is already a PR open for this, but I think this is a less redundant implementation for the node sets. I noticed that the tocellsets method is quite general in terms of dim. Supplying the global node number from gmsh directly gives the proper node set definition. So the function can be reused.

Some questions regarding Ferrite grids:

• What are vertex sets? I noticed them in the documentation. I guess this is just a different name and they are interchangeable with node sets.

• I assume node sets can be created independent of the dimension in gmsh. They always exist and are of dim=0.

• I assume edge sets are in a sense dim-2 sets (when face sets are dim-1 sets). So, for dim=2, they are equal to node sets, so I would ignore them in this case and only extract edge sets for dim=3.

• [x] Support node sets

• [x] Support edge sets for (dim == 3)

• [x] Add test cases

[sebastianpech]

Not sure how to deal with tonodes now returning two arguments. It makes sense to do it because toelements does the same, but it breaks compatibility.

[KnutAM]

Recently we have changed the definitions of edges and faces in Ferrite, see description here (https://github.com/Ferrite-FEM/Ferrite.jl/pull/914)

What are vertex sets?

Vertices describe the end-points of edges, while nodes can also be present along an edge, on a face, or inside a volume.

I assume edge sets are in a sense dim-2 sets (when face sets are dim-1 sets). So, for dim=2, they are equal to node sets, so I would ignore them in this case and only extract edge sets for dim=3.

With the new definitions, edges are always 1d entities and faces 2d entities.

Note that the edgesets and facesets are removed from the grid struct and replaced by facetsets.

[sebastianpech]

Recently we have changed the definitions of edges and faces in Ferrite, see description [...]

So, what's your opinion on downward compatibility here? Is it sufficient to just support the latest definitions of Ferrite?

[koehlerson]

I think it's sufficient to use the latest definition and make a compat entry for a new FerriteGmsh version that it only supports 1.0 in the new release

[sebastianpech]

Two things I'm currently uncertain of.

1. How to treat 1-dim physical groups for 3d geometries? They can be defined in gmsh and are edgesets in Ferrite. However, edgesets can't be stored in the grid. Should they be returned eg. by the togrid function as an extra return value?
2. How to deal with nodes vs. vertices? Every vertex is a node but not every node a vertex. We could keep the information twice. So each 0-dim physical group exists as a node and a vertex set (if applicable). Alternatively, everything that is already in a vertex set is not required to be stored in a nodeset. Not sure what the better approach is regarding the intended usage of nodesets in Ferrite.

Edit: Currently, I use the following rule for a model of dimension dim:

• cellsets: global id, physical group of dimension dim (volume, face, edge)
• nodeset: global id, physical group of dimension 0 (node)
• facetset: related to cell, physical group of dimension dim-1 (face, edge, vertex)
• vertexset: related to cell, physical group of dimension 0 (vertex)

[koehlerson]

How to treat 1-dim physical groups for 3d geometries? They can be defined in gmsh and are edgesets in Ferrite. However, edgesets can't be stored in the grid. Should they be returned eg. by the togrid function as an extra return value?

I'd suggest the following: either we add a docstring to todimEntitysets that explains how one can use it for extracting edgesets or we include a separate function that returns a Set{EdgeIndex}. If that exceeds the scope of the PR then I'll open a issue with these things. After https://github.com/Ferrite-FEM/Ferrite.jl/pull/914 edgesets were removed and it's unsure if they will return in Ferrite.Grid. So introducing a changing interface seems odd to me and either we don't offer this functionality or we go the route with a little bit of additional effort with a separate function

How to deal with nodes vs. vertices? Every vertex is a node but not every node a vertex. We could keep the information twice. So each 0-dim physical group exists as a node and a vertex set (if applicable). Alternatively, everything that is already in a vertex set is not required to be stored in a nodeset. Not sure what the better approach is regarding the intended usage of nodesets in Ferrite.

I think if you query 0 dimensional entities from GMSH you always get a nodeset, right? I'd just include it for now as a nodeset, not sure what the use case of vertexsets would be in that case.

[sebastianpech]

I'd suggest the following: either we add a docstring to todimEntitysets that [...]

Sound good to me.

I think if you query 0 dimensional entities from GMSH you always get a nodeset, right? I'd just include it for now as a nodeset, not sure what the use case of vertexsets would be in that case.

Sure, I don't think gmsh supports the concept of a vertex. However, Ferrite.Dirichlet requires vertex sets, right? So I think the node physical groups should definitely be vertex sets for applying BCs. I don't know why one would require node sets that are not vertices as well (Except maybe for reference points or additional DOFs, but I guess that's anyway not yet supported by Ferrite). Edit: Nevermind, I stopped reading after VertexIndex. Nodesets sound good.

[sebastianpech]

• edgesets can now be extracted using an extra function
• I removed support for Ferrite < 1.0; also updated the CI scripts to not test on jl 1.6 (didn't work with Ferrite >= 1.0). The jl version tests run on now match the ones in the Ferrite repo.
• Some minor performance improvements (getfacets.(elements) and getedges.(elements) is using a generator expression now)
• tonodes now returns a second argument just like toelements. I don't think this is strictly necessary, as we do node renumbering anyway, but I just wanted to be sure that there is no mixup with the global node numbering.
• the test examples now include an example for an embedded edge in a 3d box, a 3d example testing node, facet and cell sets and a 2d example testing node, facet and cell sets.