CGAL users discussion list

["Jens K. Becker" <>]

Hi all,

I am very happy to give any information you need to solve the problem (and am
quite sure that in the end I did something wrong somewhere). Here is what I am
trying to do:

1. Make a polyhedron
2. Delete all halfedges that separate facets that are in one plane
  - check if the facet halfedge->facet() and halfedge->opposite()->facet() are
coplanar
  - if they are, use join_facet(halfedge) to delete the corresponding edge and
therewith merge the two facets
3. Retriangulate the polyhedron so that each facet is a triangle

all of that using:
typedef CGAL::Exact_predicates_inexact_constructions_kernel K;
(me and Gmpq do not work together very well so I try with doubles)

This works OUTSIDE of valgrind only if the polyhedra are cubes. If they are
anything else, it works only INSIDE of valgrind.

If I start the program OUTSIDE of valgrind, it stops with:

CGAL error: precondition violation!
Expr: circulator_size(h->vertex_begin()) >= size_type(3)
File: /home/jkbecker/Code/eKolos/src/eKolos/core/aPolyhedron_3.h
Line: 1196
Explanation:
terminate called after throwing an instance of 'CGAL::Precondition_exception'
 what():  CGAL ERROR: precondition violation!
Expr: circulator_size(h->vertex_begin()) >= size_type(3)
File: /home/jkbecker/Code/eKolos/src/eKolos/core/aPolyhedron_3.h
Line: 1196

CGAL probably produces antennas and at a later stage bails out because of it.

INSIDE of valgrind, it works fine.

The polyhedra check out ok using p.is_valid(), they fail the higher tests
(p.is_valid(true,1)), but I am not sure about the real meaning of this yet (I
will send output if needed).


Any ideas? Let me know if you need more info.

Jens


jkbecker@tiny:~$
 gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)


--
Dr. J.K. Becker
University of Tuebingen - Institute for Geoscience
Sigwartst. 10 - 72076 Tuebingen (Germany)
Tel.: ++49 7071 29 73139   Fax: +49 7071 5059
web: http://www.jkbecker.de


Quoting Sylvain Pion 
<>:

> Laurent Rineau wrote:
> > On Friday 28 November 2008 14:17:06 Sylvain Pion wrote:
> > > Jens K. Becker wrote:
> > > > The program compiles fine but does
> > > > not work (it always crashes when trying to remove halfedges (using
> > > > join_facets). If I run it in valgrind, it perfectly works.
> >
> > > Valgrind does not emulate FPU rounding modes which are used to implement
> > > interval arithmetic.  The later being used in filtered kernels which you
> > > can find in many places in CGAL.  A solution is to used either inexact
> > > fast non-robust, risky, use-at-your-own-risk, may-or-may-not-work-for-you
> > > kernels e.g. Simple_cartesian<double>, or a slow exact kernel, e.g.
> > > Simple_cartesian<Gmpq>.  That may be enough for debugging.
> > >
> > > The ideal solution would be to ping the valgrind developers (again),
> > > so that they work on supporting this missing feature.
> >
> > Sylvain, you missed a point: Jens program works only *IN* valgrind, 
> > and *that* is strange. What sort of CGAL can work only if rounding 
> > mode are never changed?
>
> OK, then I guess we need more details about "does not work".
>
> But valgrind is quite bad at emulating the FPU.  For example I think
> it emulates 64-bit only FPU instructions, so it truncates the additional
> precision on x86.  This can affect the result, in which ever direction.
> Similarly, not emulating the rounding mode makes all intervals singleton,
> which prevents any filter failure, hence no costly computation, and so
> might make a program look like it works whereas the too costly computations
> might kill it for performance/memory reasons.
>
> Again, more details are needed, but my gut feeling is that it's most
> probably something around this problem.
>
> --
> Sylvain Pion
> INRIA Sophia-Antipolis
> Geometrica Project-Team
> CGAL, http://cgal.org/