← Back to team overview

dolfin team mailing list archive

Re: More problem with Expressions in Python

 

On Friday 16 October 2009 14:50:45 Anders Logg wrote:
> On Fri, Oct 16, 2009 at 02:42:13PM +0200, Johan Hake wrote:
> > On Friday 16 October 2009 14:13:34 Anders Logg wrote:
> > > I have an Expression class with a member function that looks like this:
> > >
> > >   void update(boost::shared_ptr<const dolfin::Function> u)
> > >   {
> > >    ...
> > >   }
> > >
> > > I used to be able to send in a Python Function as argument to this
> > > from Python but not anymore. I get the following error message:
> > >
> > >   argument 2 of type 'boost::shared_ptr< dolfin::Function const >'
> > >
> > > This indicates that my Python Function is not recognized as something
> > > that can be used as an argument for
> > >
> > >   boost::shared_ptr< dolfin::Function const >
> > >
> > > Any ideas what goes wrong?
> >
> > Yes, previously we sub-classed Function, so your user defined Function
> > were of course aware of the class Function. That is not the case now. We
> > need to expose Function to our compiled expression. We might also want to
> > expose several DOLFIN classes, for example MeshFunction. However it is
> > difficult to get hold of all possible types, and we wont get the SWIG
> > specializations done in the foo_pre.i and foo_post.i files as these will
> > not med imported.
> >
> > We need to think how this should be done. We might import all types
> > together with all specializations, this will create _a lot_ of
> > unnecessary type code and double the amount of wrapper code generated, or
> > we could try to figure out what DOLFIN classes that is used by a simple
> > lookup. The last example could be made more easy if we had modularized
> > DOLFIN. This is kind of drastic.
> >
> > As an intermediate (or possible permanent) fix we could organize special
> > files that imports the content of the swig modules:
> >
> >   %include <dolfin/swig/dolfin_function.i>
> >
> > which would expose all types in the function module to the
> > compiled_expression. Again this could be done automagically. If a user
> > use MeshFunction in the code we then also put the line
> >
> >   %include <dolfin/swig/dolfin_mesh.i>
> >
> > in the generated SWIG interface file.
> 
> I see. Could you expose at least Function and MeshFunction?
> 
> I really need Function... :-)

Just for you ;)

Might not be until tonight though...

Johan


References