ffc team mailing list archive
-
ffc team
-
Mailing list archive
-
Message #00248
Re: Tensors
-
To:
Discussion of FFC development <ffc-dev@xxxxxxxxxx>
-
From:
Johan Jansson <johanjan@xxxxxxxxxxxxxxxx>
-
Date:
Wed, 7 Sep 2005 14:50:09 +0200
-
In-reply-to:
<20050906215358.GD28419@galerkin>
-
User-agent:
Mutt/1.5.6+20040523i
On Tue, Sep 06, 2005 at 04:53:58PM -0500, Anders Logg wrote:
> Rob and I discussed this earlier today and came to the conclusion that
> new operators should be defined using Python built-in lists. This seems
> to be both the most flexible approach and the most transparent.
>
> With new operators defined in terms of Python lists, it is the
> responsibility of FFC to process the given form and find the proper
> tensor representation. In the case of Poisson's equation as discussed
> in a previous post, this means that FFC will have to look at the two
> terms and factor out the common reference tensor. I have started to
> work out the details (computing signatures to identify common
> tensors).
>
> A clarification might be necessary. The syntax remains the same as
> before, in particular the index notation with implicit summation.
> The only thing that will change is that new operators (such as grad,
> div, rot) will be added and they will be defined in terms of Python
> lists. This already works (as Johan has noted), but is non-optimal.
>
> /Anders
>
Ok, I didn't realize that it would break up the products. Of course we
shouldn't accept sub-optimal code generation. We don't have any real
time constraints at compile time, so let's make sure the operators
lead to the same code as writing them out manually explicitly would
do.
Great that you seem to have found a solution.
Also nice that Numeric.array supports tensors, I must have missed this
detail somehow in the documentation.
Johan
Follow ups
References