Gmesh mesh with Physical Entities

[wcdawn]

Thanks to some help from @cwsmith, I have been able to split a mesh using from_gmsh and zsplit. (Original issue).

In my mesh, I use Physical Entities from Gmsh to specify different material compositions. However, it seems like all elements in the PUMI mesh have the same material. Is there a way to preserve these element material numbers/attributes?

I am using MFEM to work with my mesh so this could also be an issue with the reader there.

[cwsmith]

Hi @wcdawn. I'm glad that worked out.

Do you have a small (?) example gmsh mesh with the different Physical Entities? I found a few gmsh examples here but the few I looked at don't appear to have them.

It looks like our reader supports ascii version 2 legacy formats containing $Nodes and $Elements sections:

http://gmsh.info/doc/texinfo/gmsh.html#MSH-file-format-version-2-_0028Legacy_0029

and discards tags:

core/mds/mdsGmsh.cc

Lines 161 to 164 in 8a38fea

	getLong(r); /* discard physical type */
	long gtag = getLong(r);
	for (long i = 2; i < ntags; ++i)
	getLong(r); /* discard all other element tags */

[wcdawn]

Thanks for the help. Fortunately, my Gmsh files already use the v2.2 legacy format.

I have a series of refined meshes so I can share a coarse one here. If that is too coarse, I have others as well.

[cwsmith]

@wcdawn The from_gmsh utility in the cws/gmshTags branch supports creating an apf tag from the 'physical type' listed for each face and region in the Elements block. Would you please test this with some of your other meshes and let me know if there are any issues? If it looks good I'll merge it into develop.

The screenshot below was created with ./from_gmsh .null marvel_2D_mod_r0.msh marvel.smb. Note, the version of from_gmsh in the branch converts the tag to a field then writes vtu files for loading into paraview. This debugging code will be removed when it is merged into develop.

[wcdawn]

@cwsmith thanks for taking a look at this!

The vtu files look good and I can see the different numbers in the tag field. However, reading the resulting smb file with my MFEM code still only results in one tag/material/region. It looks like this is an error with the MFEM PUMI reader here.

Should I open a new issue in the MFEM repo? It looks like we need something like getTag(ent); instead of setting to a constant value. I can make the changes in MFEM if that's easier, but I don't know what the function call should be.

[cwsmith]

You're welcome. I'll merge the branch into develop and then close the issue.

Yeah, I think an issue in the MFEM repo (that references this issue) is a good idea.

[cwsmith]

@wcdawn Is a geometric model used when creating the gmsh mesh?

[wcdawn]

No. I simply have a Gmsh input file and use .null when generating the PUMI mesh.

[cwsmith]

OK. Thank you. We can proceed without it.

[cwsmith]

The cws/gmshTags branch was merged into develop (59e207b). develop will be merged into master tomorrow morning if the nightly tests pass.

[cwsmith]

cws/gmshTags was merged into master 19185e9