ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Mar 17, 2009 at 09:29:06PM +0100, Martin Sandve Alnæs wrote:
> On Tue, Mar 17, 2009 at 9:14 PM, Kristian Oelgaard
> <k.b.oelgaard@xxxxxxxxxx> wrote:
> > Quoting Anders Logg <logg@xxxxxxxxx>:
> >
> >> On Tue, Mar 17, 2009 at 09:05:22PM +0100, Kristian Oelgaard wrote:
> >> > Quoting Anders Logg <logg@xxxxxxxxx>:
> >> >
> >> > > On Tue, Mar 17, 2009 at 10:39:10AM +0100, Kristian Oelgaard wrote:
> >> > > > Quoting UFL <ufl@xxxxxxxxxx>:
> >> > > >
> >> > > > > One or more new changesets pushed to the primary ufl repository.
> >> > > > > A short summary of the last three changesets is included below.
> >> > > > >
> >> > > > > changeset:   739:ace55a2c179c2335fccb620f1c4db1bc5a0f3153
> >> > > > > tag:         tip
> >> > > > > user:        Anders Logg <logg@xxxxxxxxx>
> >> > > > > date:        Sun Mar 15 19:56:10 2009 +0100
> >> > > > > files:       scripts/form2ufl
> >> > > > > description:
> >> > > > > Improvements to form2ufl script
> >> > > >
> >> > > > There's a bug when translating PoissonDG.form, look at the last *ds
> >> term.
> >> > > >
> >> > > > Kristian
> >> > >
> >> > > Fixed. I've regenerated all .ufl files now except for
> >> TensorWeightedPoisson
> >> > > which can't be handled by the script.
> >> >
> >> > OK.
> >> >
> >> > > It would be good if we could keep the .ufl files untouched from now on
> >> > > until at least the next release (so they are as close as possible to
> >> > > the old .form files and generated using form2ufl). If you want, you
> >> > > can add some more examples that set options like "quadrature_order".
> >> >
> >> > The reason that I've changed the *.ufl forms (added the quadrature_order)
> >> is
> >> > that otherwise the results does not agree, which I think is just as
> >> important
> >> > if you talk about a foo.form and foo.ufl form being equal.
> >>
> >> But isn't that a good thing? It indicates that we have not yet figured
> >> out the correct quadrature order to use automatically.
> >
> > That is one way of looking at it, but it makes it difficult to see if the rest
> > of the generated code is correct. It's no big deal though, I just add the order
> > for the forms that I test without checking the changes in.
> >
> > Kristian
> 
> To really solve this issue, I need to understand what sufficient
> quadrature order _is_.
> 
> 1) Can the discrete operator assembled from a bilinear form be
> approximated using quadrature order v.degree() + u.degree()?
> This seems to be common, but I don't understand why it is ok.
> 
> 2) Obviously, using v.degree() is not sufficient for linear forms,
> it even fails for f*v*dx. So using v.degree() + f.degree() in this
> case seems like the only right thing to do. This can be generalized
> to sum the degrees of form arguments in each product.
> 
> 3) But for forms like "exp(f**2)*v*dx", there's no way we can
> decide a sufficient quadrature order, so what do we fall
> back to? Should the rhs use the same order as the lhs?
> Or will simply 2*v.degree() be fine? The user should probably
> be careful in a case like this anyway.
> 
> Martin

I think the form compilers should try to integrate the given forms
exactly and otherwise default to some sensible value.

So I'd suggest

  v.degree() + f.degree() - {num derivatives on v and f}

For cases like exp(f**2)*v*dx, I think it's reasonable to default to
2*v.degree().

We could also have an option for using quadrature order v.degree()
which I think should retain the correct order of convergence in most
cases, but that is more of a form compiler option than a language
option.

-- 
Anders

Attachment: signature.asc
Description: Digital signature