ffc team mailing list archive

["Garth N. Wells" <g.n.wells@xxxxxxxxxxxxxxx>]

Hi Johan,

For me, tensor notation would be really useful. 

Related to the issue of taking slices and indexing, I had some exchanges with
Anders a while  ago about the possibility of being able to specify the range of
the summation when using the index summation convention. This would be a big
help when examining coupled problems. At the moment I'm not able (or don't know
how) to use the index notation for these problems, so I'm writing out the
bilinear form for explicitly. As an example, I'm  looking at a coupled
elasticity-diffusion equation at the moment. In 2D (3 dof per node), part of th
bilinear form looks like

a = ( lmbda * (u[0].dx(0) + u[1].dx(1))*(v[0].dx(0) + v[1].dx(1))  + \
       mu * ( \
        (u[0].dx(0)+u[0].dx(0))*(v[0].dx(0)) + \
        (u[0].dx(1)+u[1].dx(0))*(v[0].dx(1)) + \
        (u[1].dx(0)+u[0].dx(1))*(v[1].dx(0)) + \
        (u[1].dx(1)+u[1].dx(1))*(v[1].dx(1)) ) )* dx + \
     -Beta*( u[2]*v[0].dx(0) + u[2]*v[1].dx(1) )* dx

For 3D, I need to add a bunch of terms. What I would like to able to do is use
something like:

a = ( lmbda * u[i:0,n].dx(i:0,n) * v[j:0,n].dx(j:0,n) + \
  mu * ( u[i:0,n].dx(j:0,n) + u[j:0,n].dx(i:0,n) ) * v[i:0,n].dx(j:0,n) )* dx + \
 -Beta * u[n+1]*v[i:0,n].dx(i:0,n) * dx
 
where n is the range of the summation. Setting n = 1 would then be for 2D, and n
 = 2 for 3D. It might then be an idea to make the spatial dimension available 
within ffc.

Garth



Quoting Johan Jansson <johanjan@xxxxxxxxxxxxxxxx>:

> Hi,
> 
> I'm at a point where tensor (matrix) notation would be very useful in
> FFC. Has anyone given any thought to what needs to be done? I can work
> on implementing it, I need some exercise in Python and to learn more
> about FFC. It would be good to discuss which features are needed
> here on this list.
> 
> Right now I'm thinking that all that should be necessary is a matrix
> indexing operator: [a, b] (perhaps general tensor indexing can wait,
> but presumably it would extend naturally: [a, b, c] etc.), which would
> be very similar to the vector indexing operator: [a]. There also needs
> to be a way of specifying the dimensions for the components of the
> tensor. Perhaps slicing would also be useful, i.e. the [:, b] and [a,
> :] operators.
> 
> The actual tensor operators (matrix multiplication etc.) could then be
> user-defined, at least at this stage.
> 
> What do you think? The rest of FFC and FIAT shouldn't have to know
> about tensors, an M x N tensor-valued element should just look like an
> M * N vector-valued element to them. I haven't looked much at the code
> yet, but hopefully it should be straightforward to do it this way.
> 
>   Johan
> 
> _______________________________________________
> FFC-dev mailing list
> FFC-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/ffc-dev
>