ufl team mailing list archive

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

I've pushed some changes to lp:~martinal/ufl/reconstruction mostly
implementing the ufl side of taking an (optional) element_mapping
as input to preprocess, but I want to test it a bit more before pushing
to trunk.

Martin

On 12 May 2011 18:28, Martin Sandve Alnæs <martinal@xxxxxxxxx> wrote:
> 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
>>
>