Write to Gmsh .msh version 4/4.1

[coopertrucks]

Hello all, I am wondering if there is any interest or need for the mesh converter tool to write to the most up to date version of the .msh file format, which is currently version 4/4.1. I know that gmsh_io can read from versions 2.0 up through 4.0 at least, but only writes to version 2.0 during output. I have found that there is a specific gap here in the capabilities of conversion tools from EXODUS II to the current Gmsh .msh file version, and stumbled upon this while trying to wrangle together reactor meshes for my group's radiation code. I'll probably end up writing a direct converter from EXODUS to our file format, but as it stands I think there's a gap in mesh conversion capabilities that libMesh would be apt to address if implemented.

One 'workaround' I've found is using libMesh to convert from EXODUS to .msh version 2.0, and then using the Gmsh editor to export it as version 4.1 - but I don't think this plays nicely between .msh files in terms of the physical volumes and volumes, and does not do a good job of preserving information from EXODUS like subdomains from MOOSE. Physical groups in Gmsh are important for mapping elements to materials, in our case. Thoughts on writing to the updated .msh version?

[jwpeterson]

I think most of our users are using Exodus and .xdr files for output, since those formats also support writing solutions, and the GmshIO writer does not. So, I don't think there is a lot of demand for writing the latest Gmsh format, but we would of course be open to accepting a patch that adds such support. Out of curiosity, what is your workflow, i.e. what do you end up doing with the Gmsh 4 files once they are written?

[coopertrucks]

Once we have the Gmsh 4 files, we use a converter that writes to our code's specific mesh format and assigns boundary conditions during. Our code only uses tetrahedral elements, and the volume or physical volume info from Gmsh informs the regions our code recognizes. Thank you for the insight, I am not strong enough in C++ to contribute yet - so it seems that getting our converter to read directly from EXODUS to our format is my ticket for the moment.

[jwpeterson]

Since you mentioned MOOSE... are you using MOOSE, but don't actually have a MOOSE-based code? I only ask because there is also the possibility of sidestepping files and file formats altogether if you can call one code directly from the other somehow.

[coopertrucks]

Yes, our code is not MOOSE based and I was hoping to use the meshing utilities in MOOSE for ease of meshing geometries like reactor cores. I do have ambitions to create a MOOSE wrapper for our code so it can be used with MOOSE in the future! So, all of this file conversion business would likely support that effort. If only things were so simple.