[Gmsh] Problems with gmsh 2D quad grids and deal.ii
Christophe Geuzaine
cgeuzaine at ulg.ac.be
Tue Jul 9 14:22:53 CEST 2013
On 29 May 2013, at 21:30, Christophe Geuzaine <cgeuzaine at ulg.ac.be> wrote:
>
> Hi Johannes,
>
> It seems that for some reason Gmsh does not (sometimes...) orient the meshes of some of the surfaces according to the orientation of the corresponding CAD surfaces.
>
> We'll need to investigate what looks like a bug.
>
Dear Johannes,
There was indeed a bug in Gmsh, where in some cases the normal of a plane surface defined with Gmsh's internal CAD engine was not computed correctly (it was swapped).
Could you try the new Gmsh 2.8 and let us know if everything is ok ?
Thanks again for the report,
Christophe
> Thanks for the report,
>
> Christophe
>
> On 29 May 2013, at 14:08, Johannes Reinhardt <johannes.reinhardt at unifr.ch> 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
>> <common_params.geo><failure.log><generate_geo.py><make_meshes.sh><mass_grid.cc>_______________________________________________
>> gmsh mailing list
>> gmsh at geuz.org
>> http://www.geuz.org/mailman/listinfo/gmsh
>
> --
> Prof. Christophe Geuzaine
> University of Liege, Electrical Engineering and Computer Science
> http://www.montefiore.ulg.ac.be/~geuzaine
>
>
>
>
> _______________________________________________
> gmsh mailing list
> gmsh at geuz.org
> http://www.geuz.org/mailman/listinfo/gmsh
--
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science
http://www.montefiore.ulg.ac.be/~geuzaine