dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Dec 08, 2008 at 02:31:23PM +0100, Johan Hake wrote:
> 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.

Then it would be different from the C++ constructor (which doesn't
handle named default arguments) and the Mesh constructor in both C++
and Python:

  mesh = Mesh("mesh.xml")

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

Yes.

> > 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?

Yes, first create the cpp.Function, then extract
v.function_space.element().signature() and use that to create the form
compiler element. Will that work?

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

ok.

-- 
Anders

Attachment: signature.asc
Description: Digital signature