dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Feb 04, 2010 at 01:08:35AM +0100, Andre Massing wrote:
> Garth N. Wells wrote:
> >
> > Andre Massing wrote:
> >> Hi!
> >>
> >> Garth N. Wells wrote:
> >>> Is it OK to remove GTS support from DOLFIN?
> >> I think, the GTS functionality is not really used anymore in DOLFIN.
> >> At least I have already removed all classes and member methods which
> >> where somehow linked to the GTS interface in the cgal_branch.
> >>
> >
> > Can we also use CGAL for what's in TriangleCell::intersects?
>
> Yes sure, in principal. I removed that function in my local trunk
> because it was only used for the mesh intersection (at least in the
> main trunk) and it reimplements functionality which is available in
> CGAL.
> Additionally it uses some very let's say advanced  macroprogramming,
> have a look at dolfin/mesh/GeometricPredicates.cpp.
> As a sidenote IMHO intersects should be not a member function of a
> cell, this just scatters intersect(class A, class B) function
> through all the involved classes, but that's a matter of taste :)

I agree. If you have a better solution, just push it.

> The template class Primitive_Traits, which converts from DOLFIN
> cells/entities to corresponding CGAL primitives like Triangle_3,
> Tetrahedron_2 etc., is already in place, such that an intersection
> test would only involve a call to do_intersect function in the CGAL
> geometric kernel.

The Primitive_Traits template should be renamed PrimitiveTraits and
the file renamed accordingly to match other classes in DOLFIN.

> So it's not a questions of if, just of where exactly.
> One could for example extend the IntersectionOperator with methods
> like do_intersect(class A, class B)?

Your call.

--
Anders

Attachment: signature.asc
Description: Digital signature