ufl team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Monday 06 April 2009 13:44:14 Martin Sandve Alnæs wrote:
> I'm not sure, I was just thinking about this...
>
> Say we have:
>
>   V = VectorElement("CG", triangle, 1)
>   P = FiniteElement("CG", triangle, 1)
>   TH = V+P
>   up = Function(TH)
>
> then up.shape() == (3,) and thus len(up) == 3 and you can do
>
>   ux, uy, p = up # only considers the value shape
>   u = as_vector((ux, uy))
>
> while ufl.split works like this:
>
>   u, p = split(up) # deals with the mixed element structure
>   len(u) == 2
>
> We can only implement __iter__ to do one thing!

A naive solution could be to overload the __len__ and __iter__ functions in 
ufl.Functions, so they return the subfunctions as they are used in split()?

I have __no__ clue what so ever to what other things this potentially could 
break ;)

> It might be for ambiguities similar to this that I didn't
> implement this earlier, but I don't remember any
> more compelling reasons...
>
> In PyDOLFIN, Function.split() is something else?
>
> It creates SubFunctions, which can't be used in forms.
> Right? 

As it is now you are actually able to use the returned subfunction to define 
forms. It's a bug which I will fix :P. 

It turns out that the subfunctions has two version of the FunctionSpace. One 
in python, which is just the original FunctionSpace that was used to define 
the MixedFunctionSpace and one which is the correct FunctionSpace, including 
the correct offset, which is stored by the c++ version. Nice! Not...

I will fix this so the versions correponds.

> I think we should keep that explicit. 

While I see the ambiguity I implemented this in PyDOLFIN.

Now in the stokes demo we can do:

  u, p = problem.solve()

This is what you thought of Anders? You desides what get pushed :)


Johan