[Gmsh] Problems with gmsh 2D quad grids and deal.ii

Johannes Reinhardt Johannes.Reinhardt at unifr.ch
Fri May 31 12:28:36 CEST 2013


Hi,

thanks for looking into this issue.

Indeed, I had linked to the release library of deal.ii 7.3, when I link
to the debug lib I get the internal error in get_quads that you quoted.

Greetings

Johannes

On Thu, 30 May 2013 11:57:50 +0200
Mikhail Artemiev <artemiev.mikhail at gmail.com> wrote:

> Hi,
> 
> I dug into Johannes' issue, and I can confirm that there is something
> strange here. I used deal.II 7.2.0 and svn version (not the latest
> though) and gmsh 2.7.0 on Ubuntu 12.04.
> 
> For both versions (built in debug mode) the error was in function
>     void
> dealii::internal::GridReordering2d::GridReordering::get_quads(std::vector<dealii::CellData<2>
> >&) const The violated condition was: s[1] == s[3]
> The name and call sequence of the exception was:
>     ExcInternalError()
> Additional Information:
> (none)
> 
> Stacktrace:
> -----------
> #0  /home/artemiev/deal.II.dev.orig.new/lib/libdeal_II.g.so.8.0.pre:
> dealii::internal::GridReordering2d::GridReordering::get_quads(std::vector<dealii::CellData<2>,
> std::allocator<dealii::CellData<2> > >&) const
> #1  /home/artemiev/deal.II.dev.orig.new/lib/libdeal_II.g.so.8.0.pre:
> dealii::internal::GridReordering2d::GridReordering::reorient(std::vector<dealii::CellData<2>,
> std::allocator<dealii::CellData<2> > >&)
> #2  /home/artemiev/deal.II.dev.orig.new/lib/libdeal_II.g.so.8.0.pre:
> dealii::GridReordering<2,
> 2>::reorder_cells(std::vector<dealii::CellData<2>,
> 2>std::allocator<dealii::CellData<2> > >&)
> 2>#3  /home/artemiev/deal.II.dev.orig.new/lib/libdeal_II.g.so.8.0.pre:
> 2>dealii::GridIn<2, 2>::read_msh(std::istream&) #4  ./proj:
> 2>GridChecker::check_grid(std::string) #5  ./proj: main
> 2>--------------------------------------------------------
> 
> @Johannes,
> I got the same exception as you:
>    The violated condition was:
>       needed_lines.find(std::make_pair(line_vertices.second,
>       line_vertices.first)) == needed_lines.end()
> for 7.2.0 version built in release mode - did you also launch your
> program linking to the release version of deal.II ?
> 
> What is more interesting - for the case described in code:
>  3---4---5
>  |    |    |
>  0---1---2
> both versions works fine.
> I checked it for the following .msh file:
> 
> $MeshFormat
> 2.0 0 8
> $EndMeshFormat
> $Nodes
> 6
> 1 0 0 0
> 2 1 0 0
> 3 2 0 0
> 4 0 1 0
> 5 1 1 0
> 6 2 1 0
> $EndNodes
> $Elements
> 2
> 1 3 2 0 1 1 2 5 4
> 2 3 2 0 2 5 2 3 6
> $EndElements
> 
> Mikhail
> 
> On Wednesday, May 29, 2013 7:08:49 PM UTC+7, Johannes Reinhardt
> wrote:Hello everyone,
> 
> I encounter problems when trying to load 2D quad meshes generated by
> gmsh into a deal.ii based code. I could roughly find out, what the
> causes of the problems are, but I don't know whether it is a problem
> with gmsh, my use of it, or a problem in deal.ii code. Therefore I
> have sent this mail to the mailing lists of both gmsh and deal.ii.
> The rest of this rather lengthy mail explains my findings in detail.
> 
> I need to calculate a certain quantity as a function of a change in
> the geometry. For this reason I want to generate a large number of
> meshes using gmsh, so I defined some functions in a common file, and
> then use a python script to generate many short .geo files that just
> include the common file and call the function with different
> parameters.
> 
> The meshes are 2D quad meshes, because my calculation, that is based
> on deal.ii, which can only deal with quad meshes. The meshes are
> relatively detailed already, because I do not use adaptive refinement
> and need a good approximation of the curved boundaries of the various
> surfaces.
> 
> However when I try to load the resulting .msh files in my calculation
> (which uses deal.ii), some of the meshes fail to load. Of the
> 294 meshes I generated, 39 fail.
> 
> Of these 31 fail with the error message:
> 
> The violated condition was:
> n_negative_cells==0 || n_negative_cells==cells.size()
> 
> and 8 fail with the error message:
> 
> The violated condition was:
>     needed_lines.find(std::make_pair(line_vertices.second,
>     line_vertices.first)) == needed_lines.end()
> 
> The first error seems to be connected to by a cell orientation
> issue that leads to a invalid cell:
> http://www.dealii.org/7.3.0/doxygen/deal.II/classGridReordering.html#ae3a479aa86fabf1f761ab05eb1e42838
> 
> The second seems to be due to a vertex ordering problem, I quote from
> deal.II/source/grid/tria.cc around line 1640, where the error is
> thrown:
> 
> // assert that the line was
> // not already inserted in
> // reverse order. This
> // happens in spite of the
> // vertex rotation above,
> // if the sense of the cell
> // was incorrect.
> //
> // Here is what usually
> // happened when this
> // exception is thrown:
> // consider these two cells
> // and the vertices
> //  3---4---5
> //  |   |   |
> //  0---1---2
> // If in the input vector
> // the two cells are given
> // with vertices <0 1 4 3>
> // and <4 1 2 5>, in the
> // first cell the middle
> // line would have
> // direction 1->4, while in
> // the second it would be
> // 4->1.  This will cause
> // the exception.
> 
> The first error seems to be rather common, when looking it up, I found
> a tool to postprocess .msh files to resolve it:
> https://code.google.com/p/tethex/
> 
> When using this tool with my meshes, the first error is indeed
> avoided, and of my 294 meshes, but now 9 meshes fail with the second
> error, so for one file the first error masked the second one.
> 
> I use deal.ii 7.3 and the Linux 64 bit release of gmsh 2.7.1 on
> Xubuntu 13.04 64bit.
> 
> I have attached some files from my investigations:
> 
> common_params.geo contains functions that are used to build the
> geometry and common parameters.
> generate_geo.py is used to generate individual .geos that include
> common_params
> make_meshes.sh is a shell script that sets up directories, runs the
> python scripts, runs gmsh and runs tethex
> mass_grid.cc is a small snippet that uses the deal.ii grid classes to
> load meshes and logs what is going wrong
> failure.log is a log about which .msh files can not be loaded with and
> without using tethex and why.
> 
> I uploaded a selection of the msh files that should cover all the
> cases here (~3MB):
> 
> http://ist-dein-freund.de/geometries.tar.gz
> 
> Thank you for your efforts in advance
> 
> Johannes



--