dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Monday 16 February 2009 01:04:55 A Navaei wrote:
> 2009/2/14 Johan Hake <hake@xxxxxxxxx>:
> > On Saturday 14 February 2009 21:09:34 A Navaei wrote:
> >> 2009/2/14 Johan Hake <hake@xxxxxxxxx>:
> >>  [snip]
> >>
> >> >> > Again, you do not want to do this as you then won't be able to use
> >> >> > your overloaded eval function, as the Function will then be treated
> >> >> > to be discrete, i.e., using the coefficients in _vector together
> >> >> > with the basis function in the FunctionSpace to interpolate any
> >> >> > eval().
> >> >>
> >> >> Yes, that's why I'm working on wrapping shared_ptr.
> >> >
> >> > Then you should definetly switch to the development version, or you
> >> > won't get it to work ;)
> >>
> >> Raw pointers get wrapped fine.
> >
> > Ok.
> >
> >> I simply tried replacing
> >> dolfin/swig/*.i with the new development versions, but it didn't help.
> >
> > No you have to switch the whole cake, together with ufc, ffc, and instant
> > :)
>
> I've tried it with the development version. Finally, boost:shared_ptr
> gets wrapped, 

Good!

> however, the resulting python objects are not really useful. 
> in the current dolfin wrapping mechamism. Here is a demonstraion:
>
> In [43]: from dolfin import *
> In [44]: mesh = UnitSquare(100, 100)
> In [45]: V = FunctionSpace(mesh, "CG", 1)
> In [46]: f = Function(V)
>
> In [47]: f.function_space()
> Out[47]: <dolfin.functionspace.FunctionSpace; proxy of <Swig Object of
> type 'boost::shared_ptr< dolfin::FunctionSpace > *' at 0x9e64880> >
>
> In [48]: f.function_space_ptr()
> Out[48]: <dolfin.cpp.FunctionSpace; proxy of <Swig Object of type
> 'boost::shared_ptr< dolfin::FunctionSpace > *' at 0xa9d8540> >
>
> So, they are both proxies of the same class defined in different
> modules. Now, let's check the type:
>
> In [50]: isinstance(f.function_space(), FunctionSpace)
> Out[50]: True
>
> In [51]: isinstance(f.function_space_ptr(), FunctionSpace)
> Out[51]: False

The wrapper defined in dolfin.functionspace.FunctionSpace is just adding suger 
to be able to define FunctionSpaces using a python form compiler a la:

   V = FunctionSpace(mesh,"Lagrange",1)
  
If you instead test for 

  isinstance(f.function_space(), cpp.FunctionSpace)
  isinstance(f.function_space_ptr(), cpp.FunctionSpace)

above you should get True in both cases, as dolfin.functionspace.FunctionSpace  
inherits cpp.FunctionSpace which is the actuall swig generated proxy class 
the c++ version of FunctionSpace. This is also the type that is returned from 
f.function_space_ptr().

> Despite this, all functions can be called just the same as each other:
>
> In [53]: f.function_space().dim()
> Out[53]: 10201
>
> In [54]: f.function_space_ptr().dim()
> Out[54]: 10201

That is because the first one just calls its parents dim which is the same 
that the latter is calling.

> So effectively, since the python functions perform type checking using
> isinstance, they block the wrapped shared pointers, eg:
>
> interpolate(f, f.function_space())
>
> works, but,
>
> interpolate(f, f.function_space_ptr())
>
> doesn't.

You are right. This is a bug. Should soon be fixed.

To Anders:

When a functionality in python just need the cpp version of a class then check 
for that instead of our python wrappers. This is the kind of issues Martin 
predicted. E.g., in interpolate.py we do not need the Function and 
FunctionSpaces to be our wrapped versions, as no Form compiler information is 
needed.

Johan