On Thu, May 11, 2017 at 8:27 AM, Roy Stogner <royst...@ices.utexas.edu> wrote:
> > On Thu, 11 May 2017, John Peterson wrote: > > On Thu, May 11, 2017 at 7:12 AM, Harshad Sahasrabudhe <hsaha...@purdue.edu> >> wrote: >> >> Thanks for your help. The problem was solved. I had tets and >> triangles in >> my mesh file initially, which was causing the mismatch in number of >> elements between 2 processors. I removed the triangle elements and >> the >> error went away. >> >> Those lower dimensional elements were probably there for a reason, >> though, like specifying boundary conditions. >> > > Is that how we decided to interpret those in the Gmsh case? Not as > overlapping boundary elements? We can do either. b4a9a2c2 added the ability for libmesh to recognize the "lower_dimensional_block" tag as a block of lower dimensional elements rather than just as specifying BCs. Newer versions of libmesh should properly support reading Gmsh files >> with lower dimensional elements. >> > > That's what I thought, too, but > https://github.com/libMesh/libmesh/pulls?utf8=%E2%9C%93&q= > is%3Apr%20is%3Aclosed%20gmsh > doesn't seem to find any relevant fixes that post-date 0.9.5 You're right, the commit above did appear in 0.9.5. But, there was also a refactoring in ed27c808 that might have inadvertently also fixed a bug, that one only appeared in 1.0.0. More recently there was 383d013d which fixed a bug where only a single lower-dimensional element per side was read in that could also be related to the number of elements being off... -- John ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
