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 <[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
ok, I'll try to remember. -- Anders
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
