[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







More information about the gmsh mailing list