gmsh, parallel - reads #partitions an element is part of

Issue #38 resolved
Alex created an issue

Hi,

when reading files partitioned with gmsh via

  std::string l_loadOpts = "PARALLEL=BCAST_DELETE;";
              l_loadOpts += "PARTITION;";
              l_loadOpts += "PARALLEL_RESOLVE_SHARED_ENTS;";

  // load the mesh
  l_error = m_core.load_file( i_pathToMesh.c_str(), &m_mesh, l_loadOpts.c_str() );
  checkError( l_error );

moab reads the "third number" in

number-of-tags

    gives the number of integer tags that follow for the n-th element. By default, the first tag is the number of the physical entity to which the element belongs; the second is the number of the elementary geometrical entity to which the element belongs; the third is the number of mesh partitions to which the element belongs, followed by the partition ids (negative partition ids indicate ghost cells). A zero tag is equivalent to no tag. Gmsh and most codes using the MSH 2 format require at least the first two tags (physical and elementary tags).

http://gmsh.info/doc/texinfo/gmsh.html

This happens in line 294 of ReadGmsh.cpp:

    id_list.push_back(int_data[0]);
    part_set_list.push_back(tag_data.size() > 2 ? tag_data[2] : 0);
    geom_set_list.push_back(tag_data.size() > 1 ? tag_data[1] : 0);
     mat_set_list.push_back(tag_data.size() > 0 ? tag_data[0] : 0);

Can be fixed by reading 3 instead of 2 (not sure of side effects):

    part_set_list.push_back(tag_data.size() > 3 ? tag_data[3] : 0);
    geom_set_list.push_back(tag_data.size() > 1 ? tag_data[1] : 0);
     mat_set_list.push_back(tag_data.size() > 0 ? tag_data[0] : 0);

For the sake of completeness, here's the gmsh-geo ifle, attaching the mesh file:

// optimize mesh
Mesh.Lloyd=5;

// define mesh size
size = 9.424777960769379715387930149838508652591508198125317462924;

// define characteristic length
lc = 0.93;

//
// construct the square
//
Point(1) = { 0,    0,    0, lc };
Point(2) = { size, 0,    0, lc };
Point(3) = { size, size, 0, lc };
Point(4) = { 0,    size, 0, lc };

Line(1) = {1, 2};
Line(2) = {2, 3};
Line(3) = {3, 4};
Line(4) = {4, 1};

Line Loop(101) = { 1, 2, 3, 4};
Plane Surface(201) = {101};

// define volume
Physical Surface("region_0") = {201};

mesh generated with

gmsh -2 mesh.geo -part 3

 gmsh --version
2.12.0

moab-version: 4.9.0

Comments (8)

  1. Vijay M

    Sorry about the delayed response Alex. I think we have not kept the Gmsh I/O reader to conform to the new changes. I'm swamped with couple of other things now and won't be able to get to this until mid-August. However, if you have some changes, please feel free to submit a PR.

  2. Alex reporter

    Vijay,

    thanks for looking into this. Mid-August sounds good. The workaround above works until then. Will submit something if time allows, unlikely though.

  3. Vijay M

    This has been fixed I think. Alex, can you confirm ? We are releasing 4.9.2 tomorrow and just want to confirm if you are able to verify. If this is fixed, please close the issue.

  4. Alex reporter

    Vijay, this is excellent news!

    Alex, can you confirm ?
    

    i am occupied for the next 1-2 weeks; will come back to you later this month.

  5. Vijay M

    Alex, I'll wait for your confirmation but the fixes made it to the last release. So if you can verify, we'll mark this as resolved.

  6. Log in to comment