dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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... :-)

--
Anders

Attachment: signature.asc
Description: Digital signature