At next week’s International Meshing Roundtable in Buffalo, I’ll be presenting an update on work being done by Nick Wyman and our Applied Research team on something we call MeshLink. The project is all about devising a method for giving CFD flow solvers robust access to B-Rep NURBS geometry models so they can do things like surface mesh adaptation involving point insertion and point movement.

The CFD 2030 Vision Study identifies an “inadequate linkage with CAD” as a pacing item in the development of applied CFD. Beyond the usual geometry model issues of interoperability and suitability for simulation, the Study notes that CFD flow solvers need to evaluate the geometry model (e.g. compute curvatures, project points) and to perform those evaluations in a tightly-coupled, low-overhead manner within a massively parallel computational environment. A perfect example of this need is mesh adaptation during which surface mesh points constrained to the geometry model must be moved or new points inserted.

“Tight coupling between the CFD software and geometry definition is required to enable low-overhead, on-demand, geometry surface information queries within the context of a massively parallel computing framework.” -CFD Vision 2030 Study

Prior work by the authors concluded that just giving geometry kernel software to flow solver developers is not sufficient to robustly meet this need. If it were, the issue would be moot due to the plethora of kernels available today. What is missing is a description of the associativity between the mesh and the geometry model. The mesh a flow solver typically uses is organized and classified only by boundary conditions (e.g. wall, symmetry plane, outflow) and volume conditions (e.g. fluid, porous media, solid). Even if one were to assume that all wall BC mesh points are on the geometry model, there is no data to identify exactly where on the geometry model those points belong (i.e. on which specific surface entities). To make matters more complicated, some surface mesh points are actually constrained to curve entities (often intersection curves) in the geometry model. This additional complication arises from the fact that the computation of intersection curves is a tolerance-based fit of discrete points. Because this tolerance can be on the order of the local mesh edge length (especially when refining the mesh during adaptation), knowing whether mesh points adhere to the intersection curve or one or the other of its parent surfaces is critical to robust use of the geometry model.

In addition to computational robustness, a concise description of mesh-geometry associativity should improve computational efficiency when mesh adaptation is deployed in a massively parallel environment. When a CFD application is deployed across multiple compute nodes, it is likely that only a minority of them will contain geometry-constrained surface meshes. Knowledge of which compute nodes require access to specific geometry model entities will help achieve the goal of low-overhead computations.

An example of MeshLink’s high-level API for accessing B-Rep NURBS geometry.

Therefore, in addition to classification by BC, flow solvers need access to data that classifies the mesh by geometry model associativity. MeshLink is an on-going project to define and deliver this mesh-geometry associativity. MeshLink consists of a schema and an XML implementation that defines the associativity. MeshLink also includes a high-level API that simplifies for flow solver authors geometry evaluations in a kernel-agnostic manner. MeshLink is available at http://www.pointwise.com/meshlink. Being kernel-agnostic, MeshLink can work with virtually any geometry kernel, for example the open-source EGADSlite. Companion software to MeshLink, the Geode geometry kernel (www.pointwise.com/geode), is currently in beta testing by CFD flow solver authors.

See the full IMR agenda here.