ffc team mailing list archive

[Kristian Oelgaard <k.b.oelgaard@xxxxxxxxxx>]

Quoting Martin Sandve Alnæs <martinal@xxxxxxxxx>:

> On Fri, Mar 6, 2009 at 10:23 AM, Kristian Oelgaard
> <k.b.oelgaard@xxxxxxxxxx> wrote:
> > Quoting FFC <ffc@xxxxxxxxxx>:
> >
> >> One or more new changesets pushed to the primary ffc repository.
> >> A short summary of the last three changesets is included below.
> >>
> >> changeset:   1372:19f68f217564f18384dd29d30081268e1d583163
> >> tag:         tip
> >> user:        Anders Logg <logg@xxxxxxxxx>
> >> date:        Thu Mar 05 22:19:10 2009 +0100
> >> files:
> >> ffc/compiler/representation/quadrature/uflquadraturerepresentation.py
> >> ffc/compiler/representation/tensor/tensorrepresentation.py
> >> ffc/compiler/representation/tensor/ufltensorrepresentation.py
> >> ffc/compiler/uflcompiler.py
> >> description:
> >> Use form instead of form_data in compiler stage 3
> >
> > This caused me quite a bit of grief.
> >
> > Try:
> > print form
> > print form.form_data().form
> >
> > on any form involving functions. In the first instance the coefficients has
> > arbitrary indices, in the second the index corresponds to the correct
> function
> > number in the form.
> >
> > Maybe I'm the only one not knowing this but it did break the quadrature
> > generation.
> >
> > Kristian
>
> Also, in the second one, derivatives are expanded
> and indices renumbered from 0.
>
> Without expanded derivatives, the functions and
> basis functions are not correct for all forms.

Yup, that's part of what broke.

> Without renumbered indices and arguments,
> the repr-based signature will often break.
>
> I'm always using form_data().form in the form compiler.

Me too, from now on that is....

> For the record, try this:
>   print form.form_data().original_form
>
> Which gives back the untransformed form.
>
> Any reason why you're not using load_forms?

I didn't know that it existed or what it does, but it looks like it should/could
be used in the top ffc script. Anders?

Kristian

> Martin
>