Subject: [Ufl] [[email-masked]: [Bug 785143] Re: Element mapping is not provided to ufl.Form.compute_form_data()]

From: Anders Logg <[email-masked]>
Date: Mon, 30 May 2011 21:39:16 +0200

How is this mapping created? Which degree is chosen for the elements?
If it's the same as currently used in FFC, we can drop that and rely
on UFL.

Here's what's used in FFC:

  # Extract common degree
  common_degree = max([e.degree() for e in elements])
  if common_degree is None:
      common_degree = default_quadrature_degree

  # Degree must be at least 1 (to work with Lagrange elements)
  common_degree = max(1, common_degree)

--
Anders

Subject: [Bug 785143] Re: Element mapping is not provided to ufl.Form.compute_form_data()
From: Martin Sandve Alnæs <[email-masked]>
To: [email-masked]
Date: Mon, 30 May 2011 11:35:32 -0000

In an upcoming commit, the element mapping is now constructed
automatically by ufl in preprocess in the case of invalid cells. Thus
ffc (and sfc) do not need to pass a mapping unless you want to override
things like degree and family.

Note that there may still be issues with the above code snippet, but
I'll close this bug and report eventual other bugs separately if
necessary.

** Changed in: ffc
       Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of FFC Core
Team, which is subscribed to FFC.
https://bugs.launchpad.net/bugs/785143

Title:
  Element mapping is not provided to ufl.Form.compute_form_data()

Status in FEniCS Form Compiler:
  Invalid

Bug description:
  FFC does not provide an element mapping to
  ufl.Form.compute_form_data(). This is needed when used from PyDOLFIN,
  to make forms well defined when coefficients are missing cells.

  I have some failing code, will need to simplify it before I post it
  here.

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Mon, 30 May 2011 22:10:00 +0200

> If it's the same as currently used in FFC, we can drop that and rely

It only adds missing cells. I think which degrees to choose is not
something UFL should guess at, that is completely in the form
compiler realm. In particular I think FFC should choose quadrature
elements for quadrature representation and CG elements for tensor
representation, which are concepts we do not want to introduce in UFL.

But the original bug report here was that FFC does not pass any
element mapping at all, so if you need to map degrees you should
look into that.

>  common_degree = max(1, common_degree)

So if f and v are CG2 functions, then f*v*dx which is an up to
4th degree polynomial, is integrated with 2nd degree accuracy?

Martin

> --
> Anders
>
>
> ---------- Forwarded message ----------
> From: "Martin Sandve Alnæs" <[email-masked]>
> To: [email-masked]
> _______________________________________________
> Mailing list: https://launchpad.net/~ufl
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~ufl
> More help   : https://help.launchpad.net/ListHelp
>
>

---

From: Anders Logg <[email-masked]>
Date: Tue, 31 May 2011 21:19:13 +0200

> element mapping at all, so if you need to map degrees you should

So then what's the point of this function if it can't be used by a
form compiler? The form compiler will have to check for missing degree
and supply the mapping which will override any mapping that UFL
computes.

> 4th degree polynomial, is integrated with 2nd degree accuracy?

No, it's integrated with with a quadrature rule exact for degree 4
polynomials. But for the form c*f*v*dx where c is an undefined
expression, c would be interpolated into P2, and then a quadrature
rule exact for polynomials of degree 6 is used.

--
Anders