ffc team mailing list archive

[Matthew Knepley <knepley@xxxxxxxxxxx>]

On Wed, Sep 16, 2009 at 10:58 AM, Anders Logg <logg@xxxxxxxxx> wrote:

> You mean the transitive closure of the support? ;-)
>

If you express it as a sieve, Yes.

   Matt


> --
> Anders
>
>
> On Wed, Sep 16, 2009 at 10:53:41AM -0500, Matthew Knepley wrote:
> > I do agree with Anders, that if we associate a single basis function to
> each
> > vertex (P1),
> > then that function must have support on the "star" of the vertex, or
> every cell
> > which
> > includes that vertex on its boundary.
> >
> >   Matt
> >
> > On Wed, Sep 16, 2009 at 10:50 AM, Garth N. Wells <gnw20@xxxxxxxxx>
> 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> > _______________________________________________
> > FFC-dev mailing list
> > FFC-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/ffc-dev
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkqxCxMACgkQTuwUCDsYZdEm6ACeIwB2B5lEezV67AtPczQtdCnd
> btgAn0ylMIUDs49LTyM1yv+W72+ISeXM
> =QSEr
> -----END PGP SIGNATURE-----
>
>


-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener