CGAL users discussion list

[Graham Macpherson <>]

Hi,

The displacements (a different 'v' for every vertex) in my application (moving
the triangulation around to create dual cells with favourable shapes for 
finite
volume CFD) is calculated in double precision, so the resulting point did not
need to be exact.  I changed to using:

    pointsToInsert.push_back
    (
        Point
        (
            CGAL::to_double(vit->point().x()) + CGAL::to_double(v.x()),
            CGAL::to_double(vit->point().y()) + CGAL::to_double(v.y()),
            CGAL::to_double(vit->point().z()) + CGAL::to_double(v.z())
        )
    );

and all was well.

Also, after your question, it seems that I can get away with;

    typedef CGAL::Exact_predicates_inexact_constructions_kernel inexactK;

if I use:

    typedef CGAL::Robust_circumcenter_traits_3<inexactK>  K;

which, along with switching to Triangulation_cell_base_with_circumcenter_3, 
has
given a nice speedup.

Best regards,

Graham


On Tuesday 01 February 2011 09:46:23 Sebastien Loriot (GeometryFactory) wrote:
> Hello,
>
> In my first answer I told you about a DAG used to maintain constructions
> so as to evaluate exactly predicates using them.
>
> When the answer of a predicate can be certified using approximated
> constructions, the DAG does not change. When approximations are
> not sufficient to conclude (what we call a filter failure), a traversal
> of the DAG is made and the corresponding path is simplified and replaced
> by the corresponding exact value.
>
> The main difference between 4.3 and 4.5 is that the compiler gets better
> and fewer filter failures are observed. The result is that the DAG is
> more often simplified when using 4.3 than with 4.5 (thus the memory
> increase with 4.5).
> You can observe it by manually simplify the DAG by using for example the
> following:
>        if (i % 5 == 0 ) exact(vit->point());
>        // Option B
>        pointsToInsert.push_back(vit->point() + v);
>
> In general, it is not a good solution to use iterative constructions
> with the Lazy_kernel as no automatic simplification policy are
> implemented right now and can lead to memory issues.
>
> Does the displacement of your points need to be exact? Otherwise using
> Exact_predicates_inexact_constructions_kernel might be sufficient.
> If you tell us more details about your application, we might find a
> solution that fit your needs.
>
>
> S.
>
>
>
> Graham Macpherson wrote:
> > Hi Sebastien,
> >
> > Do you have any further info on using gcc 4.5?  Is it an isolated problem
> > related to where I found it, or are there wider implications across CGAL?
> >
> > Thanks,
> >
> > Graham
> >
> >
> > On Monday 17 January 2011 13:40:04 Sebastien Loriot (GeometryFactory) 
> > wrote:
> >> Graham Macpherson wrote:
> >>> Hi Sebastien,
> >>>
> >>> Thanks for the reply.
> >>>
> >>> I've checked and I do see the linear memory increase with openSUSE and 
> >>> not with
> >>> Ubuntu; the logs I attached to my email are valid.
> >>>
> >>> Is it worth investigating if gcc 4.4 vs 4.5 makes a difference?
> >>>
> >> You were right, there seems to be a problem when using gcc 4.5.
> >> I don't know right now what. I'll post here when I have more
> >> information.
> >>
> >> S.
> >>
> >>
> >>> Regards,
> >>>
> >>> Graham
> >>>
> >>>
> >>>
> >>> On Monday 17 January 2011 08:40:52 Sebastien Loriot (GeometryFactory) 
> >>> wrote:
> >>>> There is no memory leak in your code.
> >>>>
> >>>> Behind the Exact_predicates_exact_constructions_kernel, there are
> >>>> *a multi-precision number type (for example Gmpq if GMP is available)
> >>>> *filtering mechanism on constructed objects (such as points)
> >>>>
> >>>> In your for loop, you are iteratively summing to your points a vector.
> >>>> Both implementation details are responsible for the memory increase:
> >>>>
> >>>> *The precision needed by the number type to exactly do the sums
> >>>> requires more precision, thus more space. Running you code with
> >>>> CGAL::Simple_cartesian<CGAL::Gmpq>, you will observe an increase in
> >>>> memory usage, but not at each iteration (only when precision of numbers
> >>>> is increased).
> >>>>
> >>>> *the filtering mechanism maintain a DAG of the cascaded constructions.
> >>>> Each sum create a note in the DAG. This is the real cause of the memory
> >>>> usage increase in your case.
> >>>>
> >>>>
> >>>> However, I am surprised that you do not observe the memory consumption
> >>>> increase on Ubuntu.
> >>>> Can you please check again to confirm whether there is a problem?
> >>>>
> >>>> S.
> >>>>
> >>>> Graham Macpherson wrote:
> >>>>> Hello all,
> >>>>>
> >>>>> I've found a strange memory problem that I've reproduced in the 
> >>>>> attached code.
> >>>>>
> >>>>> I'm taking the vertices of a Delaunay tessellation, calculating a 
> >>>>> displacement
> >>>>> for them, clearing the tessellation, then reinserting the displaced 
> >>>>> vertices.
> >>>>> When I run this, the memory use by the process increases linearly 
> >>>>> with each
> >>>>> iteration, which is wrong, it should be essentially constant, however:
> >>>>>
> >>>>>  + The problem doesn't occur with option A in the attached, only with 
> >>>>> option B,
> >>>>>    i.e. when adding a Vector_3 to the point;
> >>>>>
> >>>>>  + The problem doesn't occur using
> >>>>>    Exact_predicates_inexact_constructions_kernel, only with
> >>>>>    Exact_predicates_exact_constructions_kernel;
> >>>>>
> >>>>>  + It doesn't appear on all operating systems - it appears on 
> >>>>> openSUSE 11.3, but
> >>>>>    not on Ubuntu 10.04.
> >>>>>
> >>>>> Also attached are two log files showing the contrasting behaviour on 
> >>>>> the two
> >>>>> operating systems with the code the same.
> >>>>>
> >>>>> I've tried on openSUSE 11.3 with gcc 4.5.0 (system compiler) and gcc 
> >>>>> 4.5.2,
> >>>>> boost versions 1.40.0, 1.42.0 (system) and 1.45.0, and with CGAL 
> >>>>> 3.5.1 and CGAL
> >>>>> 3.7, and they all essentially do the same thing.
> >>>>>
> >>>>> On Ubuntu I'm using CGAL 3.7, gcc 4.4.3 (system compiler) and boost 
> >>>>> 1.40.0
> >>>>> (system).
> >>>>>
> >>>>> Note, the memInfo class is one that's part of other libraries I'm 
> >>>>> using, so it
> >>>>> won't compile for you, it's only there to show how the output was 
> >>>>> generated.
> >>>>>
> >>>>> Assuming that the addition operation in option B is legitimate, then 
> >>>>> this looks
> >>>>> like a bug in a library.  Any suggestions for how to get to the 
> >>>>> bottom of it?
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Graham
> >>>>>
> >>>>> --
> >>>>> Graham Macpherson
> >>>>>
> >>>>> OpenCFD Ltd.
> >>>>> www.openfoam.com
> >>>>>
> >>>>> 
> >>>>> +44 (0)118 9471030
> >>>>>
> >>>>> 9 Albert Road
> >>>>> Caversham
> >>>>> Reading RG4 7AN
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
> >
>
>
>