"Zigzagging" side sets in ExodusII 2.5D mesh output

[lindsayad]

Discussed in #24630

^{Originally posted by ln53 June 8, 2023}
I've been generating disjoint 2D meshes in 3D space using Gmsh. After the mesh has been processed by MOOSE (and opened in ParaView), the side sets (which should be straight along the edges) are in the pictured "zigzag" or "stitched" pattern.

• This happens using Gmsh physical groups to specify sidesets, as well as ParsedGenerateSideset, SideSetsFromNormalsGenerator, and various other side set generators.
• It only seems to happen when there are multiple disjoint meshes in 3D - individual 2D meshes or disjoint & coplanar 2D meshes both behave as expected.
• MWE image and code under dropdowns below.

Mesh generation with Gmsh Python API

import gmsh
occ = gmsh.model.occ
gmsh.initialize()

occ.addRectangle(0, 0, 0, 1, 1)
occ.addRectangle(0, 0, 0.5, 1, 1)
occ.synchronize()

gmsh.model.addPhysicalGroup(1, [1], name="MWE_Sideset")
gmsh.option.setNumber("Mesh.MeshSizeMax", 0.1)
gmsh.option.setNumber("Mesh.SaveAll", 1)
gmsh.model.mesh.generate()
gmsh.write("MWE.msh")

MOOSE input file mesh block

[Mesh]
  [mesh]
    type = FileMeshGenerator
    file = 'MWE.msh'
  []
  #   [sideset2]
  #     type = SideSetsFromNormalsGenerator
  #     input = mesh
  #     normals = '1 0 0'
  #     new_boundary = 'MWE_Sideset2'
  #   []
  #   [sideset3]
  #     type = ParsedGenerateSideset
  #     input = mesh
  #     combinatorial_geometry = 'x = 0 & z = 0'
  #     new_sideset_name = 'MWE_Sideset3'
  #   []
[]

[lindsayad]

I wish I could transfer this issue to another organization 😦

[roystgnr]

I can reproduce this, and with a pure libMesh code; the problem's got to be at that level. The get_boundary_info().add_side code in gmsh_io.C looks utterly straight-forward, but I'll get in there in gdb and see if I can figure out what's going on.

[roystgnr]

I'm horribly confused by this. When I ncdump the output exodus file, I see that all the sideset entries are on side 3. When I look at the corresponding triangles, they're numbered counter-clockwise with "lower right node", "upper node", "lower left node" ordering. When I look at the ExodusII docs, they agree with libMesh convention (except for the 1-based vs 0-based counting), so side 3 should be between those lower nodes. So the file looks perfectly correct. But Paraview is showing me the same jaggies it's showing you.

[roystgnr]

Yeah, this looks like a paraview bug to me. I took the upper layer out of the python script, to output a MWE_flat.e. I did ncdump MWE_flat.e > MWE_flat.ncdump; cp MWE_flat.ncdump MWE_flat_moved.ncdump. I edited num_dim = 3 and added coordz to the latter (setting it equal to coord y, so the output would still be planar but no longer XY). I did ncgen -o MWE_flat_moved.e < MWE_flat_moved.ncdump ... and whereas paraview MWE_flat.e has the sidesets perfectly correct, paraview MWE_flat_moved.e has the jaggies.

I wish I could transfer this issue to another organization

After your third wish can I have the lamp?

[roystgnr]

Linking #24630 (reply in thread) so it doesn't get missed from this side of things.

We don't have a problem with gmsh 2.5D input; we have a problem with ExodusII 2.5D output. "The same mesh visualizes differently in Paraview when you just change num_dim from 2 to 3" would be pretty damning ... except that the definition of ExodusII triangle data changes when you just change num_dim from 2 to 3 ( https://sandialabs.github.io/seacas-docs/html/element_types.html#tri ), and we need to change our definitions accordingly.