On Monday 16 February 2009 01:04:55 A Navaei wrote: > 2009/2/14 Johan Hake <[email protected]>: > > On Saturday 14 February 2009 21:09:34 A Navaei wrote: > >> 2009/2/14 Johan Hake <[email protected]>: > >> [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 _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
