Unexpected block_id assignment (0) when importing Gmsh mesh with physical groups 1/2/3

[hityyds]

Hi,

I’m encountering a block_id mismatch while importing a Gmsh mesh and would like to clarify OpenSN’s indexing convention. After importing a Gmsh mesh file where all volumetric physical groups are tagged as 1/2/3 (no tag 0 exists), GDB debugging reveals cells assigned to block_id=0:

(gdb) p cell
$8 = (const opensn::Cell &) @0x555556de76f0: {
  _vptr.Cell = 0x7ffff6de1200 <vtable for opensn::Cell+16>, global_id = 5328, 
  local_id = 5328, partition_id = 0, block_id = 0, 

Does OpenSN automatically ​decrement Gmsh’s physical group tags by 1 when assigning block_id values (i.e., converting 1-based Gmsh tags to 0-based indices)? This would explain why my physical group 1 maps to block_id=0.

Thank you in advance for your guidance and support!

[wdhawkins]

Hello. I'll look into this problem and see about getting it fixed. Can you send me your input and mesh?

[hityyds]

It appears OpenSN does convert 1-based Gmsh physical group tags to 0-based indices. After decrementing all physical group tags by 1 in my Lua script, OpenSN executed successfully. Attached are my input files and mesh for troubleshooting. Thank you for looking into this.
Uploading test.zip…

[wdhawkins]

Thanks! I've identified the problem, and I have a fix in the works. I'll test my changes with your input as well and let you know when the fix has been merged.

[wdhawkins]

I wasn't able to download your input and mesh, but I have merged a fix for this issue. You'll need to pull your working copy up to the current version of main. Note that the default user interface in the latest version has switched from Lua to Python. To configure the code to use the older Lua interface, do the following: cmake -DOPENSN_WITH_LUA=True ... Please let me know if the latest version of the code fixes your issue.

[hityyds]

Thank you, the updated code has resolved the issue. I successfully configured the code with -DOPENSN_WITH_LUA=True as suggested and verified the fix. Appreciate your prompt resolution of this!

However, during compilation I encountered the following warning in the test suite:

opensn/test/unit/framework/mesh/mesh_mapping_test.cc:71:10: warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wdangling-else]
   71 |       if (!found_mapping)
      |          ^

While I've reviewed the relevant code and can confirm the functionality remains unaffected, I wanted to formally report this compiler warning for completeness. The build completed successfully regardless. Appreciate your attention to these details.

[wdhawkins]

Thanks for the report. I'll go through and fix any compiler warnings that have cropped up.