error when importing .msh file

[samuelpmish]

Hi, I'm trying to use FEMAddOns for its ability to import different kinds of meshes. I use mostly fTetWild to generate tet meshes, and they output gmsh's .msh format. When I try to import these meshes into Mathematica with ImportMesh[] I get a bunch of error messages:

gmsh is able to read these meshes-- are they ill-formed or is there a bug/incompatibility in FEMAddOns' importer?

Here's the mesh used to produce the error messages above:
octane.zip

---

Also, on an unrelated note, the airplane mesh in the readme is cool! Is it possible to get access to that mesh (I didn't see it in the Resources directory)

[ruebenko]

This is a binary file format of the msh file. Can you generate a text version and try that? The binary version is not implemented; though it should give a better error message in that case. I worst case you could try to export the binary file as a text file from GMSH?
The airplane comes from https://github.com/c3m-labs/ImportMesh which has been absorbed by the FEMAddOns.
What may also be of interest to you, though I have not tired is the https://github.com/c3m-labs/GmshLink
Lastly, what is you experience with fTetWild, how is it better then then TetGen (used by Mathematica)?

[ruebenko]

OK, I have added a check and a message that the binary file format is not supported. If you feel like adding support for the binary file format, please contact me. Also, if you find out how to make fTetWild generate an ASCII version or how to convert the binary file format to an ASCII version with GMSH, let me know and I can add that information to the documentation.

[samuelpmish]

Lastly, what is you experience with fTetWild, how is it better then then TetGen (used by Mathematica)?

It works well in my (limited) experience. In most cases, it seems to produce better quality meshes than TetGen and considerably faster too. The potential downside is that it doesn't guarantee meshes that strictly conform to the boundary representation (there is a parameter that controls how closely the output should agree with the boundary geometry, similar to DiscretizeRegion's AccuracyGoal)

If you feel like adding support for the binary file format, please contact me.

I'm writing some gmsh import/export tools in a C++ project right now, but once I get those working I could try to get a Mathematica version as well (or C++ library with Mathematica bindings is another option). I think there's value in supporting the binary flavor of gmsh files.

Out of curiosity-- any chance some of these features (e.g. ImportMesh) make it directly into Mathematica?

[ruebenko]

Having a C++ interface would be useful, I think. Contributions of this kind a very welcome.

Concerning the boundary position, we have some internal code in the FEM context that improves the position of boundary mesh nodes, if a symbolic region description is given. (See here) The call signature is ImproveBoundaryPosition[mesh, region]. It works very well in 2D, it depends on the geometry for 3D, but give it a shot.

Concerning moving functionality into Mathematica: That depends on a number of things. First, there may be some license issues that would need to be sorted out, then, secondly and more importantly, for formats that are from commercial vendors, we typically do not have access to the software and I rely on customers to help with these.

Things in FEMAddOns oftern have either a license issue of some sort or are not at the quality as needed to put them in the product. Is there anything else you'd like to see in product besides ImportMesh?