parallel reader for Gmsh mesh file

[WeiliangChenOIST]

At the moment the Gmsh reader read the whole file using rank 0 then redistribute the mesh across the ranks. This solution may not be ideal for large size mesh. Is it possible to implement a parallel reader, in consideration of the new Gmsh 4 format?

[tristan0x]

Gmsh 4.2 introduces a new parallel file format versioned 4.1.

[smelchio]

FYI, gmsh file.geo -3 -part 2 -part_split is the command to generate a mesh that is split into file_1.msh and file_2.msh.

[smelchio]

Dan, do you think that you would have time to support the parallel reader in April?

[ibaned]

Unless its trivial, I don't think so. I have lots of travel in April.

[tristan0x]

Hello @ibaned
Supporting Gmsh parallel file format 4.1 would allow Omega_h to take benefits of Metis partitioning available in Gmsh. Is this something SNL would be interested in? Would you consider supporting it in Omega_h at some point?
Best

[ibaned]

I have no problem with supporting it, but so far the projects I work on either use structured meshes or use the SNL mesh generator (CUBIT), not Gmsh, so I don't think I can get money from them to add this.

[smelchio]

Dear @ibaned
In the following weeks, we need omega_h to be able to import distributed mesh files generated with gmsh. Concerning the two following options:

• either get a strong inspiration of gmsh/Geo/GModelIO_MSH4.cpp by "simply" replacing creation of a gmsh object by the creation of a gmsh object,
• or there is a possibility to offer an optional cmake linkage with the gmsh API to avoid the former "code duplication",
  would you have a comment on, e.g., which one you would favor?
  Sincerely.

[ibaned]

@smelchio I would personally do the first option, the "duplicate" one. This allows users to read the format without building Gmsh on the same machine, and it also avoids issues with Gmsh's GPL license. Still, if you do the second option, I will merge it.