dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Monday 08 December 2008 13:55:26 Anders Logg wrote:
> On Mon, Dec 08, 2008 at 08:01:32AM +0100, Johan Hake wrote:
> > On Sunday 07 December 2008 23:33:53 Anders Logg wrote:
> > > Something that needs to be added to the new Function interface is
> > > reading functions from file. This has worked before:
> > >
> > >   f = Function("function.xml")
> > >
> > > Can this be added to the metaclass machinery?
> >
> > No, but to the __new__ function ;) so I guess yes!
> >
> > The metalclass produces Function classes. The __new__ function
> > instantiate new Functions from what ever argument. This is such a case.
>
> It looks like some work is needed to get this in place.
>
> The "constructor" currently looks as follows:
>
>     def __new__(cls, V, **kwargs):
>
> so to do
>
>     f = Function("function.xml")
>
> we need to check if V is a string. Could you add some hooks for this?

I will have a look at it. I do not like V beeing both a FunctionSpace and 
potentially a filename. I consider having a bunch of kwargs, all defaulting 
to None. E.g. 

  def __new__(cls, V=None,cpparg=None,defaults=None,filename=None):

Then if you create a Function from file you do:

  f = Function(filename="some_function.xml")

the cpparg can the repreresent what is sent to compile_function.

> Also, we need to figure out how to define the file format for
> Functions.
>
> Currently, it looks like this:
>
> <dolfin ...>
>   <function>
>     <mesh ...>
>       ...
>     </mesh>
>     <vector ...>
>       ...
>     </vector>
>     <finiteelement signature="..."/>
>     <dofmap signature="..."/>
>   </function>
> </dolfin>
>
> Should we change the file format to reflect the new design? We would
> need something like this:
>
> <dolfin ...>
>   <function>
>     <functionspace>
>       <mesh>
>         ...
>       </mesh>
>       <finiteelement signature="..."/>
>       <dofmap signature="..."/>
>     </functionspace>
>     <vector ...>
>       ...
>     </vector>
>   </function>
> </dolfin>

The loaded function instantiate a FunctionSpace in any case, so I guess the 
present format is good enough.

Our problem is that, after we have instantiated the cpp.Function, together 
with the cpp.FunctionSpace, we then have to reverse engeneer the 
ffc.FiniteElement together with the dolfin.FunctionSpace.

> We also need to change the signature strings so that one may
> create form compiler elements (and dofmaps) from the strings.
>
> The simplest option could be to let the signature be something like
>
>    FiniteElement("Lagrange", "triangle", 1)

So you mean substituting the present 

  "Lagrange finite element of degree 1 on a triangle"

with the above? Won't this signature be lost in the parsing of the XMLFile, or 
do you meen that we should parse the function.xml file after we have sent it 
to cpp.Function() and then extract the element signature?

> so that we may create the objects using exec() directly on the
> strings, perhaps prepended with the name of the form compiler:
>
>    ffc.FiniteElement("Lagrange", "triangle", 1)
>
> This will be supported through __repr__ which is implemented correctly
> in UFL (but not in FFC).
>
> If this looks reasonable, could you take a look to see what's needed
> on the Python side and I can take a look at updating the XML format?

I will implement the Function/Functions thing so I can take a look at the 
Function(filename="thing") too, when I get the time...

Johan