Geometry
What does it take to get from a CAD surface to a solvable mesh?
Nothing consumes more calendar time than getting a usable mesh around real geometry, and nothing ties a group more tightly to one vendor. We treat meshing as part of the research problem, because the discretisation and the mesh are not independent choices.
FigureSurface geometry as the solver receives it. Everything downstream — background mesh, carving, projection, partitioning — is generated from this.
Why it is hard
Real surfaces are triangulated, imperfect and aligned with nothing. Fitting a mesh to them means removing cells, projecting vertices and repairing connectivity — and each stage can produce a mesh that looks fine and fails in the solver hours later. The accumulated-sign-error problem is endemic: a normal corrected here, a face loop reversed there, each a latent defect that only appears once two stages are composed.
How we attack it
Replace every local sign convention with one invariant that holds everywhere a face is created or modified. With that in place, projecting a vertex onto a surface is just recomputing geometry — no special cases, no sign guessing. The full path is in-house: background mesh, refinement against the surface, removal by geometric query, projection, partitioning. So the mesh can change to suit the physics rather than the reverse.
What we have established
- A complete surface-to-solver path, validated by running the actual solver on the generated mesh rather than by a quality report.
- One global invariant eliminates an entire class of composition bug and measurably improves closure after projection.
- Hexahedral and tetrahedral paths share the same solver, because the kernels never assume an element type.