ufl team mailing list archive

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

On 12 May 2011 17:32, Anders Logg <logg@xxxxxxxxx> wrote:
> On Thu, May 12, 2011 at 05:16:30PM +0200, Martin Sandve Alnæs wrote:
>> On 12 May 2011 12:13, Anders Logg <logg@xxxxxxxxx> wrote:
>> > On Thu, May 12, 2011 at 10:52:50AM +0100, Garth N. Wells wrote:
>> >> Since there are no commit messages, can you tell us where the UFL/FFC
>> >> fixes to get DOLFIN working again are at?
>> >
>> > How do you mean? I don't yet know which fixes should be made to get
>> > DOLFIN working again or I would have fixed it already.
>> >
>> > I've fixed quite a few issues. FFC is green again and the test cases
>> > I've been using (JIT-compilation of Expressions and the DOLFIN
>> > function unit tests) run.
>> >
>> > The changes I've made are mainly to analysis.py (FFC) and
>> > preprocess.py (UFL) + tons of other files.
>> >
>> > The main outline of the change is:
>> >
>> > 1. preprocess tries to figure out the common cell
>> >
>> > 2. no elements are modified or mapped
>>
>> Hmm...
>>
>> Then the signature of the form will still be incomplete after preprocessing.
>> If there is no valid cell in the form, the form signature does not
>> identify whether it is in e.g. R^2 or R^3. Or am I missing something?
>
> That's true. I didn't think about that. Hmm...
>
> But perhaps that's not really a problem after all? The form compiler
> should select the same elements the second time it sees a form with
> the same signature containing unknowns.
>
> I can think of one case when this can go wrong which is the case when
> one integrates an expression over with unspecified domain in 2D, and
> then later wants to integrate the same expression in 3D, and the 2D
> version gets reused. We can get around this by including common_cell
> passed to the JIT compiler in the signature used for caching.

Reusing the same form for 2D and 3D is not possible anyway.

> Are there other cases when this can go wrong?

While your analysis may currently be right (I can't be sure), we can't
follow the "what could possibly go wrong" kind of logic when defining
a language like UFL. In particular when the logic depends on how ffc
and pydolfin happens to work today. To handle unforeseen combinations
(which is kinda the point of a language) we need to be able to
guarantee certain properties of objects. There are too many
combinations to enumerate and test them all.

I'll take a shot at implementing reconstruct tonight.

Martin

> --
> Anders
>
>
>> > 3. FFC keeps track of suitable values for cells and degrees when they
>> > are missing (as part of element_data computed in analysis.py)
>> >
>> > I'm about to leave my office and be offline for a few hours.
>> >
>>
>> But the preprocess function does look nice now at least :)
>>
>> Martin
>