← Back to team overview

ffc team mailing list archive

Re: "Bug" in evaluate_basis

 



Anders Logg wrote:
On Wed, Sep 16, 2009 at 05:50:05PM +0200, Garth N. Wells wrote:

Anders Logg wrote:
On Wed, Sep 16, 2009 at 05:37:13PM +0200, Garth N. Wells wrote:
Anders Logg wrote:
On Wed, Sep 16, 2009 at 04:34:29PM +0200, Garth N. Wells wrote:
Anders Logg wrote:
@Garth: Yes, they are defined everywhere. For example, v1 = 1 - x - y,
v2 = x and v3 = y are a nodal basis for the reference triangle, but
they are also a basis for P1 on R^2. You can evaluate 1 - x - y for
any values of x and y.

I don't agree at all. The function 1-x-y can be evaluated anywhere, but
the basis functions are defined only on the cell. If the basis functions
  were defined everywhere, the method would loose all sparsity.
The sparsity is not a result of evaluate_basis returning 0 outside the
cells, it's a result of the assembly process and the local-to-global
mapping.

Either way, that's not how evaluate_basis is implemented today. It
works perfectly fine to evaluate the natural extensions of the basis
functions, except along one line where the mapping happens to be
singular. This is not in anyway connected to how the basis functions
should be defined, it's just a consequence of the particular way Rob
has implemented the basis functions in FIAT (via a mapping from Jacobi
polynonials on a square).

For example, if you take the first basis function (1 - x - y) on the
reference triangle and evaluate it at (2, 2), you get -2 as
expected although that point is outside the triangle. But if you try
to evaluate it at (1, 1), you get 0 because of a bug/feature in
evaluate_basis. If you do (1, 1 + eps), then you get -1 - eps.

The sparsity is a result of the basis being non-zero only locally, so I
would call getting zero outside of the cell from ufc::evaluate_basis(..)
a feature.
That's true only for DG elements. All other bases we know of have
larger support (on a patch of elements).

We can define the basis on a cell to be zero outside of the cell. The
dof map takes care of patching together the functions on neighbouring cell.

Furthermore, evaluate_basis does currently *not* return zero outside
the cell, only for *certain* points outside the cell.

It would be nice if it returned zero outside the cell, but it is a
relatively low-level function so there may be efficiency reasons why
this isn't desirable, in which case it wouldn't both me if the returned
values for points outside the cell are meaningless.

Garth

Yes, that could be an option, or adding to the manual that the values
are undefined outside the cell.

It's just that it would be very useful for us (Marie and I) to reuse
the cell basis functions on cell patches.

Are you wanting to evaluate functions like v2 = x outside of [0, 1]? What do you do with it? I added a Blueprint to UFC/FFC to evaluate basis functions at reference coordinates. Would that help with reuse?

Garth

We need it for the automatic
error estimation (which is close to working btw).

--
Anders




Follow ups

References