ffc team mailing list archive
-
ffc team
-
Mailing list archive
-
Message #00146
Re: Suggestions for changes [...]
>A Function in FFC is always a member of a finite element
space, and
>each Function declared in FFC is always connected to a
finite element
>Function in DOLFIN.
>
>The FFC Function is the restriction of a DOLFIN Function to
a local
>element.
>
ok. I was unaware of this assumption. Sundance and PETSc
both allow functions that are not in the finite element
space. But FFC only allows things that are strictly
multilinear, so it requires the mapping into the space.
>Of course, one could change the syntax from
>
> f = Function(element)
> L = v*f*dx
>
>to
>
> f = Function()
> pi = Projection(element)
> L = v*pi(f)*dx
>
>but that would only make things more complicated to write
(but perhaps
>it would be more clear what happens).
>
It is more to type, but more clear. It opens two nice
avenues:
i.) Adding quadrature-based modules that will *not* do the
projection explicitly
ii.) Allowing multiple kinds of projections (L2, H1, nodal
interpolation)
>What I meant was that in some cases, we want to project a
Function
>locally from one finite element space to another. Take as
an example
>the stabilization term of Navier-Stokes with linear
elements on tets:
>
Good point, I hadn't thought about this. Another example
would be any kind of multigrid or multilevel method.
>
>And D(i) would look very much like a gradient:
>
> D(i)(u)*D(i)(v)
>
I'n not sure what you mean -- this is the dot product of
gradients of scalar functions.
>I need to think about this. At some point, we should add
grad,
>div, rot anyway.
>
I would add these in terms of what you've already done by
simple definitions, e.g.
grad(u) --> u.dx(i)
But maybe it's two lines -- one if u is a scalar, and
another if it's a vector
grad(u) --> u[i].dx(j) if u is a vector
grad(u) --> u.dx[i] if u is a scalar.
Rot/curl is a little trickier, as you need to know whether
you're in 2d or 3d.
Rob
Follow ups