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.
