ufl team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

2009/4/6 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()?

Yes, that's the general idea, but then iteration over a Function and
another ufl expression won't work the same way. If that's what we
choose to do I will probably remove iteration over general expressions,
because this will be too confusing.


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

For some reason I had explicitly implemented __iter__ using
NotImplemented to signal it shouldn't be used, and as I said
I don't remember why that was:

>> 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 won't even try to wrap my head around that paragraph,
this is why I'm continuing to use C++ while getting UFL done :-/
(Don't waste your time trying to explain it better,
I just don't want to know at this point)


>> 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 :)

But what does this mean?
  u, p = ufl.split(up)
or
  u, p = up.split()
?

Unless there is a solution to make these the same (which seems
complicated), I still think this should be done explicitly.

Also, I've said before: PyDOLFIN.Function should _not_ implement
any special functions (__foo__) since they may interfere with UFL.
The "u, p = up" feature breaks with this.

Martin