[Libmesh-users] Assertion `mesh.comm().verify(mesh.n_elem())' failed.

[Harshad Sahasrabudhe]

Hi,

I'm trying to import a mesh using the GmshIO class. However, I get the
following error while broadcasting the mesh when I run with 2 processes:

Assertion `mesh.comm().verify(mesh.n_elem())' failed.

[0] src/mesh/mesh_communication.C, line 814, compiled [1]
src/mesh/mesh_communication.C, line 814, compiled Dec 14 2016 at 16:17:32
terminate called after throwing an instance of 'libMesh::LogicError'

Any idea why this could be happening? Here's the backtrace:

#0 0x0000003ab5c32625 in raise () from /lib64/libc.so.6
#1 0x0000003ab5c33e05 in abort () from /lib64/libc.so.6
#2 0x00002b85c16c3b6d in __gnu_cxx::__verbose_terminate_handler () at
/tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/vterminate.cc:95
#3 0x00002b85c16c1bb6 in __cxxabiv1::__terminate (handler=<optimized out>)
at /tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4 0x00002b85c16c1c01 in std::terminate () at
/tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5 0x00002b85c16c1e18 in __cxxabiv1::__cxa_throw (obj=0x13547900,
tinfo=0x2b85c0a27db0 <typeinfo for libMesh::LogicError>,
dest=0x2b85be586574 <libMesh::LogicError::~LogicError()>) at
/tmp/aai/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc:87
#6 0x00002b85c4e24852 in libMesh::MeshCommunication::broadcast
(this=0x7ffe6f69f433, mesh=...) at src/mesh/mesh_communication.C:814
#7 0x00002b85c4f43eaf in libMesh::NameBasedIO::read (this=0x7ffe6f69f640,
name=...) at src/mesh/namebased_io.C:284
#8 0x00002b85c4f74ca8 in libMesh::UnstructuredMesh::read (this=0x17462b0,
name=..., mesh_data=0x0, skip_renumber_nodes_and_elements=false) at
src/mesh/unstructured_mesh.C:589
#9 0x00002b85bfa3a9eb in FEMmacroscopicDomain::build_mesh_orthogonal
(this=0x17456e0) at FEMmacroscopicDomain.cpp:267
#10 0x00002b85bfa39497 in FEMmacroscopicDomain::build_the_domain
(this=0x17456e0) at FEMmacroscopicDomain.cpp:63
#11 0x00002b85bf958853 in Domain::init (this=0x17456e0) at Domain.cpp:343
#12 0x00002b85bfa65b3d in Nemo::init_materials (this=0x63ba80
<Nemo::instance()::impl>) at Nemo.cpp:1201
#13 0x0000000000426ed3 in main (argc=3, argv=0x7ffe6f6a14d8) at main.cpp:440

Thanks!
Harshad

[Roy Stogner]

Post by Harshad Sahasrabudhe
I'm trying to import a mesh using the GmshIO class. However, I get the
Assertion `mesh.comm().verify(mesh.n_elem())' failed.
[0] src/mesh/mesh_communication.C, line 814, compiled [1]

What libMesh release or git hash is this?

Thanks,
---
Roy

[Harshad Sahasrabudhe]

Post by Roy Stogner
What libMesh release or git hash is this?

This is LibMesh 0.9.5.

Harshad

[Roy Stogner]

Post by Roy Stogner
What libMesh release or git hash is this?
This is LibMesh 0.9.5.

More than a year old? Can you replicate the problem either with
libMesh 1.2 or with the git master/HEAD?
---
Roy

[Harshad Sahasrabudhe]

Hi Roy,

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.

Thanks!
Harshad

Post by Roy Stogner
What libMesh release or git hash is this?

Post by Harshad Sahasrabudhe
This is LibMesh 0.9.5.

More than a year old? Can you replicate the problem either with
libMesh 1.2 or with the git master/HEAD?
---
Roy

[John Peterson]

Post by Harshad Sahasrabudhe
Hi Roy,
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. Newer versions of libmesh should
properly support reading Gmsh files with lower dimensional elements.

I would really encourage you to upgrade your code from using libmesh 0.9.5
to a new release as soon as possible... if there is some major issue
preventing you from doing so, we can probably help with resolving it...

[Roy Stogner]

Post by Harshad Sahasrabudhe
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?

Post by Harshad Sahasrabudhe
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

Post by Harshad Sahasrabudhe
I would really encourage you to upgrade your code from using libmesh
0.9.5 to a new release as soon as possible... if there is some major
issue preventing you from doing so, we can probably help with
resolving it...

Agreed.
---
Roy

[John Peterson]

Post by Roy Stogner

Post by Harshad Sahasrabudhe
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

Post by Roy Stogner

Post by Harshad Sahasrabudhe
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...

[Harshad Sahasrabudhe]

Hi Roy and John,

I would really encourage you to upgrade your code from using libmesh 0.9.5

Post by John Peterson
to a new release as soon as possible... if there is some major issue
preventing you from doing so, we can probably help with resolving it...

We will work on upgrading as soon as possible.

I'd still love to get a test case code if you can replicate the error

Post by John Peterson
with libMesh 1.2..

I will test with 1.2 and let you know if this problem still exists.

Thanks!
Harshad

[Roy Stogner]

Post by Harshad Sahasrabudhe
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.

I'd still love to get a test case code if you can replicate the error
with libMesh 1.2... or even if you can boil the problem down to a
short code with 0.9.5; I can see if it replicates on newer libMesh or
not myself. Now that you've discovered more about the problem it's
looking more likely to me that it's in the category "corner case we
should support but don't" rather than "bug we fixed a year ago that
you're just not up to date on yet".

However, if you're too busy I understand; it's definitely not *your*
problem anymore. Even if there is a current bug with Gmsh loading of
multi-manifold meshes, that's only applicable to people who *want*
multi-manifold meshes, and if you don't want a combined volume +
surface mesh then "remove the triangles" is the correct way to avoid
getting one.

Thanks,
---
Roy