← Back to team overview

ffc team mailing list archive

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