ufl team mailing list archive

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

On Mon, Apr 20, 2009 at 2:02 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> On Mon, Apr 20, 2009 at 01:39:06PM +0200, Martin Sandve Alnæs wrote:
>> On Mon, Apr 20, 2009 at 1:27 PM, Anders Logg <logg@xxxxxxxxx> wrote:
>> > On Mon, Apr 20, 2009 at 01:21:07PM +0200, Martin Sandve Alnæs wrote:
>> >> Yes, I agree that the data flow can be confusing,
>> >> and I've intended to discuss it for a while.
>> >> But there's so much to do and so little time, we
>> >> can't do any major restructuring right now anyway...
>> >>
>> >> In SFC, I do this as the first thing:
>> >>
>> >>   fd = input_form.form_data() # not recomputed if done before
>> >>   form = fd.form # has applied all common expansions and renumberings
>> >>
>> >> From that point I use fd and form, never touch input_form
>> >> again, and never call form_data() again. Do that in FFC, and
>> >> you should be safe.
>> >
>> > We do something similar, but it gets a bit ugly since we want to
>> > modify the integral metadata (set correct representation and
>> > quadrature order if not already set by a user). So then we first call
>> > form_data() only to be able to estimate the quadrature order. Then we
>> > need to call form_data() again on the modified form after having
>> > modified the integral metadata.
>>
>>
>> This calling of form_data on the second form will result in
>> a new computation, which is costly.
>>
>> If the metadata is the only thing you modify, can't
>> you store the modified metadata outside the form?
>
> Yes, good idea. I changed this so it's now stored as a dictionary in
> form_data named metadata. It can be accessed by
>
>  form_data.metadata[integral]
>
> FFC attaches a number of extra data to form_data after it has been
> created by UFL. Some is FFC specific, such as form_data.ffc_elements
> (FFC wrappers for FIAT elements corresponding to the UFL elements) but
> some others may be worthwile to include in ufl.FormData.
>
> Take look at analyze_form in ffc/compiler/uflcompiler.py if some of
> these can be placed in ufl.FormData.
>
>> >  # Validate form
>> >  validate_form(form)
>> >
>> >  # Set metadata for all integrals (requires form_data().form)
>> >  new_form = Form([])
>> >  for integral in form.form_data().form.integrals():
>> >      new_form += Form([_set_integral_metadata(integral, options)])
>> >  form = new_form
>> >
>> >  # Extract form data
>> >  form_data = form.form_data()
>> >  form = form_data.form
>> >
>> >> Most algorithms work on expanded expressions,
>> >> but that could be documented better. Some assume
>> >> already expanded expressions, and some call
>> >> expand functions, and this is not consistent.
>> >> Don't hesitate to ask or report if something specific is unclear.
>> >
>> > Is it possible to either set a flag that can be checked by algorithms
>> > requiring expanded expressions, or that these algorithms call
>> > expand_compounds?
>> >
>> > It's confusing if something is required by an algorithm and it doesn't
>> > report an error if that requirement is not met.
>>
>> That's a solution I have considered, but not found the time to go into detail.
>> Such flags must be possibly be propagated many places, the implementation
>> could be very error prone if not done carefully.
>
> Yes, let's check back on this later, but it's very important to put in
> some checks, especially since the functions sometimes return something
> that looks valid but is incorrect (like wrong integrand degree).

We can remove the default behaviour of DegreeEstimator
and implement rules for all operators that should be supported.

Martin