mfem: Broken MFEM mesh format v1.1

In PETSc, me and @dalcinl have used MFEM v1.1 to visualize meshes for years.

Currently, MFEM master will always force to use the NCMesh extension, see e.g. https://github.com/mfem/mfem/blob/master/mesh/mesh.cpp#L3472 even if the mesh is conforming. This is causing issues in parallel, see eg the valgrind stack trace of the glvis command

==1990783== Invalid write of size 4
==1990783==    at 0x55F316: mfem::NCMesh::LegacyToNewVertexOrdering(mfem::Array<int>&) const (/home/szampini/Devel/glvis-fork/mfem/mesh/ncmesh.cpp:5996)
==1990783==    by 0x636CD5: mfem::GridFunction::LegacyNCReorder() (/home/szampini/Devel/glvis-fork/mfem/fem/gridfunc.cpp:3706)
==1990783==    by 0x6374B7: mfem::GridFunction::GridFunction(mfem::Mesh*, std::istream&) (/home/szampini/Devel/glvis-fork/mfem/fem/gridfunc.cpp:70)
==1990783==    by 0x52B9C6: mfem::Mesh::Loader(std::istream&, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) (/home/szampini/Devel/glvis-fork/mfem/mesh/mesh.cpp:3621)
==1990783==    by 0x535B06: Load (/home/szampini/Devel/glvis-fork/mfem/mesh/mesh.hpp:737)
==1990783==    by 0x535B06: mfem::Mesh::Mesh(std::istream&, int, int, bool) (/home/szampini/Devel/glvis-fork/mfem/mesh/mesh.cpp:3268)
==1990783==    by 0x431865: ReadInputStreams(StreamState&) (/home/szampini/Devel/glvis-fork/glvis.cpp:1606)
==1990783==    by 0x42D8CD: main (/home/szampini/Devel/glvis-fork/glvis.cpp:1289)
==1990783==  Address 0x5c09440 is 0 bytes after a block of size 32 alloc'd
==1990783==    at 0x483A582: operator new[](unsigned long) (/builddir/build/BUILD/valgrind-3.16.1/coregrind/m_replacemalloc/vg_replace_malloc.c:431)
==1990783==    by 0x439697: New (/home/szampini/Devel/glvis-fork/mfem/mesh/../general/mem_manager.hpp:468)
==1990783==    by 0x439697: New (/home/szampini/Devel/glvis-fork/./mfem/general/mem_manager.hpp:699)
==1990783==    by 0x439697: Memory (/home/szampini/Devel/glvis-fork/mfem/linalg/../general/mem_manager.hpp:178)
==1990783==    by 0x439697: mfem::Array<int>::GrowSize(int) (/home/szampini/Devel/glvis-fork/mfem/fem/../linalg/../general/array.hpp:648)
==1990783==    by 0x55F3DE: SetSize (/home/szampini/Devel/glvis-fork/mfem/mesh/../general/array.hpp:669)

This is because RemoveUnusedVertices() is called. If we compile GLVis using MFEM v4.2, we are able to visualize all meshes (conforming or nonconforming) we want.

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 15 (13 by maintainers)

Most upvoted comments

Here is another reproducer, using the mesh at https://gitlab.com/petsc/petsc/-/blob/main/src/snes/tutorials/output/ex12_glvis_2d_hex_p0.out (output from a PETSc DMPLEX). Using the current master in MFEM and examples/ex1p. (this issue is independent of the visualization, it is a Mesh loading issue in MFEM)

With v1.1 as version

With v1.0 as version

stefanozampini on Mar 24, 2021

Here you have a reproducer that emulates how PETSc and our solver interacts with GLVis. You need netcat to run it (nc command).

You need the following two mesh files. This is a 2D mesh with just two quads partitioned in two.

filename: test-mesh.000000

MFEM mesh v1.1

dimension
2

elements
1
1 3 0 2 4 1

boundary
0

vertices
6
nodes
FiniteElementSpace
FiniteElementCollection: L2_T1_2D_P1
VDim: 2
Ordering: 1

 0.0000e+00 0.0000e+00
 5.0000e-01 0.0000e+00
 0.0000e+00 1.0000e+00
 5.0000e-01 1.0000e+00

filename: test-mesh.000001

MFEM mesh v1.1

dimension
2

elements
1
1 3 0 1 3 2

boundary
0

vertices
6
nodes
FiniteElementSpace
FiniteElementCollection: L2_T1_2D_P1
VDim: 2
Ordering: 1

 5.0000e-01 0.0000e+00
 1.0000e+00 0.0000e+00
 5.0000e-01 1.0000e+00
 1.0000e+00 1.0000e+00

Launch glvis in server mode (I’ll assume localhost:19916)
Execute the following two commands

{ printf "parallel 2 0\nmesh\n"; cat test-mesh.000000; } | nc localhost 19916 &
{ printf "parallel 2 1\nmesh\n"; cat test-mesh.000001; } | nc localhost 19916 &

Look at the output in the console where you executed glvis, notice the last line, the glvis window never pops up:


       _/_/_/  _/      _/      _/  _/
    _/        _/      _/      _/        _/_/_/
   _/  _/_/  _/      _/      _/  _/  _/_/
  _/    _/  _/        _/  _/    _/      _/_/
   _/_/_/  _/_/_/_/    _/      _/  _/_/_/

Waiting for data on port 19916 ...
double free or corruption (out)

dalcinl on Mar 24, 2021

Yes it most likely is caused by #1392, and I hope it can be fixed by adjusting the v1.1 compatibility code.

jakubcerveny on Mar 23, 2021