ufl team mailing list archive

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

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.

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.

Martin



On Mon, Apr 20, 2009 at 1:06 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> On Mon, Apr 20, 2009 at 11:05:12AM +0200, Martin Sandve Alnæs wrote:
>> Try applying this to the form after expand_compounds etc has been applied.
>
> If expand_compounds is needed by an algorithm, then wouldn't it be
> better if that algorithm called expand_compounds?
>
> In general I find it the use of form, form.form_data() and form_data.form
> a bit confusing.
>
> I would like the program flow to be to call form.form_data() once and
> not having to call it in multiple places. Even validate_form is
> calling form.form_data().
>
> --
> Anders
>
>
>> In [20]: estimate_max_polynomial_degree(L.form_data().form)
>> Out[20]: 2
>>
>> In [21]: estimate_max_polynomial_degree(L.form_data().original_form)
>> Out[21]: 1
>>
>> This is because rules have not been defined for all types.
>>
>> In SFC I don't look at the original form at all,
>> using form.form_data().form from the start.
>>
>> Martin
>>
>>
>>
>> On Mon, Apr 20, 2009 at 10:59 AM, Kristian Oelgaard
>> <k.b.oelgaard@xxxxxxxxxx> wrote:
>> > Quoting Anders Logg <logg@xxxxxxxxx>:
>> >
>> >> I tried to use the new UFL function estimate_max_polynomial_degree
>> >> but the results seem to be incorrect for quadrature representation.
>> >> (Or the references are wrong which I doubt.)
>> >>
>> >> Kristian, can you take a look at this?
>> >>
>> >> Try running the test in simple_verify_tensors. It reports the
>> >> following errors:
>> >>
>> >> FunctionOperatorsBilinearForm_cell_integral_0:      *** (diff = 0.010098)
>> >> MassBilinearForm_cell_integral_0:                   *** (diff = 1e-09)
>> >> NeumannProblemLinearForm_cell_integral_0:           *** (diff = 0.0029685)
>> >
>> > This difference is because:
>> > element = VectorElement("Lagrange", triangle, 1)
>> >
>> > v = TestFunction(element)
>> > f = Function(element)
>> > L = inner(v, f)*dx
>> >
>> > results in:
>> > Input form: { sum_{i_0} ((v_0)[i_0]) * ((w_0)[i_0])  } *
>> > dx0<{'ffc_representation': 'tensor', 'quadrature_order': 1}>
>> >
>> > where the quadrature order should be 2.
>> >
>> > The tensor representation computes the degree elsewhere (which is 2) as far as I
>> > can tell from using the -d1 option.
>> >
>> > Kristian
>> >
>> >> NeumannProblemLinearForm_exterior_facet_integral_0: *** (diff = 0.00292)
>> >> OptimizationBilinearForm_cell_integral_0:           *** (diff = 2.19169)
>> >> PoissonDGBilinearForm_interior_facet_integral_0:    *** (diff = 0.3504)
>> >> PoissonSystemLinearForm_cell_integral_0:            *** (diff = 0.0029685)
>> >> QuadratureElementBilinearForm_cell_integral_0:      *** (diff = 0.249892)
>> >> QuadratureElementLinearForm_cell_integral_0:        *** (diff = 0.10106)
>> >> StokesLinearForm_cell_integral_0:                   *** (diff = 0.00140453)
>> >>
>> >>
>> >>
>> >> On Sun, Apr 19, 2009 at 06:23:03PM +0200, FFC wrote:
>> >> > One or more new changesets pushed to the primary ffc repository.
>> >> > A short summary of the last three changesets is included below.
>> >> >
>> >> > changeset:   1497:38268dcd85de2bfcae1094ed96ea584293320491
>> >> > tag:         tip
>> >> > user:        Anders Logg <logg@xxxxxxxxx>
>> >> > date:        Sun Apr 19 18:23:00 2009 +0200
>> >> > files:       ffc/compiler/uflcompiler.py
>> >> > description:
>> >> > Use new UFL function estimate_max_polynomial_degree to estimate quadrature
>> >> > degree. Seems to give wrong results for quadrature representation.
>> >> >
>> >> >
>> >> > changeset:   1496:2eaeb80e1d1fdf45208005bd1cc23016ca872919
>> >> > user:        "Garth N. Wells <gnw20@xxxxxxxxx>"
>> >> > date:        Sun Apr 19 14:26:22 2009 +0800
>> >> > files:       ffc/compiler/uflcompiler.py
>> >> > description:
>> >> > Fix silly error.
>> >> >
>> >> >
>> >> > changeset:   1495:4710241c0954645d8150ec6fcd1eb3bff4f6d333
>> >> > user:        "Garth N. Wells <gnw20@xxxxxxxxx>"
>> >> > date:        Sun Apr 19 13:47:10 2009 +0800
>> >> > files:       ffc/compiler/uflcompiler.py
>> >> > description:
>> >> > Small fix.
>> >> >
>> >> > ----------------------------------------------------------------------
>> >> > For more details, visit http://www.fenics.org/hg/ffc
>> >> > _______________________________________________
>> >> > FFC-dev mailing list
>> >> > FFC-dev@xxxxxxxxxx
>> >> > http://www.fenics.org/mailman/listinfo/ffc-dev
>> >>
>> >
>> >
>> > _______________________________________________
>> > FFC-dev mailing list
>> > FFC-dev@xxxxxxxxxx
>> > http://www.fenics.org/mailman/listinfo/ffc-dev
>> >
>> _______________________________________________
>> UFL-dev mailing list
>> UFL-dev@xxxxxxxxxx
>> http://fenics.org/mailman/listinfo/ufl-dev
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAknsV0wACgkQTuwUCDsYZdEYsACfeuTvMVgE/UAyn0Hmv3ve6kn8
> HeEAoIuHs4p/1Zdj+HguzFaerxZbYi/9
> =PhO4
> -----END PGP SIGNATURE-----
>
>