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
signature.asc
Description: Digital signature
_______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
