How to represent edges in a sideset more explicitly.

[gsjaardema]

Currently, a Sideset is a list of pairs -- (implicit element id, local side number) where "side" is face for 3D solid elements and an edge for 2D solid elements. For a hex the side number runs from 1 to 6, for a tet it runs from 1 to 4. There has been a kluge added in which if the side number exceeds the number of "sides" (face 3d or edge 2d), then the sideset is referring to edges. This isn't typically used for solid elements (hexes, tets), but is more commonly used for shells. The shell "local side number" would be 1, 2 for the faces and 3, 4, 5, 6 for the 4 edge sides of a quadrilateral shell. [For shells, this has been part of Exodus convention since the beginning, but was extended to refer to the edges of 3D solid elements and the nodes of 2D solid elements]

If we had a sideset over quad shells the element/side pairs of 1.1, 3.1, 5.1, 1.3, 1.4 would consist of 3 quad face sides and 2 edge sides.

This works, but is ungainly since there is offsetting of the local side number by the number of faces. When the IOSS library reads an exodus sideset using this convention, it creates a SideSet and then would create two SideBlocks in the SideSet. The first would be a SideBlock with quad topology and shell parent topology and the second would be a SideBlock with edge topology and shell parent topology. The IOSS would also remove the offset int the local sides on the SideBlock containing edges, so it would show that there are 2 edges, the first is edge 1 of element 1 and the second is edge 2 of element 1.

On output, IOSS would combine the sides in the 2 SideBlocks into a single group and add back the offsets in the local side numbers for the edges and that is what would be stored in Exodus.

One problem with this representation is that it is difficult to look at a sideset [element, local_side] pair and know whether it refers to face topologies or edge topologies.

Some options:

• Continue as is. Most commonly used for shells and they have used this method for a few decades.
• Use a negative side number for edges and positive for faces (or negative for nodes, positive for edges in 2D)
• Modify the current exodus sideset to use sideblocks similar to IOSS and then we have an explicit location to store the topology of the entities in the sideblock. Also makes distribution factors easier,
• Similar to above, but instead of modifying sideset, create a new type "surface" or "boundary" that contains blocks of homogenous topology.

I'm not sure what is the best option. I think that the IOSS layer hides most of the complexity from the applications and there shouldn't need to be any modifications above the IOSS level to deal with any of these changes; I think it would be isolated at the exodus level...

Let me know if I am missing some nuance on the need for #445

[tokusanya]

I think the explanation here for Sidesets is pretty straightforward ... also because I was able to decipher the functionality based on the IOSS code. Part of the confusion for Edgesets was that I could not get a clear picture of what the functional design was based on the code so I simply made the assumption that it followed the same structure as Sidesets (which made sense in my mind) but the code seemed to have subtle enough differences that I had to make some adjustments to compensate in the TextMesh update.

Your explanation in the MR suggests that the creation of the edges is done based on "block" groupings which have homogeneous topologies and the edgesets are arbitrary (possibly heterogeneous) groupings of any set of edges. This sounds like it is the reverse hierarchy of how sidesets are constructed. It wasn't clear from the IOSS code that this was the case but hopefully the documentation you linked will help.

Currently, what I have implements an "edgeset" syntax similar to the creation of sidesets where the user provides [element,ordinal] pairs which represent a (possibly heterogeneous) list of edges that gets split into the edge blocks. So the difference here would be that the sideset is a full grouping of all edges in the edge blocks as opposed to a subset of edges in the list of edge blocks. This could still work in the current framework unless the user really does want to follow the true exodus convention of defining the edge blocks and then the edgesets from the individual edges. That is much harder to implement in TextMesh as what I currently have simply extends what Sidesets are doing...

Note that what I pushed up is a generalized implementation for edgesets regardless of shells or solid elements

[gsjaardema]

A sideset is the only "outlier" in that all other set types are basically a grouping of entity type A over all the blocks containing entity type A (node, edge, face, element). The "nodeblock" is conceptual as there is only a single nodeblock in an exodus file containing all of the nodes.

A "block" (node, edge, face, element) contains entities of a homogenous topology type and all entities must be in one and only one block.

A (node, edge, face, element) set is just a grouping of that type of entities and, as you say, can contain heterogenous topologies. A (node, edge, face, element) can be in 0 or more sets. There is zero or one "distribution factor" per entity in a set (either all in the set have one or all have zero).

A sideset is different in that it isn't representing a grouping of the entities in one or more blocks, it is representing the boundary of the elements in an element block and therefore consists of a pair of identifiers (implicit element id, local side of that element).

For shells, we have had the mixture of face/edge with the local side ranging from 1..6 for quad shells and 1..5 for tri shells since the beginning (I think). The extension to allow that for referencing edges in solid elements was just supported sometime since the beginning of the IOSS library.

There is some question about how to represent a sideset on a beam or truss element. A beam has two "edge" faces 1..2 and 2..1
and a truss has 2 "node" faces -- then ends of the truss. I don't know any code using this although Salinas did talk about it several years ago when Garth was PO.

[tokusanya]

While I set up the grouping of the edgesets and edgeblocks in TextMesh to behave like sidesets, is there any actually any issue with the end result that the user sees in the sense that they provide the heterogenous list of edges via [element, ordinal] pairs in and I provide the edgeblocks that correspond to the unique grouping of these edges? TextMesh is really only designed to prototype small meshes really fast in unit tests and not meant to be any sort of large scale mesh generator.

[gsjaardema]

I think the issue is that code will be written that then assumes a particular inverted behavior of Ioss::EdgeSets and Ioss::EdgeBlocks. If it isn't ever intended for larger use, then why do it; if it is intended for larger use then we have now set a precedence that EdgeSets and EdgeBlocks do not behave in the way they were designed or they have two behaviors depending on something...

I guess I don't understand the argument as to why unit test code doesn't have to conform to the regular behavior... I'm probably understanding the argument incorrectly, but I think that behavior in a unit test which doesn't match the behavior of a real application doesn't help and actually can cause incorrect design decisions...?

[tokusanya]

Ok, let's chat about this some more when I get back (assuming I still have enough brain cells left :D )

[tokusanya]

The STK team is still having issues getting consensus from the app teams primarily due to confusion as to what a a face is. As you you surmised above, getting a consistent representation for sideset entries especially for shells is a tricky thing because specifying an ordinal beyond 2 for a 3D shell can have different meanings. The TF team wants it to reference a face on those collapsed boundaries and the rest of the apps want it to reference the boundary edges.

While IOSS hides most of this, the problem comes in the STK IO layer where a decision has to be made as to what it means. If there was some sort of hybrid interpretation of the first and second bullet where positive ordinals refer to one entity type (edge/face) and negative refers to the other, then it starts to help make distinction between the two.

The third option would be mostly invisible to the user but sounds like it would help unify and make consistent the concept of sidesets/edgesets in both IOSS and Exodus. It is quite a bit to think about and has been giving the STK team lots of problems for months now trying to find some middle ground with the app teams

[gsjaardema]

I guess I don't know how to correctly handle this at the exodus level, or even possibly at the IOSS level. What do we do if there is a couple analysis of TF and SM using the same mesh?

I could see that there would be an "entity attribute" on the sideset which specified that all "edges" are to be treated as "faces", so when read into IOSS it would assign the "correct" topology to the entities in the SideBlock. But down in exodus, they would still be topologically 1D entities with a node on each end and a line in between... I guess I don't see this as a mesh issue other than perhaps an attribute that specifies how a client wants to interpret things...

[tokusanya]

The entity attribute is actually similar to a current proposal where the app team can pass an option down to STK_IO to treat the shell "edges" as either edges or faces. STK_IO could read the attribute and decide what to do in the same way although I suspect that users might still want to override this with an app option.