ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Sep 16, 2009 at 08:02:45PM +0200, Anders Logg wrote:
> On Wed, Sep 16, 2009 at 07:58:26PM +0200, Garth N. Wells wrote:
> >
> >
> > Anders Logg wrote:
> > > On Wed, Sep 16, 2009 at 12:57:52PM -0400, Shawn Walker wrote:
> > >> On Wed, 16 Sep 2009, Anders Logg wrote:
> > >>
> > >>> On Wed, Sep 16, 2009 at 06:12:48PM +0200, Garth N. Wells wrote:
> > >>>>
> > >>>> Anders Logg wrote:
> > >>>>> 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 don't understand how evaluating the P2 basis for K outside of K would
> > >>>> work. For example, it could be greater than one.
> > >>> Yes, it can be greater than one but that's not a problem. The point is
> > >>> that the extension of the basis for P2 on K spans P2 on R^2.
> > >>>
> > >>> Just think of the nodal basis for P1 on the reference triangle:
> > >>>
> > >>> v1 = 1 - x - y
> > >>> v2 = x
> > >>> v3 = y
> > >>>
> > >>> These three functions span P1 on R^2 or on any other triangle than K.
> > >>> But they are only a *nodal* basis on K.
> > >>>
> > >> This discussion doesn't concern me, but here is my opinion.
> > >>
> > >> I think that it should be possible for a user to evaluate the basis
> > >> functions outside the reference element.  This could potentially be
> > >> useful for a generalized FEM.  Or perhaps a user wants to `hack'
> > >> DOLFIN to do some peculiar thing, for whatever reason.  This should
> > >> be allowed!
> > >>
> > >> I think in general, one should not limit functionality unless there
> > >> is a strong reason otherwise.  You could still output a warning
> > >> message.
> > >
> > > A share this view.
> > >
> >
> > What is the isoparametric map outside of the cell?
>
> The map is a polynomial and so are the basis functions so they
> naturally extend to any point in the universe.

I've added a note to the UFC manual about the value being undefined at
a point outside the cell. It's the easiest solution...

--
Anders

Attachment: signature.asc
Description: Digital signature