ffc team mailing list archive

[Matthew Knepley <knepley@xxxxxxxxxxx>]

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
>
>  --
>> Anders
>>
>
>
>


-- 
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