Renumbering nodes fails without error message

[alex-fu27]

I have a mesh file test.unv generated by FreeCAD, which internally also uses GMSH. If I try to load that file, I get this:

julia> using GridapGmsh
julia> model = GmshDiscreteModel("test.unv")

Info    : Reading 'test.unv'...
Info    : Reading nodes
Info    : Reading elements
Info    : Done reading 'test.unv'
ERROR: 
Stacktrace:
 [1] error(s::String)
   @ Base ./error.jl:35
 [2] renumberNodes
   @ ~/.julia/artifacts/4653460f3c6b714482628cbde55e1ca3845b68b4/lib/gmsh.jl:3008 [inlined]
 [3] GmshDiscreteModel(mshfile::String; renumber::Bool, has_affine_map::Nothing)
   @ GridapGmsh ~/.julia/packages/GridapGmsh/ZGvkt/src/GmshDiscreteModels.jl:23
 [4] GmshDiscreteModel(mshfile::String)
   @ GridapGmsh ~/.julia/packages/GridapGmsh/ZGvkt/src/GmshDiscreteModels.jl:12
 [5] top-level scope
   @ REPL[4]:1

Which is pretty unfortunate, as I would have expected an error message so that I know what I need to change to fix the file.

I have Julia 1.10.1 and GridapGmsh 0.7.2.

Any help is appreciated, so I attached the mesh file. However, you will have to remove the .txt ending that I had to add to make Github accept the upload:
test.unv.txt

[JordiManyer]

The function that fails, renumberNodes is not ours. It comes from Gmsh, so you can have a look at their documentation. If you want an error message, you should talk to them.

There is also the option to not renumber, by setting renumber=false in

GmshDiscreteModel(mshfile; renumber=true, has_affine_map=nothing)

One comment about CAD softwares is that, to my understanding, they do not produce water-tight meshes. This might be the issue you are having here.

[alex-fu27]

Sorry, I forgot to mention with renumber=false it will fail with "Only consecutive elem tags allowed."

I've had a look at Gmsh's API, and indeed, the wrapper swallows all exceptions, so neither you nor me can know what's going on without patching Gmsh. I'll try to open an issue in their tracker (if they let me create an account there, that is) and close this one.

You are right about the CAD software. FreeCAD internally writes a .geo script to load a BREP file into Gmsh and write an .unv file, so I assumed that if I export the mesh as .unv, it will use that exact file, which is wrong. It somehow breaks the mesh on the way. But one can steal the file Gmsh has written from the temp directory, and that file can be loaded, but only with renumber=false, and then it will be corrupted. It loads fine in FerriteGmsh though. I will check back as soon as I have found out what makes the difference.

[JordiManyer]

with renumber=false it will fail with "Only consecutive elem tags allowed."

This happens in the following situation:

elemTypes, elemTags, nodeTags = gmsh.model.mesh.getElements(d)

nmin = minimum( minimum, elemTags )
nmax = maximum( maximum, elemTags )
ncells = sum([length(t) for t in elemTags])
if !( (nmax-nmin+1) == ncells)
  gmsh.finalize()
  error("Only consecutive elem tags allowed.")
end

From the manual:

so as I understand it, the elemTypes is a very short vector with the different types of elements you have (triangles, quads) and elemTags has for each type of element the list of cell ids for the cells of that type.

The issue with your mesh would then seem to be that your cell ids are not contiguous, i.e your CAD generator is missing some ids (or deleting some of the cells without renumbering the remaining ones).

It then makes sense that renumbering would solve this issue, but gmsh seems to have problems doing just that.

@alex-fu27