Function evaluation fails if the mesh has one element

[Doug Arnold]

In trying to debug a code, I wanted to work with a simple mesh.
But when I tried the simplest possible, a mesh consisting of a single
element, I discovered that the evaluation of functions in finite
element spaces doesn't work. For example this code fails:

from dolfin import *
mesh = Mesh("simplemesh.xml")
Vh = FunctionSpace(mesh, 'CG', 1)
u = Function(Vh)
print u((.3,.6))

if simplemesh.xml is this one element mesh:

<?xml version="1.0"?>
<dolfin xmlns:dolfin="http://www.fenicsproject.org">
  <mesh celltype="triangle" dim="2">
    <vertices size="3">
      <vertex index="0" x="0" y="0" />
      <vertex index="1" x="0" y="1" />
      <vertex index="2" x="1" y="1" />
    </vertices>
    <cells size="1">
      <triangle index="0" v0="0" v1="1" v2="2" />
    </cells>
  </mesh>
</dolfin>

If mesh has two elements, the code succeeds.

A bug? Is there a work around?

[Johan Hake (johan-hake)]

It looks like a limitation in CGAL. The error I get is:

StandardError: CGAL ERROR: assertion violation!
Expr: m_primitives.size() > 1
File: /usr/include/CGAL/AABB_tree.h
Line: 302

CGAL is used to check what element is intersected and then use that
element in the restriction. However, we need to check whether the point
is inside the element or not.

Johan

On 08/23/2012 12:07 AM, Doug Arnold wrote:
> Public bug reported:
>
> In trying to debug a code, I wanted to work with a simple mesh.
> But when I tried the simplest possible, a mesh consisting of a single
> element, I discovered that the evaluation of functions in finite
> element spaces doesn't work. For example this code fails:
>
> from dolfin import *
> mesh = Mesh("simplemesh.xml")
> Vh = FunctionSpace(mesh, 'CG', 1)
> u = Function(Vh)
> print u((.3,.6))
>
> if simplemesh.xml is this one element mesh:
>
> <?xml version="1.0"?>
> <dolfin xmlns:dolfin="http://www.fenicsproject.org">
> <mesh celltype="triangle" dim="2">
> <vertices size="3">
> <vertex index="0" x="0" y="0" />
> <vertex index="1" x="0" y="1" />
> <vertex index="2" x="1" y="1" />
> </vertices>
> <cells size="1">
> <triangle index="0" v0="0" v1="1" v2="2" />
> </cells>
> </mesh>
> </dolfin>
>
> If mesh has two elements, the code succeeds.
>
> A bug? Is there a work around?
>
> ** Affects: dolfin
> Importance: Undecided
> Status: New
>

[Anders Logg (logg)]

On Thu, Aug 23, 2012 at 07:17:14AM -0000, Garth Wells wrote:
> ** Changed in: dolfin
> Status: New => Confirmed

If the limitation is in CGAL, we could add a special case check to see
if there is just one element and in that case just skip the search.

--
Anders

[Garth Wells (garth-wells)]

On 23 August 2012 12:02, Anders Logg <email address hidden> wrote:
> On Thu, Aug 23, 2012 at 07:17:14AM -0000, Garth Wells wrote:
>> ** Changed in: dolfin
>> Status: New => Confirmed
>
> If the limitation is in CGAL, we could add a special case check to see
> if there is just one element and in that case just skip the search.
>

It's not that easy - we still need to check that the point lies within the cell.

Garth

> --
> Anders
>
> --
> You received this bug notification because you are a member of DOLFIN
> Core Team, which is subscribed to DOLFIN.
> https://bugs.launchpad.net/bugs/1040312
>
> Title:
> Function evaluation fails if the mesh has one element
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/dolfin/+bug/1040312/+subscriptions

[Johan Hake (johan-hake)]

On 08/23/2012 01:02 PM, Anders Logg wrote:
> On Thu, Aug 23, 2012 at 07:17:14AM -0000, Garth Wells wrote:
>> ** Changed in: dolfin
>> Status: New => Confirmed
>
> If the limitation is in CGAL, we could add a special case check to see
> if there is just one element and in that case just skip the search.

That is the trivial part. We still need to check if the point is inside
or outside the single cell.

I suggest we add something like:

   bool Cell::inside(Point x);

Then each of the subclasses could implement some standard algorithms for
the check.

Johan

[Anders Logg (logg)]

On Thu, Aug 23, 2012 at 01:17:08PM +0200, Johan Hake wrote:
> On 08/23/2012 01:02 PM, Anders Logg wrote:
> > On Thu, Aug 23, 2012 at 07:17:14AM -0000, Garth Wells wrote:
> >> ** Changed in: dolfin
> >> Status: New => Confirmed
> >
> > If the limitation is in CGAL, we could add a special case check to see
> > if there is just one element and in that case just skip the search.
>
> That is the trivial part. We still need to check if the point is inside
> or outside the single cell.
>
> I suggest we add something like:
>
> bool Cell::inside(Point x);
>
> Then each of the subclasses could implement some standard algorithms for
> the check.

There should be some CGAL function we could call for this.

Or we could just skip the check in that case? The evaluation of basis
functions would still work outside the cell.

--
Anders

[Johan Hake (johan-hake)]

On 08/23/2012 01:22 PM, Anders Logg wrote:
> On Thu, Aug 23, 2012 at 01:17:08PM +0200, Johan Hake wrote:
>> On 08/23/2012 01:02 PM, Anders Logg wrote:
>>> On Thu, Aug 23, 2012 at 07:17:14AM -0000, Garth Wells wrote:
>>>> ** Changed in: dolfin
>>>> Status: New => Confirmed
>>>
>>> If the limitation is in CGAL, we could add a special case check to see
>>> if there is just one element and in that case just skip the search.
>>
>> That is the trivial part. We still need to check if the point is inside
>> or outside the single cell.
>>
>> I suggest we add something like:
>>
>> bool Cell::inside(Point x);
>>
>> Then each of the subclasses could implement some standard algorithms for
>> the check.
>
> There should be some CGAL function we could call for this.

Sure, but having that particular functionality as a member function to
Cell should be trivial to add without CGAL and would be quite useful.

> Or we could just skip the check in that case? The evaluation of basis
> functions would still work outside the cell.

For consistency we should probably include a check as the evaluation
outside the cell results in a the value at the closest point inside the
cell. Finding this point might not be trivial to add though...

Johan

> --
> Anders
>

[Anders Logg (logg)]

On Thu, Aug 23, 2012 at 01:28:09PM +0200, Johan Hake wrote:
> On 08/23/2012 01:22 PM, Anders Logg wrote:
> > On Thu, Aug 23, 2012 at 01:17:08PM +0200, Johan Hake wrote:
> >> On 08/23/2012 01:02 PM, Anders Logg wrote:
> >>> On Thu, Aug 23, 2012 at 07:17:14AM -0000, Garth Wells wrote:
> >>>> ** Changed in: dolfin
> >>>> Status: New => Confirmed
> >>>
> >>> If the limitation is in CGAL, we could add a special case check to see
> >>> if there is just one element and in that case just skip the search.
> >>
> >> That is the trivial part. We still need to check if the point is inside
> >> or outside the single cell.
> >>
> >> I suggest we add something like:
> >>
> >> bool Cell::inside(Point x);
> >>
> >> Then each of the subclasses could implement some standard algorithms for
> >> the check.
> >
> > There should be some CGAL function we could call for this.
>
> Sure, but having that particular functionality as a member function to
> Cell should be trivial to add without CGAL and would be quite useful.
>
> > Or we could just skip the check in that case? The evaluation of basis
> > functions would still work outside the cell.
>
> For consistency we should probably include a check as the evaluation
> outside the cell results in a the value at the closest point inside the
> cell. Finding this point might not be trivial to add though...

No, evaluation outside will be at that point outside the cell. The
basis functions will be extrapolated to outside the cell.

--
Anders

[Johan Hake (johan-hake)]

On 08/23/2012 03:07 PM, Anders Logg wrote:
> On Thu, Aug 23, 2012 at 01:28:09PM +0200, Johan Hake wrote:
>> On 08/23/2012 01:22 PM, Anders Logg wrote:
>>> On Thu, Aug 23, 2012 at 01:17:08PM +0200, Johan Hake wrote:
>>>> On 08/23/2012 01:02 PM, Anders Logg wrote:
>>>>> On Thu, Aug 23, 2012 at 07:17:14AM -0000, Garth Wells wrote:
>>>>>> ** Changed in: dolfin
>>>>>> Status: New => Confirmed
>>>>>
>>>>> If the limitation is in CGAL, we could add a special case check to see
>>>>> if there is just one element and in that case just skip the search.
>>>>
>>>> That is the trivial part. We still need to check if the point is inside
>>>> or outside the single cell.
>>>>
>>>> I suggest we add something like:
>>>>
>>>> bool Cell::inside(Point x);
>>>>
>>>> Then each of the subclasses could implement some standard algorithms for
>>>> the check.
>>>
>>> There should be some CGAL function we could call for this.
>>
>> Sure, but having that particular functionality as a member function to
>> Cell should be trivial to add without CGAL and would be quite useful.
>>
>>> Or we could just skip the check in that case? The evaluation of basis
>>> functions would still work outside the cell.
>>
>> For consistency we should probably include a check as the evaluation
>> outside the cell results in a the value at the closest point inside the
>> cell. Finding this point might not be trivial to add though...
>
> No, evaluation outside will be at that point outside the cell. The
> basis functions will be extrapolated to outside the cell.

Ok, then I have misunderstood the behavior...

For consistency I still think we need to check if the point is inside or
outside, as we do for ordinary eval. If outside one need to have:

  parameters.allow_extrapolation = True

to be able to evaulate.

Johan

[Anders Logg (logg)]

On Thu, Aug 23, 2012 at 03:16:13PM +0200, Johan Hake wrote:
> On 08/23/2012 03:07 PM, Anders Logg wrote:
> > On Thu, Aug 23, 2012 at 01:28:09PM +0200, Johan Hake wrote:
> >> On 08/23/2012 01:22 PM, Anders Logg wrote:
> >>> On Thu, Aug 23, 2012 at 01:17:08PM +0200, Johan Hake wrote:
> >>>> On 08/23/2012 01:02 PM, Anders Logg wrote:
> >>>>> On Thu, Aug 23, 2012 at 07:17:14AM -0000, Garth Wells wrote:
> >>>>>> ** Changed in: dolfin
> >>>>>> Status: New => Confirmed
> >>>>>
> >>>>> If the limitation is in CGAL, we could add a special case check to see
> >>>>> if there is just one element and in that case just skip the search.
> >>>>
> >>>> That is the trivial part. We still need to check if the point is inside
> >>>> or outside the single cell.
> >>>>
> >>>> I suggest we add something like:
> >>>>
> >>>> bool Cell::inside(Point x);
> >>>>
> >>>> Then each of the subclasses could implement some standard algorithms for
> >>>> the check.
> >>>
> >>> There should be some CGAL function we could call for this.
> >>
> >> Sure, but having that particular functionality as a member function to
> >> Cell should be trivial to add without CGAL and would be quite useful.
> >>
> >>> Or we could just skip the check in that case? The evaluation of basis
> >>> functions would still work outside the cell.
> >>
> >> For consistency we should probably include a check as the evaluation
> >> outside the cell results in a the value at the closest point inside the
> >> cell. Finding this point might not be trivial to add though...
> >
> > No, evaluation outside will be at that point outside the cell. The
> > basis functions will be extrapolated to outside the cell.
>
> Ok, then I have misunderstood the behavior...
>
> For consistency I still think we need to check if the point is inside or
> outside, as we do for ordinary eval. If outside one need to have:
>
> parameters.allow_extrapolation = True
>
> to be able to evaulate.

Yes, that's the ideal situation. My suggestion is just an excuse to
not having to implement {Tetrahedron,Triangle,Interval}Cell::inside. :-)

--
Anders

[Garth Wells (garth-wells)]

To handle the one cell case, copy the mesh, add a dummy cell to the mesh and send it to CGAL. Then just check that the return value is in/out of the first cell.

[Johan Hake (johan-hake)]

On 08/23/2012 04:00 PM, Garth Wells wrote:
> To handle the one cell case, copy the mesh, add a dummy cell to the mesh
> and send it to CGAL. Then just check that the return value is in/out of
> the first cell.

Not sure I want to touch the CGAL wrapper code, ever...

Johan

[Johan Hake (johan-hake)]

On 08/23/2012 03:47 PM, Anders Logg wrote:
> On Thu, Aug 23, 2012 at 03:16:13PM +0200, Johan Hake wrote:
>> On 08/23/2012 03:07 PM, Anders Logg wrote:
>>> On Thu, Aug 23, 2012 at 01:28:09PM +0200, Johan Hake wrote:
>>>> On 08/23/2012 01:22 PM, Anders Logg wrote:
>>>>> On Thu, Aug 23, 2012 at 01:17:08PM +0200, Johan Hake wrote:
>>>>>> On 08/23/2012 01:02 PM, Anders Logg wrote:
>>>>>>> On Thu, Aug 23, 2012 at 07:17:14AM -0000, Garth Wells wrote:
>>>>>>>> ** Changed in: dolfin
>>>>>>>> Status: New => Confirmed
>>>>>>>
>>>>>>> If the limitation is in CGAL, we could add a special case check to see
>>>>>>> if there is just one element and in that case just skip the search.
>>>>>>
>>>>>> That is the trivial part. We still need to check if the point is inside
>>>>>> or outside the single cell.
>>>>>>
>>>>>> I suggest we add something like:
>>>>>>
>>>>>> bool Cell::inside(Point x);
>>>>>>
>>>>>> Then each of the subclasses could implement some standard algorithms for
>>>>>> the check.
>>>>>
>>>>> There should be some CGAL function we could call for this.
>>>>
>>>> Sure, but having that particular functionality as a member function to
>>>> Cell should be trivial to add without CGAL and would be quite useful.
>>>>
>>>>> Or we could just skip the check in that case? The evaluation of basis
>>>>> functions would still work outside the cell.
>>>>
>>>> For consistency we should probably include a check as the evaluation
>>>> outside the cell results in a the value at the closest point inside the
>>>> cell. Finding this point might not be trivial to add though...
>>>
>>> No, evaluation outside will be at that point outside the cell. The
>>> basis functions will be extrapolated to outside the cell.
>>
>> Ok, then I have misunderstood the behavior...
>>
>> For consistency I still think we need to check if the point is inside or
>> outside, as we do for ordinary eval. If outside one need to have:
>>
>> parameters.allow_extrapolation = True
>>
>> to be able to evaulate.
>
> Yes, that's the ideal situation. My suggestion is just an excuse to
> not having to implement {Tetrahedron,Triangle,Interval}Cell::inside. :-)

Well it looks like it is not that bad. In 3D one need to do the same
calculations we do for the volume, only 4 times.

3D:
  http://steve.hollasch.net/cgindex/geometry/ptintet.html

2D:
  http://mathworld.wolfram.com/TriangleInterior.html

1D:
  Trivial.

Johan

[Andre Massing (massing)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/23/2012 01:28 PM, Johan Hake wrote:
> On 08/23/2012 01:22 PM, Anders Logg wrote:
>> On Thu, Aug 23, 2012 at 01:17:08PM +0200, Johan Hake wrote:
>>> On 08/23/2012 01:02 PM, Anders Logg wrote:
>>>> On Thu, Aug 23, 2012 at 07:17:14AM -0000, Garth Wells wrote:
>>>>> ** Changed in: dolfin Status: New => Confirmed
>>>>
>>>> If the limitation is in CGAL, we could add a special case
>>>> check to see if there is just one element and in that case
>>>> just skip the search.
>>>
>>> That is the trivial part. We still need to check if the point
>>> is inside or outside the single cell.
>>>
>>> I suggest we add something like:
>>>
>>> bool Cell::inside(Point x);

That functionality is already in DOLFIN, inside the MeshEntity class:
 bool intersects(const Point& point) const
    { return PrimitiveIntersector::do_intersect(*this, point); }

- --
Andre

>>>
>>> Then each of the subclasses could implement some standard
>>> algorithms for the check.
>>
>> There should be some CGAL function we could call for this.
>
> Sure, but having that particular functionality as a member function
> to Cell should be trivial to add without CGAL and would be quite
> useful.
>
>> Or we could just skip the check in that case? The evaluation of
>> basis functions would still work outside the cell.
>
> For consistency we should probably include a check as the
> evaluation outside the cell results in a the value at the closest
> point inside the cell. Finding this point might not be trivial to
> add though...
>
> Johan
>
>> -- Anders
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQN0mQAAoJEA79ggnbq9dmijUH/ijF7Ma4LJBpxTrcVhR/5GOF
1VeFUW1ykWrRL2dzZHH/e2tR1v4S5cjw4CNVEIM1wpvBSNknttjnPwkfPUZmQ+gU
nAkD/8VKhQ/2pcRnd0hFvOIs8Lr+MSxd3J2nG8gJmEZiDZIclMXkYwaukJ5acjfE
iBvHR8eL+cqUceneS64u6HtfG0BNWTR4wyScbMp0n++O1JBnGJNtJH+GnGC3aUPe
rKcqcV72sdOh1SKL5NPeudYQfC12YbapZJTvPOaOAXlJ10EKcz72GIOjBeO7vJX+
YyPzxU2e3La/nTZs7EH2dLzEIc+rswRNQAvQX58WbFsjSEcRXhVsYPInFvlkTy8=
=ehhL
-----END PGP SIGNATURE-----

[Anders Logg (logg)]

On Fri, Aug 24, 2012 at 09:29:58AM -0000, Andre Massing wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On 08/23/2012 01:28 PM, Johan Hake wrote:
> > On 08/23/2012 01:22 PM, Anders Logg wrote:
> >> On Thu, Aug 23, 2012 at 01:17:08PM +0200, Johan Hake wrote:
> >>> On 08/23/2012 01:02 PM, Anders Logg wrote:
> >>>> On Thu, Aug 23, 2012 at 07:17:14AM -0000, Garth Wells wrote:
> >>>>> ** Changed in: dolfin Status: New => Confirmed
> >>>>
> >>>> If the limitation is in CGAL, we could add a special case
> >>>> check to see if there is just one element and in that case
> >>>> just skip the search.
> >>>
> >>> That is the trivial part. We still need to check if the point
> >>> is inside or outside the single cell.
> >>>
> >>> I suggest we add something like:
> >>>
> >>> bool Cell::inside(Point x);
>
> That functionality is already in DOLFIN, inside the MeshEntity class:
> bool intersects(const Point& point) const
> { return PrimitiveIntersector::do_intersect(*this, point); }

Nice! :-)

--
Anders

>
> - --
> Andre
>
>
> >>>
> >>> Then each of the subclasses could implement some standard
> >>> algorithms for the check.
> >>
> >> There should be some CGAL function we could call for this.
> >
> > Sure, but having that particular functionality as a member function
> > to Cell should be trivial to add without CGAL and would be quite
> > useful.
> >
> >> Or we could just skip the check in that case? The evaluation of
> >> basis functions would still work outside the cell.
> >
> > For consistency we should probably include a check as the
> > evaluation outside the cell results in a the value at the closest
> > point inside the cell. Finding this point might not be trivial to
> > add though...
> >
> > Johan
> >
> >> -- Anders
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJQN0mQAAoJEA79ggnbq9dmijUH/ijF7Ma4LJBpxTrcVhR/5GOF
> 1VeFUW1ykWrRL2dzZHH/e2tR1v4S5cjw4CNVEIM1wpvBSNknttjnPwkfPUZmQ+gU
> nAkD/8VKhQ/2pcRnd0hFvOIs8Lr+MSxd3J2nG8gJmEZiDZIclMXkYwaukJ5acjfE
> iBvHR8eL+cqUceneS64u6HtfG0BNWTR4wyScbMp0n++O1JBnGJNtJH+GnGC3aUPe
> rKcqcV72sdOh1SKL5NPeudYQfC12YbapZJTvPOaOAXlJ10EKcz72GIOjBeO7vJX+
> YyPzxU2e3La/nTZs7EH2dLzEIc+rswRNQAvQX58WbFsjSEcRXhVsYPInFvlkTy8=
> =ehhL
> -----END PGP SIGNATURE-----
>

[Johan Hake (johan-hake)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/24/2012 11:29 AM, Andre Massing wrote:
>
> On 08/23/2012 01:28 PM, Johan Hake wrote:
>> On 08/23/2012 01:22 PM, Anders Logg wrote:
>>> On Thu, Aug 23, 2012 at 01:17:08PM +0200, Johan Hake wrote:
>>>> On 08/23/2012 01:02 PM, Anders Logg wrote:
>>>>> On Thu, Aug 23, 2012 at 07:17:14AM -0000, Garth Wells
>>>>> wrote:
>>>>>> ** Changed in: dolfin Status: New => Confirmed
>>>>>
>>>>> If the limitation is in CGAL, we could add a special case
>>>>> check to see if there is just one element and in that case
>>>>> just skip the search.
>>>>
>>>> That is the trivial part. We still need to check if the
>>>> point is inside or outside the single cell.
>>>>
>>>> I suggest we add something like:
>>>>
>>>> bool Cell::inside(Point x);
>
> That functionality is already in DOLFIN, inside the MeshEntity
> class: bool intersects(const Point& point) const { return
> PrimitiveIntersector::do_intersect(*this, point); }
>

I thought so! But I looked in the wrong file...

The bug should be fixed in trunk now.

Johan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQN2ssAAoJEEzjkVbXgH+MtPwH/A83KvrZygd54butoGlyUNRD
QDwUWaaZtRBMLEcHofw085EN55zQ9KnmciimKPgOPJxUDVt+U+TTG1YOg/qTeddx
nqCnW1np3pj7MitfJ101HIJnqs1QE/Xrak1on+Wsd548ao9BxrlK/+bM8REbfJCV
mHaZ0aU7rjx7P1/xndIdy5wNOJIIEPoS4BiHoVP+mszqR32BNWOfi5cGcHBiURp0
pwJbyb32OYMa+XLco/LgGoMrfGgY8M8xHzS2gANJji761Hl+ed5KU/GFfFD5ktVB
ExnLpV7vLq5O5BpTUPuyVj9RqiWr8FC3RqZgPwo7xn/qpfK8QIs7iZ1uo8yN8EU=
=hZyM
-----END PGP SIGNATURE-----

[Anders Logg (logg)]

On Fri, Aug 24, 2012 at 11:53:27AM -0000, Johan Hake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/24/2012 11:29 AM, Andre Massing wrote:
> >
> > On 08/23/2012 01:28 PM, Johan Hake wrote:
> >> On 08/23/2012 01:22 PM, Anders Logg wrote:
> >>> On Thu, Aug 23, 2012 at 01:17:08PM +0200, Johan Hake wrote:
> >>>> On 08/23/2012 01:02 PM, Anders Logg wrote:
> >>>>> On Thu, Aug 23, 2012 at 07:17:14AM -0000, Garth Wells
> >>>>> wrote:
> >>>>>> ** Changed in: dolfin Status: New => Confirmed
> >>>>>
> >>>>> If the limitation is in CGAL, we could add a special case
> >>>>> check to see if there is just one element and in that case
> >>>>> just skip the search.
> >>>>
> >>>> That is the trivial part. We still need to check if the
> >>>> point is inside or outside the single cell.
> >>>>
> >>>> I suggest we add something like:
> >>>>
> >>>> bool Cell::inside(Point x);
> >
> > That functionality is already in DOLFIN, inside the MeshEntity
> > class: bool intersects(const Point& point) const { return
> > PrimitiveIntersector::do_intersect(*this, point); }
> >
>
> I thought so! But I looked in the wrong file...
>
> The bug should be fixed in trunk now.

Even better. :-)

--
Anders

> Johan
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJQN2ssAAoJEEzjkVbXgH+MtPwH/A83KvrZygd54butoGlyUNRD
> QDwUWaaZtRBMLEcHofw085EN55zQ9KnmciimKPgOPJxUDVt+U+TTG1YOg/qTeddx
> nqCnW1np3pj7MitfJ101HIJnqs1QE/Xrak1on+Wsd548ao9BxrlK/+bM8REbfJCV
> mHaZ0aU7rjx7P1/xndIdy5wNOJIIEPoS4BiHoVP+mszqR32BNWOfi5cGcHBiURp0
> pwJbyb32OYMa+XLco/LgGoMrfGgY8M8xHzS2gANJji761Hl+ed5KU/GFfFD5ktVB
> ExnLpV7vLq5O5BpTUPuyVj9RqiWr8FC3RqZgPwo7xn/qpfK8QIs7iZ1uo8yN8EU=
> =hZyM
> -----END PGP SIGNATURE-----
>
>
> ** Changed in: dolfin
> Status: In Progress => Fix Committed
>