Question: 'msh2vtu.py' can't output all MaterialIDs for mixed-dimensional physical groups

Hello everyone,

Happy new year.

I have question (may be unstability) about MaterialIDs in .prj file, when I studied the 3D example link.

This example shows that in the case of mixed 2D and 3D mesh. Using ‘msh2vtu.py’, the MaterialIDs can be degined for both the 2D physical groups (planes) and the 3D physical groups (the bulk domain).

However, when I tried another example, typically the tutorial example of Gmsh link of t15.geo, it did not work.

In that case, I can not get MaterialIDs for all physical groups (I only got the MaterialIDs of bulk, the embedded plane and lines were failed to get MaterialIDs). I do not why.

Could you give me some hints?

Best regards,
Luyu

Dear Luyu,

I guess there are some errors or problems in the setting of your conducting msh2vtu.py. Please check the setting correctly before running the msh2vtu.py.

Actually, I use this tool to realize this process, GMSH2OGS. I never used msh2vtu.py yet, so I cannot give more comments about msh2vtu.py. Hope this tool can help you get a right mesh vtu. If you have any question, feel free to type here!

By the way, this part Tools & Workflows would be helpful for you to complete these pre-processings.

Best,
Rui

By the way, I found the geo file provided by you seems to have some differences with mine, but I am not sure whether it is the key, and hope others who are the experts in gmsh can help you.

The situation is that in t15.geo, the physical groups which you are caring about are use

Physical Point(“Embedded point”) = {p};
Physical Curve(“Embdded curve”) = {l};
Physical Surface(“Embedded surface”) = {s};

I don’t know why it uses p, l, and s? I think it should be numbers? So, this geo can only output the MaterialIDs with Physical Volume(“Volume”) = {1} whose index is number 1. It could be the reason why you only got the MaterialIDs of bulk (Volume here), the embedded plane and lines were failed to get MaterialIDs.

I attach the physical groups defined in my 2D geo here:

Physical Surface(“rock_mass”, 30) = {9};
Physical Surface(“fault_zone_1”, 31) = {2};
Physical Surface(“fault_zone_2”, 32) = {3};
Physical Surface(“fault_zone_3”, 33) = {4};
Physical Surface(“hf_1_out_well”, 34) = {5};
Physical Surface(“hf_1_in_well”, 35) = {8};
Physical Surface(“hf_2_out_well”, 36) = {10};
Physical Surface(“hf_3_out_well”, 37) = {11};
Physical Surface(“hf_2_in_well”, 38) = {12};
Physical Surface(“hf_3_in_well”, 39) = {13};

Physical Point(“in_well”, 40) = {2002};
Physical Point(“out_well”, 41) = {2001};

Hope my analysis can help you to find something.

Best,
Rui

By the way, I suggest you can change the topic from “Site Feedback and help” to “Usability” because “Site Feedback and help” is for discussion about this site and its organization. “Usability” is for sharing the using experience with OGS. I think the latter one is more exact for us. :wink:

Best,
Rui

Hello Rui,

Thanks for your advice.
I guess that it may be an unstability issue too. Then I changed the category of this topic to “Unstability”. Hope the developers can notice it.

Best regards,
Luyu

I am going to upgrade msh2vtu soon (it is hard to keep up the pace with the new versions of gmsh and almost impossible to remain compatible with the older versions) and will take a closer look at the handling of lower dimensional elements. The current “philosophy” is that bulk elements (highest dimension) form the domain and thus must have a material, while lower dimensional elements form the boundary and may not have materialIDs. Probably I should introduce a command line flag to enforce a full assignment for cases like yours.

Hello Dominik,
Thanks for the reply. Looking forward to the upgrade.
Best regards,
Luyu