ufl team mailing list archive

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

On Mon, Feb 23, 2009 at 2:10 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> On Mon, Feb 23, 2009 at 02:05:00PM +0100, Martin Sandve Alnæs wrote:
>> 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]
>
> ok.
>
>> >> 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.
>
> No, implicitly via indices.

What do you mean? Using actual indices to represent this sounds like a
rather explicit representation :)

But I guess you're keeping your own data structure for this, so I
don't need to care?

Martin