Javier,
Thanks for explaining how you fixed your mesh. The required work seems to be
is considerable, though.
Actually, deal.II is not aware of line orientations in gmsh at all. It only
reads a list of vertex indices for each quad from the gmsh file. Obviously,
the orientation of that list as written by gmsh is influenced by the line
orientations, however.
The annyoing thing is that deal.II is capable of detecting this kind of
problem and inverting the order of vertices for each quad that requires this.
After that operation has been aplied to all cells, the data is available for a
perfectly valid mesh, but before that mesh can actually be created an
additional test checkes whether a) none or b) all quads had to be modified. In
case some were OK while others were modified the code exits, although in the
particular case at hand that is not necessary.
The reasoning behind that behavior is the asumption, that any given code that
writes a mesh uses a fixed orientation - either clockwise or anti-clockwise.
If that were true, a mixture of both orientations would hint at a serious
problem. However, for gmsh this assumption is obviously not valid, it seems to
be easy enough to create a mesh that has both orientations.
I would argue that the mentioned check should therefore be removed. I have
seen other cases (in 3D block-structured meshes) where the underlying
assumption was not valid and I had to modify the code correspondingly.
Any comments?
Best regards,
Tobias
Am Montag, 26. September 2011 18:56:42 schrieb Javier Muñoz:
> Hi
>
> Sorry for the delay, I was a little bussy with some homework.
>
> Apparently deal.ii needs the cell vertices given in anticlockwise
> sense. The points define the vertices but the lines and line loops
> define the sense. So, for example consider the next cell:
>
> p1 ----------- p2
>
>
>
>
> p4 ------------ p3
>
> I could define the lines as (in gmsh format):
>
> l01 = newl; Line(l01) = {p01,p02}
> l02 = newl; Line(l01) = {p02,p03}
> l03 = newl; Line(l01) = {p03,p04}
> l04 = newl; Line(l01) = {p04,p01}
>
> So, the lines sense would be:
>
> p1 ----------> p2
> ^ |
>
> | v
>
> p4 <----------- p3
>
> If I a line loop with this lines:
>
> ll01 = newll; Line Loop(ll01) = {l01,l02,l03,l04}
>
> and then I define a surface I would receive the error message when I try
> to import the cell into deal.ii.
>
> To correct the error I can redefine the lines:
>
> l01 = newl; Line(l01) = {p04,p03}
> l02 = newl; Line(l01) = {p03,p02}
> l03 = newl; Line(l01) = {p02,p01}
> l04 = newl; Line(l01) = {p01,p04}
>
> or redefine the line loop:
>
> ll01 = newll; Line Loop(ll01) = {-l01,-l02,-l03,-l04}
>
> In this way I obtain a cell in anticlockwise sense:
>
> p1 <---------- p2
>
> | ^
>
> v |
> p4 -----------> p3
>
>
> And then deal.ii accept the cell.
>
> The problem was that I defined randomly the sense of lines and line
> loops because I wasn't aware of this requirement. So, after a couple of
> hours fixing the lines deal.ii accepted my mesh.
>
> Of course you need to do this with all the line loops and surfaces in
> your grid.
>
> I hope you find this helpful.
>
>
> Best regards
> Javier Muñoz
>
> El lun, 26-09-2011 a las 15:04 +0100, Ted Kord escribió:
> > Hi,
> >
> >
> > Could you possibly let me know how you re-ordered the vertices in the
> > gmsh file?
> >
> >
> > Regards,
> >
> >
> > Ted
> >
> >
> > On 25 September 2011 23:55, Javier Muñoz <[email protected]>
> > wrote:
> > Thank you for your answer. You are right, it was an error in
> > the
> > vertices order. I reorder them again and I was able to import
> > the mesh
> > into deal.ii.
> >
> > Regards
> > Javier Muñoz
> >
> >
> >
> > El dom, 25-09-2011 a las 16:10 -0500, Wolfgang Bangerth
> >
> > escribió:
> > > > Then, when I tried to import the mesh into deal.ii and it
> >
> > gave the
> >
> > > > error:
> > > >
> > > > terminate called after throwing an instance of
> > > > 'dealii::StandardExceptions::ExcInternalError'
> > > > what():
> >
> > --------------------------------------------------------
> >
> > > > An error occurred in line <642> of file
> > > > </home/zerpiko/FEM/deal.II/source/grid/grid_reordering.cc>
> >
> > in function
> >
> > > > static void dealii::GridReordering<dim,
> > > > spacedim>::invert_all_cells_of_negative_grid(const
> > > > std::vector<dealii::Point<spacedim> >&,
> > > > std::vector<dealii::CellData<dim> >&) [with int dim = 2,
> >
> > int spacedim =
> >
> > > > 2]
> > > > The violated condition was:
> > > > n_negative_cells==0 || n_negative_cells==cells.size()
> > > > The name and call sequence of the exception was:
> > > > ExcInternalError()
> > > > Additional Information:
> > > > (none)
> > > > --------------------------------------------------------
> > > >
> > > > I think is something related with reordering cells. There
> >
> > are any other
> >
> > > > restrictions that a mesh must fulfill? Tnks.
> > >
> > > It's hard to tell without a concrete input file. I believe
> >
> > what the error
> >
> > > message is trying to tell you is that the code found that
> >
> > some of your cells
> >
> > > have negative volume since the vertices are specified in the
> >
> > wrong order or
> >
> > > the cell is degenerate, but that not *all* cells have
> >
> > negative volume (in
> >
> > > which case one could simply flip all cells).
> > >
> > > You'll have to take a look at the input file to find out
> >
> > whether it's an error
> >
> > > in the code or whether it's a problem in the input mesh.
> > >
> > > Best
> > > W.
> >
> >
> > -------------------------------------------------------------------------
> >
> > > Wolfgang Bangerth email:
> >
> > [email protected]
> >
> > > www:
> >
> > http://www.math.tamu.edu/~bangerth/
> >
> >
> > _______________________________________________
> > dealii mailing list
> > http://poisson.dealii.org/mailman/listinfo/dealii
>
> _______________________________________________
> dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
>
_______________________________________________
dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
