DOLFIN

cell.intersects() functionality in 0.9.7? (i.e. GTS dependencies)

Asked by marc spiegelman

Hi All,
   I've implemented a rather nifty semi-lagrangian advection scheme in dolfin that requires rapid checking to see if a point intersects a cell (without necessarily firing up the full intersection operator). Pre 0.9.7 this was implemented as cell.intersects(point).

Everything works fine in 0.9.6 with the new CGAL intersection operator replacing the GTS intersection operator (with about a 20% speedup). However, in 0.9.7 the code breaks because cell.intersects() has been removed as a GTS dependency (actually, looking at TriangleCell.intersects(point), it looks like it simply reproduces GTS code but wasn't actually dependent on GTS)

The question is... is there is any equivalent functionality in CGAL and is anyone interested in implementing it (either as cell.intersects(??) or some other interface). The functionality should be straightforward (and I'd be surprised if it didn't exist), given a *known cell* and a point, does the cell intersect the point. This would be useful for particle based methods as well.

On a related note...are there any plans for a parallel implementation of Function::eval(Array<double>& values, const Array<double>& x)
by release 1.0?

All assistance greatly appreciated
marc

Question information

Language:
English Edit question
Status:
Solved
For:
DOLFIN Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Andre Massing (massing) said : 		#1

On Friday 19. February 2010 18.33.47 marc spiegelman wrote:
 > New question #101686 on DOLFIN:
 > https://answers.launchpad.net/dolfin/+question/101686
 >
 > Hi All,
 > I've implemented a rather nifty semi-lagrangian advection scheme in
 > dolfin that requires rapid checking to see if a point intersects a
 > cell
 > (without necessarily firing up the full intersection operator). Pre
 > 0.9.7
 > this was implemented as cell.intersects(point).
 >
 > Everything works fine in 0.9.6 with the new CGAL intersection
 > operator
 > replacing the GTS intersection operator (with about a 20% speedup).

Did you only use the intersection between meshentities and points or did
you
use also the new mesh intersection operator? Just curious, because the
former
code for intersection between points og e.g. triangles did not change.

 > However, in 0.9.7 the code breaks because cell.intersects() has been
 > removed as a GTS dependency (actually, looking at
 > TriangleCell.intersects(point), it looks like it simply reproduces
 > GTS
 > code but wasn't actually dependent on GTS)

Yep that's true, the intersection functions was removed and there is a new
PrimitiveIntersector class in C++ with two static functions. These computes
the intersection between rather arbitrary mesh entities (exact or only
using
doubling precision). The functions are exposed as do_intersect and
do_intersect_exact in the python interface. But you are right, a point -
meshentity intersection is not provided. I attached a patch against the
recent
0.9.7 release. Could you can apply to you sources and see whether it
works for
you?

 >
 > The question is... is there is any equivalent functionality in CGAL
and is
 > anyone interested in implementing it (either as cell.intersects(??)
 > or some other interface). The functionality should be straightforward
 > (and I'd be surprised if it didn't exist), given a *known cell* and a
 > point, does the cell intersect the point. This would be useful for
 > particle based methods as well.
 >
 > On a related note...are there any plans for a parallel implementation
 > of Function::eval(Array<double>& values, const Array<double>& x) by
 > release 1.0?
 >
 > All assistance greatly appreciated

Any feedback as well :)

 > marc
 >

Revision history for this message
Garth Wells (garth-wells) said : 		#2

Andre Massing wrote:
> Question #101686 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/101686
>
> Status: Open => Answered
>
> Andre Massing proposed the following answer:
> On Friday 19. February 2010 18.33.47 marc spiegelman wrote:
> > New question #101686 on DOLFIN:
> > https://answers.launchpad.net/dolfin/+question/101686
> >
> > Hi All,
> > I've implemented a rather nifty semi-lagrangian advection scheme in
> > dolfin that requires rapid checking to see if a point intersects a
> > cell
> > (without necessarily firing up the full intersection operator). Pre
> > 0.9.7
> > this was implemented as cell.intersects(point).
> >
> > Everything works fine in 0.9.6 with the new CGAL intersection
> > operator
> > replacing the GTS intersection operator (with about a 20% speedup).
>
> Did you only use the intersection between meshentities and points or did
> you
> use also the new mesh intersection operator? Just curious, because the
> former
> code for intersection between points og e.g. triangles did not change.
>
> > However, in 0.9.7 the code breaks because cell.intersects() has been
> > removed as a GTS dependency (actually, looking at
> > TriangleCell.intersects(point), it looks like it simply reproduces
> > GTS
> > code but wasn't actually dependent on GTS)
>
> Yep that's true, the intersection functions was removed and there is a new
> PrimitiveIntersector class in C++ with two static functions. These computes
> the intersection between rather arbitrary mesh entities (exact or only
> using
> doubling precision). The functions are exposed as do_intersect and
> do_intersect_exact in the python interface. But you are right, a point -
> meshentity intersection is not provided. I attached a patch against the
> recent
> 0.9.7 release. Could you can apply to you sources and see whether it
> works for
> you?
>

Andre: Did you forget to attach it?

> >
> > The question is... is there is any equivalent functionality in CGAL
> and is
> > anyone interested in implementing it (either as cell.intersects(??)
> > or some other interface). The functionality should be straightforward
> > (and I'd be surprised if it didn't exist), given a *known cell* and a
> > point, does the cell intersect the point. This would be useful for
> > particle based methods as well.
> >
> > On a related note...are there any plans for a parallel implementation
> > of Function::eval(Array<double>& values, const Array<double>& x) by
> > release 1.0?

I've just pushed a change for this, although it won't work for
off-process points.

Garth

> >
> > All assistance greatly appreciated
>
> Any feedback as well :)
>
> > marc
> >
>

Revision history for this message
Andre Massing (massing) said : 		#3

Garth N. Wells wrote:
>
> Andre Massing wrote:
>> Question #101686 on DOLFIN changed:
>> https://answers.launchpad.net/dolfin/+question/101686
>>
>> Status: Open => Answered
>>
>> Andre Massing proposed the following answer:
>> On Friday 19. February 2010 18.33.47 marc spiegelman wrote:
>> > New question #101686 on DOLFIN:
>> > https://answers.launchpad.net/dolfin/+question/101686
>> >
>> > Hi All,
>> > I've implemented a rather nifty semi-lagrangian advection scheme in
>> > dolfin that requires rapid checking to see if a point intersects a
>> > cell
>> > (without necessarily firing up the full intersection operator). Pre
>> > 0.9.7
>> > this was implemented as cell.intersects(point).
>> >
>> > Everything works fine in 0.9.6 with the new CGAL intersection
>> > operator
>> > replacing the GTS intersection operator (with about a 20% speedup).
>>
>> Did you only use the intersection between meshentities and points or did
>> you
>> use also the new mesh intersection operator? Just curious, because the
>> former
>> code for intersection between points og e.g. triangles did not change.
>>
>> > However, in 0.9.7 the code breaks because cell.intersects() has been
>> > removed as a GTS dependency (actually, looking at
>> > TriangleCell.intersects(point), it looks like it simply reproduces
>> > GTS
>> > code but wasn't actually dependent on GTS)
>>
>> Yep that's true, the intersection functions was removed and there is a new
>> PrimitiveIntersector class in C++ with two static functions. These computes
>> the intersection between rather arbitrary mesh entities (exact or only
>> using
>> doubling precision). The functions are exposed as do_intersect and
>> do_intersect_exact in the python interface. But you are right, a point -
>> meshentity intersection is not provided. I attached a patch against the
>> recent
>> 0.9.7 release. Could you can apply to you sources and see whether it
>> works for
>> you?
>>
>
> Andre: Did you forget to attach it?

Hmm, I did not, at least in my sent box it also appeared with
attachment. Strange... resend it (CC to the DOLFIN-ml).

>
>> >
>> > The question is... is there is any equivalent functionality in CGAL
>> and is
>> > anyone interested in implementing it (either as cell.intersects(??)
>> > or some other interface). The functionality should be straightforward
>> > (and I'd be surprised if it didn't exist), given a *known cell* and a
>> > point, does the cell intersect the point. This would be useful for
>> > particle based methods as well.
>> >
>> > On a related note...are there any plans for a parallel implementation
>> > of Function::eval(Array<double>& values, const Array<double>& x) by
>> > release 1.0?
>
> I've just pushed a change for this, although it won't work for
> off-process points.
>
> Garth
>
>> >
>> > All assistance greatly appreciated
>>
>> Any feedback as well :)
>>
>> > marc
>> >
>>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~dolfin
> More help : https://help.launchpad.net/ListHelp

Revision history for this message
Andre Massing (massing) said : 		#4

Attachments seems to be filtered out when replying via email. Manually copied here for convenience, patch also available on the ml.

=== modified file 'dolfin/mesh/PrimitiveIntersector.cpp'
--- dolfin/mesh/PrimitiveIntersector.cpp 2010-02-11 00:47:11 +0000
+++ dolfin/mesh/PrimitiveIntersector.cpp 2010-02-19 18:39:14 +0000
@@ -6,7 +6,7 @@
 // Modified by André Massing, 2010
 //
 // First added: 2010-02-09
-// Last changed: 2010-02-11
+// Last changed: 2010-02-19
 //
 //Author: André Massing (am), <email address hidden>
 //Company: Simula Research Laboratory, Fornebu, Norway
@@ -26,13 +26,22 @@
 {
   return PrimitiveIntersector::do_intersect_with_kernel<SCK>(entity_1, entity_2);
 }
-
+//-----------------------------------------------------------------------------
+bool PrimitiveIntersector::do_intersect(const MeshEntity & entity, const Point & point)
+{
+ return PrimitiveIntersector::do_intersect_with_kernel<SCK>(PrimitiveTraits<PointPrimitive,SCK>::datum(point), entity);
+}
+//-----------------------------------------------------------------------------
 bool PrimitiveIntersector::do_intersect_exact(const MeshEntity & entity_1, const MeshEntity & entity_2)
 {
-
   return PrimitiveIntersector::do_intersect_with_kernel<EPICK>(entity_1, entity_2);
 }
 //-----------------------------------------------------------------------------
+bool PrimitiveIntersector::do_intersect_exact(const MeshEntity & entity, const Point & point)
+{
+ return PrimitiveIntersector::do_intersect_with_kernel<EPICK>(PrimitiveTraits<PointPrimitive,EPICK>::datum(point), entity);
+}
+//-----------------------------------------------------------------------------
 template <typename K, typename T, typename U >
 bool PrimitiveIntersector::do_intersect_with_kernel(const T & entity_1, const U & entity_2)
 {

=== modified file 'dolfin/mesh/PrimitiveIntersector.h'
--- dolfin/mesh/PrimitiveIntersector.h 2010-02-10 12:25:51 +0000
+++ dolfin/mesh/PrimitiveIntersector.h 2010-02-19 18:17:44 +0000
@@ -6,7 +6,7 @@
 // Modified by André Massing, 2010
 //
 // First added: 2010-02-09
-// Last changed: 2010-02-10
+// Last changed: 2010-02-19
 //
 //Author: André Massing (am), <email address hidden>
 //Company: Simula Research Laboratory, Fornebu, Norway
@@ -19,6 +19,7 @@
 namespace dolfin
 {
   class MeshEntity;
+ class Point;

   /// This class implements an intersection detection, detecting whether two given (arbitrary) meshentities intersect.
   class PrimitiveIntersector
@@ -28,10 +29,12 @@
       ///kernel which is faster but may suffer from floating point precision
       //issues.
       static bool do_intersect(const MeshEntity & entity_1, const MeshEntity & entity_2);
+ static bool do_intersect(const MeshEntity & entity_1, const Point & point);

       ///Computes whether two mesh entities intersect. Uses an exact geometry
       ///kernel which is slower but detects intersection always correctly.
       static bool do_intersect_exact(const MeshEntity & entity_1, const MeshEntity & entity_2);
+ static bool do_intersect_exact(const MeshEntity & entity_1, const Point & point);
     private:

       //@{

Revision history for this message
Anders Logg (logg) said : 		#5

On Sat, Feb 20, 2010 at 01:06:17AM -0000, Andre Massing wrote:
> Question #101686 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/101686
>
> Andre Massing proposed the following answer:
>
> Garth N. Wells wrote:
> >
> > Andre Massing wrote:
> >> Question #101686 on DOLFIN changed:
> >> https://answers.launchpad.net/dolfin/+question/101686
> >>
> >> Status: Open => Answered
> >>
> >> Andre Massing proposed the following answer:
> >> On Friday 19. February 2010 18.33.47 marc spiegelman wrote:
> >> > New question #101686 on DOLFIN:
> >> > https://answers.launchpad.net/dolfin/+question/101686
> >> >
> >> > Hi All,
> >> > I've implemented a rather nifty semi-lagrangian advection scheme in
> >> > dolfin that requires rapid checking to see if a point intersects a
> >> > cell
> >> > (without necessarily firing up the full intersection operator). Pre
> >> > 0.9.7
> >> > this was implemented as cell.intersects(point).
> >> >
> >> > Everything works fine in 0.9.6 with the new CGAL intersection
> >> > operator
> >> > replacing the GTS intersection operator (with about a 20% speedup).
> >>
> >> Did you only use the intersection between meshentities and points or did
> >> you
> >> use also the new mesh intersection operator? Just curious, because the
> >> former
> >> code for intersection between points og e.g. triangles did not change.
> >>
> >> > However, in 0.9.7 the code breaks because cell.intersects() has been
> >> > removed as a GTS dependency (actually, looking at
> >> > TriangleCell.intersects(point), it looks like it simply reproduces
> >> > GTS
> >> > code but wasn't actually dependent on GTS)
> >>
> >> Yep that's true, the intersection functions was removed and there is a new
> >> PrimitiveIntersector class in C++ with two static functions. These computes
> >> the intersection between rather arbitrary mesh entities (exact or only
> >> using
> >> doubling precision). The functions are exposed as do_intersect and
> >> do_intersect_exact in the python interface. But you are right, a point -
> >> meshentity intersection is not provided. I attached a patch against the
> >> recent
> >> 0.9.7 release. Could you can apply to you sources and see whether it
> >> works for
> >> you?
> >>
> >
> > Andre: Did you forget to attach it?
>
> Hmm, I did not, at least in my sent box it also appeared with
> attachment. Strange... resend it (CC to the DOLFIN-ml).

We also need to add back the simple interface

  bool MeshEntity::intersects(const Foo& foo) const;

where foo can be either a Point or another MeshEntity.

do_intersect looks a bit strange to me. (But it might be good for the
low-level interface that interacts with the CGAL templates.)

--
Anders

Revision history for this message
Andre Massing (massing) said : 		#6

Anders Logg wrote:
> Question #101686 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/101686
>
> Anders Logg proposed the following answer:
> On Sat, Feb 20, 2010 at 01:06:17AM -0000, Andre Massing wrote:
>> Question #101686 on DOLFIN changed:
>> https://answers.launchpad.net/dolfin/+question/101686
>>
>> Andre Massing proposed the following answer:
>>
>> Garth N. Wells wrote:
>>> Andre Massing wrote:
>>>> Question #101686 on DOLFIN changed:
>>>> https://answers.launchpad.net/dolfin/+question/101686
>>>>
>>>> Status: Open => Answered
>>>>
>>>> Andre Massing proposed the following answer:
>>>> On Friday 19. February 2010 18.33.47 marc spiegelman wrote:
>>>> > New question #101686 on DOLFIN:
>>>> > https://answers.launchpad.net/dolfin/+question/101686
>>>> >
>>>> > Hi All,
>>>> > I've implemented a rather nifty semi-lagrangian advection scheme in
>>>> > dolfin that requires rapid checking to see if a point intersects a
>>>> > cell
>>>> > (without necessarily firing up the full intersection operator). Pre
>>>> > 0.9.7
>>>> > this was implemented as cell.intersects(point).
>>>> >
>>>> > Everything works fine in 0.9.6 with the new CGAL intersection
>>>> > operator
>>>> > replacing the GTS intersection operator (with about a 20% speedup).
>>>>
>>>> Did you only use the intersection between meshentities and points or did
>>>> you
>>>> use also the new mesh intersection operator? Just curious, because the
>>>> former
>>>> code for intersection between points og e.g. triangles did not change.
>>>>
>>>> > However, in 0.9.7 the code breaks because cell.intersects() has been
>>>> > removed as a GTS dependency (actually, looking at
>>>> > TriangleCell.intersects(point), it looks like it simply reproduces
>>>> > GTS
>>>> > code but wasn't actually dependent on GTS)
>>>>
>>>> Yep that's true, the intersection functions was removed and there is a new
>>>> PrimitiveIntersector class in C++ with two static functions. These computes
>>>> the intersection between rather arbitrary mesh entities (exact or only
>>>> using
>>>> doubling precision). The functions are exposed as do_intersect and
>>>> do_intersect_exact in the python interface. But you are right, a point -
>>>> meshentity intersection is not provided. I attached a patch against the
>>>> recent
>>>> 0.9.7 release. Could you can apply to you sources and see whether it
>>>> works for
>>>> you?
>>>>
>>> Andre: Did you forget to attach it?
>> Hmm, I did not, at least in my sent box it also appeared with
>> attachment. Strange... resend it (CC to the DOLFIN-ml).
>
> We also need to add back the simple interface
>
> bool MeshEntity::intersects(const Foo& foo) const;
>
> where foo can be either a Point or another MeshEntity.

Of course we can do this. But before I removed it, we discussed it a bit
and concluded that intersects should not be a member function of an
entity (IIRC :), because it is a symmetric operation between geometric
objects and calculation of intersection detection is dependent on both
involved types.

>
> do_intersect looks a bit strange to me. (But it might be good for the
> low-level interface that interacts with the CGAL templates.)

Why exactly? It takes two entities or an entity and a point and just
returns a boolean value, stating, whether to entities "do intersect" :)
But what might be a better, more meaningful name? Just "intersects"? Or
what did you think of?

>
> --
> Anders
>

Revision history for this message
Anders Logg (logg) said : 		#7

On Sat, Feb 20, 2010 at 05:54:18PM -0000, Andre Massing wrote:
> Question #101686 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/101686
>
> Andre Massing proposed the following answer:
>
> Anders Logg wrote:
> > Question #101686 on DOLFIN changed:
> > https://answers.launchpad.net/dolfin/+question/101686
> >
> > Anders Logg proposed the following answer:
> > On Sat, Feb 20, 2010 at 01:06:17AM -0000, Andre Massing wrote:
> >> Question #101686 on DOLFIN changed:
> >> https://answers.launchpad.net/dolfin/+question/101686
> >>
> >> Andre Massing proposed the following answer:
> >>
> >> Garth N. Wells wrote:
> >>> Andre Massing wrote:
> >>>> Question #101686 on DOLFIN changed:
> >>>> https://answers.launchpad.net/dolfin/+question/101686
> >>>>
> >>>> Status: Open => Answered
> >>>>
> >>>> Andre Massing proposed the following answer:
> >>>> On Friday 19. February 2010 18.33.47 marc spiegelman wrote:
> >>>> > New question #101686 on DOLFIN:
> >>>> > https://answers.launchpad.net/dolfin/+question/101686
> >>>> >
> >>>> > Hi All,
> >>>> > I've implemented a rather nifty semi-lagrangian advection scheme in
> >>>> > dolfin that requires rapid checking to see if a point intersects a
> >>>> > cell
> >>>> > (without necessarily firing up the full intersection operator). Pre
> >>>> > 0.9.7
> >>>> > this was implemented as cell.intersects(point).
> >>>> >
> >>>> > Everything works fine in 0.9.6 with the new CGAL intersection
> >>>> > operator
> >>>> > replacing the GTS intersection operator (with about a 20% speedup).
> >>>>
> >>>> Did you only use the intersection between meshentities and points or did
> >>>> you
> >>>> use also the new mesh intersection operator? Just curious, because the
> >>>> former
> >>>> code for intersection between points og e.g. triangles did not change.
> >>>>
> >>>> > However, in 0.9.7 the code breaks because cell.intersects() has been
> >>>> > removed as a GTS dependency (actually, looking at
> >>>> > TriangleCell.intersects(point), it looks like it simply reproduces
> >>>> > GTS
> >>>> > code but wasn't actually dependent on GTS)
> >>>>
> >>>> Yep that's true, the intersection functions was removed and there is a new
> >>>> PrimitiveIntersector class in C++ with two static functions. These computes
> >>>> the intersection between rather arbitrary mesh entities (exact or only
> >>>> using
> >>>> doubling precision). The functions are exposed as do_intersect and
> >>>> do_intersect_exact in the python interface. But you are right, a point -
> >>>> meshentity intersection is not provided. I attached a patch against the
> >>>> recent
> >>>> 0.9.7 release. Could you can apply to you sources and see whether it
> >>>> works for
> >>>> you?
> >>>>
> >>> Andre: Did you forget to attach it?
> >> Hmm, I did not, at least in my sent box it also appeared with
> >> attachment. Strange... resend it (CC to the DOLFIN-ml).
> >
> > We also need to add back the simple interface
> >
> > bool MeshEntity::intersects(const Foo& foo) const;
> >
> > where foo can be either a Point or another MeshEntity.
>
> Of course we can do this. But before I removed it, we discussed it a bit
> and concluded that intersects should not be a member function of an
> entity (IIRC :), because it is a symmetric operation between geometric
> objects and calculation of intersection detection is dependent on both
> involved types.
>
> >
> > do_intersect looks a bit strange to me. (But it might be good for the
> > low-level interface that interacts with the CGAL templates.)
>
> Why exactly? It takes two entities or an entity and a point and just
> returns a boolean value, stating, whether to entities "do intersect" :)
> But what might be a better, more meaningful name? Just "intersects"? Or
> what did you think of?

I'm thinking we should reserve free functions for a few main
operations like assemble, solve, plot, refine. It would be more
natural to have intersects() as a member function in MeshEntity and
Point. They can be inlined and just call
PrimitiveIntersector::do_intersect.

--
Anders

Revision history for this message
Andre Massing (massing) said : 		#8

Hi Marc!

Just for your information, the code has been merged into the main trunk of DOLFIN, so there is again a intersects() member function available, now being member of the MeshEntity class. It computes exactly without limit precision related errors.
Hence it is slower then its inexact counterpart (which uses only double precision). If you need more speed you can also access the static do_intersect function of the PrimitiveIntersector class. The MeshEntity::intersects member only delegates to the static *do_intersect_exact* function of the PrimitiveIntersector class.

Any feedback is highly appreciated!

Revision history for this message
Anders Logg (logg) said : 		#9

On Fri, Mar 05, 2010 at 09:55:35AM -0000, Andre Massing wrote:
> Question #101686 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/101686
>
> Andre Massing posted a new comment:
> Hi Marc!
>
> Just for your information, the code has been merged into the main trunk of DOLFIN, so there is again a intersects() member function available, now being member of the MeshEntity class. It computes exactly without limit precision related errors.
> Hence it is slower then its inexact counterpart (which uses only double precision). If you need more speed you can also access the static do_intersect function of the PrimitiveIntersector class. The MeshEntity::intersects member only delegates to the static *do_intersect_exact* function of the PrimitiveIntersector class.
>
> Any feedback is highly appreciated!

I just added two new functions:

  intersects_exactly(point)
  intersects_exactly(entity)

which map to do_intersect_exact and changed intersects() to map to the
fast version.

--
Anders

Revision history for this message
Andre Massing (massing) said : 		#10

Anders Logg wrote:
> On Fri, Mar 05, 2010 at 09:55:35AM -0000, Andre Massing wrote:
>> Question #101686 on DOLFIN changed:
>> https://answers.launchpad.net/dolfin/+question/101686
>>
>> Andre Massing posted a new comment:
>> Hi Marc!
>>
>> Just for your information, the code has been merged into the main trunk of DOLFIN, so there is again a intersects() member function available, now being member of the MeshEntity class. It computes exactly without limit precision related errors.
>> Hence it is slower then its inexact counterpart (which uses only double precision). If you need more speed you can also access the static do_intersect function of the PrimitiveIntersector class. The MeshEntity::intersects member only delegates to the static *do_intersect_exact* function of the PrimitiveIntersector class.
>>
>> Any feedback is highly appreciated!
>
> I just added two new functions:
>
> intersects_exactly(point)
> intersects_exactly(entity)

>
> which map to do_intersect_exact and changed intersects() to map to the
> fast version.

Ok, cool, was going to ask about that, but you replied faster then I ask :)

>
> --
> Anders
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~dolfin
> More help : https://help.launchpad.net/ListHelp

Revision history for this message
Garth Wells (garth-wells) said : 		#11

Present in latest release.