← Back to team overview

dolfin team mailing list archive

Re: Image to Function data structure conversion

 

On Mon, Feb 16, 2009 at 08:19:42AM +0100, Johan Hake wrote:
> 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

ok, I'll try to remember.

-- 
Anders

Attachment: signature.asc
Description: Digital signature


References