Future developments for HOHQMesh

This checklist collects a wishlist and/or plan that David and I discussed (in August 2023) for feature development in HOHQMesh. There is no timeline for said features so this issue is planned to stay open indefinitely and be edited accordingly.

Basic functionality:

[x] Fix compilation problems (and possibly testing issues) with the ifort compiler. #76
[ ] Check the handedness of outer curves using the circulation function to ensure right-handedness. This is already done for any of the spline curves of the outer or inner boundaries chains. But such an orientation check should be extended to ensure that all chains have the assumed orientation to ensure that the meshing algorithm is valid.

Mesh quality improvements:

[ ] Improve spline representation of curves. Currently, only cubic splines (or bicubic in 3D) are used. Could use higher order splines to increase the approximation accuracy of boundary curves. High-order splines of fourth or fifth order are straightforward to achieve for 2D meshes, although appropriate (i.e. fast) matrix solves are necessary to compute the spline coefficients.
[ ] 3D mesh smoother for the extruded bottom topography meshes. This process involves a nonlinear optimization problem and some more exploration as to the best (or at least most robust) strategy. Experimental code exists for the optimization procedure using steepest descent. Several open questions exist, such as, the most appropriate shape measure for a "good" element, the optimazation algorithm, and targeting the optimization to a patch of the mesh (as trying to optimize over the entire 3D mesh that contains "good" and "bad" elements tends to lack convergence).
[ ] Readin of CAD file data and using NURBs for the boundary curves. This would increase the mesh quality as well as HOHQMesh's ability but requires the most work. NURBs are complicated and using a library would be preferable rather than re-implementing these basis functions and evaluation routines. As such, this is mainly an outlook point on the checklist. Possibly this might require some additional input/output routines to something like openCascade.

Mesh output improvements:

[ ] Currently, the output of curved 2D edges or 3D faces is duplicated across elements. This is convenient for mesh file read-in procedures, but may cause the mesh files to become quite large. This file size could be reduced if the curved edge or face data was stored separate and only indexed by the curved element flags. However, updating the mesh file format output would require a modification to the mesh file parsing routines within codes like Trixi.jl. Note, changing the mesh file format would be "breaking" in the sense that mesh files in the "old" duplicate style would become unreadable (although maybe we could have different read-in functions based on some kind of flag).
[ ] Mesh file size could be reduced with output to the HDF5 format. We do not want HDF5 as a strong dependency on HOHQMesh so we think this could be achieved in two ways. Either with prerproc compiler flags in the Fortran source of HOHQMesh to isolate the (yet to be written) output routines or the HDF5 output could be handled by the Julia wrapper functionality HOHQMesh.jl via HDF5.jl. Whatever strategy is taken, appropriate mesh file read-in routines would be required for the HDF5 format. For the most part this is left up to the user, however for Trixi.jl users I feel that we would need to provide an HDF5 read-in routine (analogous to the current ASCII read-in) such that the user facing side of Trixi.jl remains consistent.

Flotsam and side projects:

[ ] Further develop the conforming mesh algorithms for embedded material interfaces.
[ ] Ensure proper compilation of HOHQMesh on the PGI Fortran compiler (related to #72)
[ ] Extend HOHQMesh.jl tutorials and documentation for embedded boundary (i.e. multi-material meshes)

trixi-framework / HOHQMesh

Future developments for HOHQMesh #77