dolfin team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/12/3 Anders Logg <logg@xxxxxxxxx>:
> On Wed, Dec 03, 2008 at 05:29:14PM +0100, Martin Sandve Alnæs wrote:
>> 2008/12/3 Anders Logg <logg@xxxxxxxxx>:
>> > On Wed, Dec 03, 2008 at 03:18:35PM +0100, buildbot@xxxxxxxxxx wrote:
>> >> The Buildbot has detected a new failure of linux_64.
>> >> Full details are available at:
>> >>  http://fenics.org:8010/dolfin/linux_64/builds/1082
>> >>
>> >> Buildbot URL: http://fenics.org:8010/dolfin/
>> >>
>> >> Buildslave for this Build: x64-linux
>> >>
>> >> Build Reason:
>> >> Build Source Stamp: HEAD
>> >> Blamelist: Anders Logg
>> >>
>> >> BUILD FAILED: failed test
>> >>
>> >> sincerely,
>> >>  -The Buildbot
>> >>
>> >> _______________________________________________
>> >> DOLFIN-dev mailing list
>> >> DOLFIN-dev@xxxxxxxxxx
>> >> http://www.fenics.org/mailman/listinfo/dolfin-dev
>> >
>> > Should be fixed now. I removed the extra test added to
>> > Coefficient::attach.
>> >
>> > Don't know yet why the extra test breaks (probably in the call to
>> > Function::in).
>>
>> This call compares the function space object addresses, so it's no
>> wonder it fails.
>
> That might very well be the reason, but the error message seems to
> indicate something else.
>
> But why shouldn't it be ok to compare the pointers? I imagine that
> shared_ptr has implemented a reasonable comparison operator that does
> the right thing.

In this case because you were sending in one "old" pointer and one
newly created. They could never be the same.

And in general, if someone does _not_ reuse FunctionSpaces optimally,
we'll get a situation where V1 is a function space on the same mesh
and with the same element as V0. Then given Function f(V0);, we should
have f.in(V1) == true, while &V0 != &V1.

--
Martin