ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Apr 20, 2009 at 01:21:07PM +0200, Martin Sandve Alnæs wrote:
> 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.

We do something similar, but it gets a bit ugly since we want to
modify the integral metadata (set correct representation and
quadrature order if not already set by a user). So then we first call
form_data() only to be able to estimate the quadrature order. Then we
need to call form_data() again on the modified form after having
modified the integral metadata.

  # Validate form
  validate_form(form)

  # Set metadata for all integrals (requires form_data().form)
  new_form = Form([])
  for integral in form.form_data().form.integrals():
      new_form += Form([_set_integral_metadata(integral, options)])
  form = new_form

  # Extract form data
  form_data = form.form_data()
  form = form_data.form

> 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.

Is it possible to either set a flag that can be checked by algorithms
requiring expanded expressions, or that these algorithms call
expand_compounds?

It's confusing if something is required by an algorithm and it doesn't
report an error if that requirement is not met.

-- 
Anders


> 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().
> >
> >
> >
> >> 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-----
> >
> >
> _______________________________________________
> FFC-dev mailing list
> FFC-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/ffc-dev

Attachment: signature.asc
Description: Digital signature