ufl team mailing list archive

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

On Mon, Feb 23, 2009 at 12:36 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> On Mon, Feb 23, 2009 at 11:51:42AM +0100, Martin Sandve Alnæs wrote:
>> Looks ok, but I simplified it further.
>
> Looks nice and simple.
>
>> Note that we might need a more sofisticated renumbering
>> later, to discover that e.g. u[i]*v[i] and u[j]*v[j] are the
>> same expression, for fast optimization of quadrature code.
>
> ok
>
>> Also, I moved the argument renumbering to FormData,
>> take a look at it. I've removed the "classes" and
>> "*_renumbering" members of FormData. We should
>> go through the FormData structure soon to finalize
>> it as well as we can.
>
> I wasn't aware that FormData already did some renumbering. What does
> it renumber and how does it relate to renumber_indices?

It didn't renumber anything, what I removed was a numbering mapping,
mapping each function to its place in the form in [0,n).
But now it renumbers the form arguments (not the indices).
It has to apply expand_derivatives before this, since
this can result in changes in the argument list.
(I don't really like this, see the FIXME comment in formdata.py).
The current implementation of expand_derivatives calls expand_compounds.

If you make a formdata:

  fd = FormData(a)

You get e.g. a list of functions:

  fd.coefficients

which have counts in [0,n),
and can get the original argument (e.g. the PyDOLFIN Function)
from the dict original_arguments:

  for f in fd.coefficients:
      original_f = fd.original_arguments[f]

>> I've confusingly used the term "coefficient" in e.g.
>> FormData, I guess we should stick to "function" in UFL.
>> Agreed?
>
> Agree, but there will be a coefficient thing in the monomial
> representation where functions are expanded to
>
>  f = f_i v_i

Do you need to represent this sum explicitly?
Some extension to UFL will be needed to do that.

Martin