ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Sep 16, 2009 at 06:02:51PM +0200, Garth N. Wells wrote:
>
>
> 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 want to have a basis for say P2 on a patch of elements surrounding an
element K and one option would be to use the extension of the P2
basis on K.

> I added a Blueprint to UFC/FFC to evaluate basis
> functions at reference coordinates. Would that help with reuse?

You mean evaluating at a point not on the physical element but on the
reference element? Like evaluate_basis but without the cell argument?
No, that would not help as those points would also need to avoid the
special line where the values are undefined.

--
Anders

Attachment: signature.asc
Description: Digital signature