ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, May 12, 2011 at 07:39:39PM +0200, Martin Sandve Alnæs wrote:
> 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.

ok. I'm currently working on sorting out some remaining cache problems
in the FFC JIT compiler. That should hopefully take care of the
remaining tests that fail in DOLFIN. When that works, I can try out
the reconstruction.

--
Anders


> 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
> >
> >>
> >>
> >>> > 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
> >>
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ufl
> Post to     : ufl@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ufl
> More help   : https://help.launchpad.net/ListHelp