Vague input format

[sebmestrallet]

Hello,

First, thank you for opening the source code of your work, which seems impressive. The dependencies are well managed and the code compiled rather easily. My issue is with I/O, where the OVM format is unknown to all mesh-related softwares I use (including meshio). But I have a piece of code to convert the output (hex-mesh OVM to MEDIT). The README says about the input files:

The input tetrahedral mesh can be in VTK or OpenVolumeMesh file format.

Then I tried to convert a mesh to VTK with meshio, but the only options are VTKv4.2 and VTKv5.1, whereas AlgoHex only accepts VTKv2.0 (not specified in the README).

Then I looked at OpenVolumeMesh and the embedded conversion executable, but it only reads Tetmesh or Netgen. I don't use these formats either. So I used meshio once again, but ovm_converter results in parsing error on these files.

Then I thought about OpenFlipper, which is the GUI platform developed by the same team behind OVM, and probably has better I/O support. But it doesn't compile on my work computer (Ubuntu 20) and doesn't work on my personal computer (Windows 10).

Then I tried your code on HexMe, because it is said to be a typical dataset for AlgoHex. Indeed, I managed to hex-mesh a file from HexMe with AlgoHex, which was a VTK file (the 2.0 format). So I dived into HexMe to understand the tetrahedral mesh generation, and Gmsh is behind.

The export performed by Gmsh follows vtk DataFile Version 2.0, in ASCII mode

So I used Gmsh to convert a tetrahedral mesh to VTKv2.0, and AlgoHex filled the console with "End of file reached while searching for input!". So I dived into OpenVolumeMesh to understand why, and the reason is that in VtkColorReader, there is no exit after an unexpected EOF, creating an infinite loop.

But why HexMe VTK files are accepted and not mine? Because HexMe, through Gmsh, writes 2 additional sections, CELL_TYPES and CELL_DATA. CELL_DATA in particular caught my attention:

integer corresponding to the cell color which is related to the CAD feature-entity (cell color and CAD color should be the same)

That means VTK files from HexMe are not only tetrahedral meshes, but also CAD features stored as VTK colors. Are the colors required for AlgoHex? This is not specified. I tried to edit VtkColorReader in OVM sources, to not expect the additional sections and to skip paintMesh() (there is an initializeColor() just before). Now AlgoHex reads my VTK files, but crashes later (in optimize_integer_grid_map() because of a bad assertion on handle validity).

My questions are:

• When you have a mesh file from someone else, how do you convert it to .ovm ?
• If the input tetra mesh of AlgoHex must contain CAD features, can you specify them? and can you update the README: "the input tetrahedral mesh can be in VTK [...] format" is misleading. What you mean is "[...] can be a vtk DataFile Version 2.0 ASCII with CAD features".
• If the input tetra mesh of AlgoHex must contain CAD features, what about .ovm input files? Should they also include CAD feature? In which format? The OVM file format specification is very poor.
• If the input tetra mesh of AlgoHex is not required to contain CAD features, can you update your code in order to accept VTKv2.0 without CAD features?

I hope my findings will help other people, and I look forward to hearing from you.

[HengLiuNotAvailable]

Hi Sébastien, thank you for sharing your detailed feedback! Regarding your questions:

• We convert a mesh file to vtk-2.0 ASCII and read it with OVM. Having a general converter (to .ovm) that supports feature tags is on our todo list. Please don't hesitate to share the file formats that you often use.
• AlgoHex does not expect the mesh to come with feature tags. In this case, it will mark the boundary faces as feature faces and certain edges as feature edges depending on the dihedral angle threshold.
• Same answer as before. The feature tags in ovm files are encoded as properties: "AlgoHex::FeatureEdges", AlgoHex::FeatureFaces", "AlgoHex::FeatureVertices".
• Yes, the vtk reader in OVM didn't handle the case properly when there's no features in the file. I've fixed the problem and created a merge request in OVM. Hopefully, everything works smoothly now.

If you have further questions, I'd be happy to answer :)

[mheistermann]

At some point I started implementing OVM (ASCII) support in meshio, but never finished it (e.g. property handling, which would be necessary for specifying features). It's stuck to some old version of meshio, but I'll just leave this here in case it's useful to somebody. I unfortunately currently don't have the time to rebase + finish it: https://github.com/mheistermann/meshio/tree/feature/openvolumemesh

[sebmestrallet]

Thank you @HengLiuNotAvailable for the quick answer and the merge request.

I mainly use the MEDIT/GAMMA ASCII format (.mesh), which is readable by SALOME, Graphite/Geogram and HexaLab, and the Wavefront format (.obj) for surface triangle meshes.

I tried the latest AlgoHex with the latest OVM, and my VTK tetrahedral meshes, generated by Gmsh, result in an assertion error, or an infinite loop after printing ###ERROR message on numerical issues in KKT system can be ignored!. See attached files VTK_files.zip

Here is the CMake command I used:

cmake .. -DGUROBI_HOME=~/.local/Gurobi/gurobi1003/linux64 -DCMAKE_BUILD_TYPE=Debug -DDISABLE_MPI=1

I found the DISABLE_MPI option in CoMISo. If not disabled, the program fails because of a MPI call before initialization.

[sebmestrallet]

Thank you @mheistermann. A proper meshio support seems too difficult. I will try a simple ASCII to ASCII converter from the MEDIT format, but there is something I don't understand with the specification.

There are 4 sections : Vertices, Edges, Faces and Polyhedra, and faces are referencing half-edges, and polyhedra are referencing half-faces. But there is no half-edge nor half-face sections, so how to get the index of theses elements ? Is $n$ the half-edge/face with the orientation defined for the edge/face $n$, whereas $2n$ is the flipped one?

Or are the Edges and Faces sections enumerating half-edges and half-faces?

[mheistermann]

But there is no half-edge nor half-face sections, so how to get the index of theses elements ? Is n the half-edge/face with the orientation defined for the edge/face n, whereas 2n is the flipped one? Or are the Edges and Faces sections enumerating half-edges and half-faces?

Edges and Faces sections in the .ovm file describe one of each pair of half-entities, namely the one with index 2k; the opposite has index 2k+1 (and is not stored explicitly). In other words, Edges lists halfedges 0, 2, 4, ...

To convert from/to OVM, it's really useful to actually have the OVM datastructure (which is why I implemented a pretty simplistic/bad version of it in python for meshio).

If you're free in your choice of language and can live with a dependency, maybe it makes sense to use C++ and link to OVM.

In the future, we'll definitely want to support a few more common file formats in OVM itself, and supply an extended version of the mesh conversion tool, however I have no timeline for that.

[HengLiuNotAvailable]

Thank you @HengLiuNotAvailable for the quick answer and the merge request.

I mainly use the MEDIT/GAMMA ASCII format (.mesh), which is readable by SALOME, Graphite/Geogram and HexaLab, and the Wavefront format (.obj) for surface triangle meshes.

I tried the latest AlgoHex with the latest OVM, and my VTK tetrahedral meshes, generated by Gmsh, result in an assertion error, or an infinite loop after printing ###ERROR message on numerical issues in KKT system can be ignored!. See attached files VTK_files.zip

Here is the CMake command I used:

cmake .. -DGUROBI_HOME=~/.local/Gurobi/gurobi1003/linux64 -DCMAKE_BUILD_TYPE=Debug -DDISABLE_MPI=1

I found the DISABLE_MPI option in CoMISo. If not disabled, the program fails because of a MPI call before initialization.

AlgoHex expects a pure tetrahedral mesh as input. The u-shape mesh seems to be an invalid input (only part of it is tetrahedralized). B0 works fine on my mac. For the MPI problem, I cannot reproduce the issue (macos and linux).

[sebmestrallet]

Good catch. I don't have the MPI call before init error with the latest version of your code, but it failed anyway. See #3