| Thread Previous • Date Previous • Date Next • Thread Next |
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. GarthYes, 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? Garth
In this particular case, the strong reason for disallowing it might be that it's difficult to get around because of the particular way FIAT has implemented the basis functions (by a singular map from a square). If that's the case, then we can work around it in our code (by expanding in the Bernstein basis and then restricting back to the cell). Rob? -- Anders ------------------------------------------------------------------------ _______________________________________________ FFC-dev mailing list FFC-dev@xxxxxxxxxx http://www.fenics.org/mailman/listinfo/ffc-dev
| Thread Previous • Date Previous • Date Next • Thread Next |
