Additional Mesh Formats To Consider

[JohnBussoletti]

Has anyone considered expanding the various mesh formats that are supported by Libmesh? in particular, CGNS and aflr3 are commonly used in the aerodynamics industry and by NASA. If there is interest, I am familiar with both formats and could develop appropriate extensions to support either reading those formats into Libmesh native data structures or possibly also converting to/from those meshes as well, via the native data structures.

[roystgnr]

We'd love to look at the PRs! I'd bet most of our MeshInput+MeshOutput subclasses got started when someone had a mesh source that they really needed to use but had no code to use it - that's the sort of feature that can be critical when you need it but that's never novel enough to produce a paper or valued enough to be directly funded.

My only suggestion (not even a requirement - I've got a fairly "beggars can't be choosers" mentality about any third-party contributions that don't force refactoring of existing code) is that you think about test coverage of whatever you write. It's sadly easy to get something working for yourself but then have it silently regressed by another developer because you didn't add a test to ensure that it kept working. Mesh format support has been particularly dangerous for that in the past, since it's the sort of code that never gets indirectly tested, so it's either direct use or nothing.

[JohnBussoletti]

Compatibility with aflr2/aflr3/aflr4 formats is straightforward, since the files have a well defined format. CGNS would require inclusion of the CGNS library either within libmesh or as a prerequisite and the CGNS "standard" is a framework within which many different methods of storing the data are possible. It's basically a binary form of XML (created before XML was invented) hosted by two different file system packages, one of which is HDF5. SImsys's aflr3 offers utilities to create a CGNS file from and aflr3 grid file, so that's one potential path to deal with a specific CGNS file structure, either by replicating it or, assuming access to aflr3, use of the utility. I'll take a look at the mesh input and output routines and see what it might take to add the capabilities. By the way, what is know about the performance of libMesh in the context of a Navier Stokes equation solver relative to, say NASA/LaRC's FUN3D?

[roystgnr]

The only direct comparison I can think of to a NASA code was FIN-S vs DPLR, but that was very apples-to-oranges; the fully-coupled libMesh-based hypersonics+radiation+ablation code was much slower per iteration but took far far fewer iterations to converge, so for the quasi-steady cases we were working on it was a big win, 10x faster solves, but for fully transient flows I'd expect something optimized for explicit or ImEx schemes could whip us.