dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

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.

Johan