dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Dec 03, 2008 at 10:33:23AM +0100, Johan Hake wrote:
> On Wednesday 03 December 2008 10:19:26 Anders Logg wrote:
> > On Wed, Dec 03, 2008 at 09:27:15AM +0100, Johan Hake wrote:
> > > On Tuesday 02 December 2008 23:53:32 Anders Logg wrote:
> > > > On Tue, Dec 02, 2008 at 11:39:40PM +0100, Johan Hake wrote:
> > > > > On Tuesday 02 December 2008 23:15:34 Anders Logg wrote:
> > > > > > On Tue, Dec 02, 2008 at 10:35:31PM +0100, Johan Hake wrote:
> > > > > > > On Tuesday 02 December 2008 15:42:53 Anders Logg wrote:
> > > > > > > > On Tue, Dec 02, 2008 at 12:12:14PM +0100, Anders Logg wrote:
> > > > > > > > > I've tried adding a new class Constant in function.py:
> > > > > > > > >
> > > > > > > > > class Constant(ffc.Constant, dolfin.cpp_Function):
> > > > > > > > >
> > > > > > > > >     def __init__(self, domain, value):
> > > > > > > > >         "Create constant-valued function."
> > > > > > > > >         print domain
> > > > > > > > >         print value
> > > > > > > > >         #ffc.Constant.__init__(self, domain)
> > > > > > > > >         #dolfin.cpp_Constant.__init__(self, value)
> > > > > > > > >
> > > > > > > > > But I get the following error message:
> > > > > > > > >
> > > > > > > > >   File
> > > > > > > > >
> > > > > > > > > "/scratch/fenics/dolfin/dolfin-dev/local/lib/python2.5/site-p
> > > > > > > > >acka ges/ dolf in/function.py", line 411, in <module> class
> > > > > > > > > Constant(ffc.Constant, dolfin.cpp_Function):
> > > > > > > > > TypeError: Error when calling the metaclass bases
> > > > > > > > >     function() argument 1 must be code, not str
> > > > > > > > >
> > > > > > > > > How is this possible? There should be no metaclasses involved
> > > > > > > > > here (except the built-in Python metaclass type that is
> > > > > > > > > always there).
> > > > > > >
> > > > > > > Meta classes is always involed when you try to create a class.
> > > > > > > This time it is not the FunctionCreator meta class, even if you
> > > > > > > first think so.
> > > > > > >
> > > > > > > If you ever tried to subclass a python function, which you are
> > > > > > > trying, you
> > > > > > >
> > > > > > > will get the same error:
> > > > > > >   >>> def jada():pass
> > > > > > >
> > > > > > >   ...
> > > > > > >
> > > > > > >   >>> class Jada(jada):pass
> > > > > > >
> > > > > > >   ...
> > > > > > >   Traceback (most recent call last):
> > > > > > >     File "<stdin>", line 1, in <module>
> > > > > > >   TypeError: Error when calling the metaclass bases
> > > > > > >       function() argument 1 must be code, not str
> > > > > > >
> > > > > > > ffc.Constant is a function not a class...
> > > > > >
> > > > > > Sorry, my fault. It looks like someone did a clever trick when
> > > > > > implementing Constant in FFC as a function and not a class... :-)
> > > > > >
> > > > > > > > I get this error even if I just try to create a class named
> > > > > > > > anything that inherits from ffc.Constant.
> > > > > > > >
> > > > > > > > Does the metaclass construction in function.py have
> > > > > > > > side-effects?
> > > > > > >
> > > > > > > Well, for it's use I think it works fine. The user should never
> > > > > > > bother with the metaclass, as the newly added quote to the
> > > > > > > docstring is mentioning.
> > > > > > >
> > > > > > > What we need to do is to assert the user use the Function class
> > > > > > > correct. I have tried to put in some checks with hopefully
> > > > > > > informative error messages. But I dont know if I have covered all
> > > > > > > bases. We need user feedback for this.
> > > > > >
> > > > > > I'm sure the checks are very good, but could the logic be broken up
> > > > > > to first split on the different types, so there's essentially one
> > > > > > case for each of the different options in the Function docstring,
> > > > > > and then a function is called for each case to do the work?
> > > > > >
> > > > > > > > I don't remember if we discussed this before, but would it be
> > > > > > > > possible (at least simpler) to instead define a simple Python
> > > > > > > > function that returns a "function" instance:
> > > > > > > >
> > > > > > > > class FooFunction(ffc.Function, ...):
> > > > > > > >     ...
> > > > > > > > class BarFunction(dolfin.Function, ...):
> > > > > > > >     ...
> > > > > > > >
> > > > > > > > def Function(V, *arg):
> > > > > > > >
> > > > > > > >     if foo:
> > > > > > > >         return FooFunction(...)
> > > > > > > >     elif bar:
> > > > > > > >         return BarFunction(...)
> > > > > > > >
> > > > > > > > This seems to be an easier solution. It would still be dynamic.
> > > > > > >
> > > > > > > This is mre or less what is going on right now. Instead of
> > > > > > > predefining the different classes they are defined dynamically in
> > > > > > > the __new__ function. We need to do this because the compiled
> > > > > > > functions are created at runtime.
> > > > > > >
> > > > > > > I can try to untangle the code a bit as asked for previously. The
> > > > > > > suggestion below which will extract the instantiation of compiled
> > > > > > > functions and discrete functions is one more radical example.
> > > > > >
> > > > > > ok.
> > > > > >
> > > > > > > > The only drawback would be that we can't do
> > > > > > > >
> > > > > > > >   isinstace(v, Function)
> > > > > > >
> > > > > > > This is not possible now either, as we are dynamically creating
> > > > > > > classes in __new__, and returning instances of other classes than
> > > > > > > Function
> > > > > > >
> > > > > > > Basically we are now dynamically creating Function classes that
> > > > > > > are all having the name "Function" but they are not of the same
> > > > > > > class. This can be illustrated by this:
> > > > > > >
> > > > > > >   class Function(object):
> > > > > > >       def __new__(cls,cppexpr=None):
> > > > > > >           if cppexpr is None:
> > > > > > >               return object.__new__(cls)
> > > > > > >           class CompiledClass(object):pass
> > > > > > >           class Function(CompiledClass):pass
> > > > > > >           return Function()
> > > > > > >
> > > > > > >   f  = Function()
> > > > > > >   f2 = Function(cppexpr="")
> > > > > > >
> > > > > > >   isinstance(f,Function)  # This will return True
> > > > > > >   isinstance(f2,Function) # This will return False
> > > > > > >
> > > > > > > I cannot see how we can avoid this, as we need to create classes
> > > > > > > at runtime. As you mention we could add a FunctionBase class that
> > > > > > > we could check against. But I was convinced by Martins argument
> > > > > > > previously that in PyDOLFIN code we never want to check if a
> > > > > > > function is both a cpp_Function and a ffc.Function, but rather
> > > > > > > for one of them. We could write this as a note for developers of
> > > > > > > PyDOLFIN, and live with it.
> > > > > > >
> > > > > > > I am a bit more worried for advanced python users that do not
> > > > > > > know of this. They could write user code that include
> > > > > > > isinstance(f,Function) statements, and it wont behave as
> > > > > > > expected.
> > > > > > >
> > > > > > > We could add a
> > > > > > >
> > > > > > >   CompileFunction(cppexpr=None, cppcode=None)
> > > > > > >
> > > > > > > which behave in the same manner as Function(cppexpr/cppcode) does
> > > > > > > today. In this way we can dynamically create functions that
> > > > > > > inherits, cpp_JitCompiledFunction, ffc.Function _and_
> > > > > > > dolfin.Function, where the latter is a class which is either an
> > > > > > > empty class or one that holds the FunctionSpace. If we do this we
> > > > > > > also need to have an additional function/class to instantiate
> > > > > > > discrete functions.
> > > > > > >
> > > > > > > This way to handle the isinstance problem can also be implemented
> > > > > > > for all cases where Function is subclassed, i.e., both for Jit
> > > > > > > compiled and ordinary python Functors.
> > > > > > >
> > > > > > > But I have a feeling we add more complexity than we remove...
> > > > > >
> > > > > > If I understand this correctly, it seems to be a simplification, or
> > > > > > at least it makes it more explicit which we all know is better
> > > > > > (import this).
> > > > > >
> > > > > > But I would like a Function class (or function) on top that
> > > > > > delegates the creation of Function objects to these classes.
> > > > > >
> > > > > > > > This can be solved by creating an empty class FunctionBase that
> > > > > > > > all the special types inherit from.
> > > > > > >
> > > > > > > This is the easiest way to fix the isinstance problem, but I
> > > > > > > think it is a bit unintuitive to check for FunctionBase when you
> > > > > > > have created a Function object.
> > > > > > >
> > > > > > > So I have scretched three possible ways to have it:
> > > > > > >
> > > > > > >   1) As it is now (with clearer code). Everything is handled with
> > > > > > >      the Function class. You cannot check for
> > > > > > > isinstance(f,Function)
> > > > > > >
> > > > > > >   2) Add CompiledFunction and DiscreteFunction. You can now
> > > > > > >      check for isinstance(f,Function) everywhere.
> > > > > > >
> > > > > > >   3) Add FunctionBase, you can now check for
> > > > > > > isinstance(f,FunctionBase)
> > > > > > >
> > > > > > > I go for either 1 or 2.
> > > > > >
> > > > > > I'd like all of the above! :-)
> > > > > >
> > > > > > 1. One single Function class using the metaclass trick to return
> > > > > > instances with dynamic inheritance.
> > > > >
> > > > > Ok.
> > > > >
> > > > > Just for repetition:
> > > > > The metaclass is used to construct new classes that dynamically
> > > > > inherit Jit compiled classes, not instances. The latter is done in
> > > > > the __new__ function.
> > > > >
> > > > > > 2. Add classes CompiledFunction, DiscreteFunction etc that handle
> > > > > > all the different ways in which the C++ part of a Function can
> > > > > > behave.
> > > > >
> > > > > My point was to add these for the user when he/she want to
> > > > > instantiate one fo these classes. This would be instead of the
> > > > > instantiation functioanlity handled by __new__ in the present
> > > > > Function class, and the whole point with introducing them would be to
> > > > > be able to use
> > > > >
> > > > >   isinstance(u,Function)
> > > > >
> > > > > where u can be any of the possible Functions we want to have.
> > > >
> > > > Maybe we could add CompiledFunction since it's rather special, but I'd
> > > > like to avoid adding DiscreteFunction in the user interface. It would
> > > > be good if the Python interface could be kept very uniform with the
> > > > C++ interface:
> > > >
> > > >   Function v(V);
> > > >
> > > >   v = Function(V)
> > > >
> > > > > > The created instances will inherit from ffc.Function (later
> > > > > > ufl.Function) and one of these classes.
> > > > >
> > > > > I am not with you here, or you are not with me ;)
> > > > >
> > > > > I mean that the created Function need to inherit FFC.Function
> > > > > together with what ever cpp_Function and a dummy dolfin.Function that
> > > > > the user could use to check, as showed above.
> > > > >
> > > > > We need to do this because a function that is instantiated from a
> > > > > dynamically created class using Function.__new__ cannot inherit
> > > > > Function, we will get an inherit recursion.
> > > > >
> > > > > But if we split out the instantiation magic we can create classes
> > > > > that all inherit Function (my 2), or we can keep the instantiation
> > > > > magic and introduce a FunctionBase class (my 3).
> > > >
> > > > My only concerns are:
> > > >
> > > > 1. A simple interface that corresponds closely to the C++
> > > > interface. In C++, we have
> > > >
> > > >   Function: can be either discrete or user-defined (subclassed)
> > > >
> > > >   Constant: special case for constants to avoid too many different
> > > >             constructors in Function
> > > >
> > > > In Python, we could then have the two above, plus an extra version
> > > > which does not exist in C++ (for obvious reasons):
> > > >
> > > >   CompiledFunction
> > > >
> > > > Would this help?
> > >
> > > W.r.t. solving the isinstance(f,Function) problem, I think no. As the
> > > Function class then always have to be a discrete function. If we let a
> > > compiled function inherit Function to facilitate isinstance, we also
> > > force it to be a discrete function, which probably would make the
> > > compiled function abit schizofreniac.
> >
> > The way the Function class is implemented in C++, its nature may
> > change dynamically. For example, it may start out as a user-defined
> > function and then become a discrete function. This happens at the
> > first call to Function::vector().
> >
> > The reason for this is to allow defining an initial condition for a
> > function by overloading eval() with say sin(x) and then use that same
> > function in a time-stepping algorithm:
> >
> > class InitialCondition
> > {
> >   void eval(...)  { values[0] = sin(x[0]); }
> > };
> >
> > InitialCondition u0(V);
> >
> > while (t < T)
> > {
> >    // Solve for u1
> >    ...
> >
> >    // Assign u0 to u1
> >    u0.vector() = u1.vector();
> > }
> >
> > This is very convenient to have in C++ but is not necessary to have in
> > Python, since one may dynamically project things to discrete
> > functions:
> >
> > u0 = project(InitialCondition(), V)
> >
> > I imagine it will work the same way for compiled functions. Anything
> > that inherits from dolfin::Function may potentially initialize a
> > vector of degrees of freedom.
> 
> I think so. You should be able to check it with the current implementation. 
> Just call vector() after you have instantiated a user defined function.
> 
> > > This goes to the core of the isinstance problem. Now Function is a
> > > versatile class that can do many things but we cannot use it to check
> > > isinstance. If we desides that this is important, we need to split out
> > > the instantiation of the compiled _and_ discrete functions, if not we're
> > > fine.
> >
> > What is the big issue with checking
> >
> >   isinstance(v, FunctionBase)
> >
> > ?
> 
> Well, I have no objection, more than it is not optimal. But then we are 
> catched in a situation where we probably cannot get everything we want. So if 
> everyone is fine with this I can implement it. 
> 
> Then I won't add any CompileFunction class/function but keep it the way it is, 
> with soon-to-come clearer internal logic?

Sounds good, unless Martin has any better ideas? I don't.

Another thing I've been wondering about is the renaming of
dolfin::Function to dolfin.cpp_Function. Is this really necessary?

If we just removed the renaming, I guess it would still work out. So
we would create classes in function.py that inherit from ffc.Function
and dolfin.Function (instead of dolfin.cpp_Function).

-- 
Anders

Attachment: signature.asc
Description: Digital signature