SCOREC / core

parallel finite element unstructured meshes
Other
179 stars 63 forks source link

Gmesh mesh with Physical Entities #355

Closed wcdawn closed 2 years ago

wcdawn commented 2 years ago

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 commented 2 years ago

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:

https://github.com/SCOREC/core/blob/8a38feae942ab5a46dc3f9fa393a68884ddddad6/mds/mdsGmsh.cc#L161-L164

wcdawn commented 2 years ago

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 commented 2 years ago

@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.

marvel

wcdawn commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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

wcdawn commented 2 years ago

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

cwsmith commented 2 years ago

OK. Thank you. We can proceed without it.

cwsmith commented 2 years ago

The cws/gmshTags branch was merged into develop (https://github.com/SCOREC/core/commit/59e207bd4a6ddc5b4f47ed0c349e7d5d3cb64929). develop will be merged into master tomorrow morning if the nightly tests pass.

cwsmith commented 2 years ago

cws/gmshTags was merged into master https://github.com/SCOREC/core/commit/19185e9a8590176575721f7057764a4feafe3e4c