ufl team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

On Mon, Feb 23, 2009 at 12:37 PM, Kristian Oelgaard
<k.b.oelgaard@xxxxxxxxxx> wrote:
> Quoting Martin Sandve Alnæs <martinal@xxxxxxxxx>:
>
>> On Mon, Feb 23, 2009 at 11:44 AM, Kristian Oelgaard
>> <k.b.oelgaard@xxxxxxxxxx> wrote:
>> > Quoting Martin Sandve Alnæs <martinal@xxxxxxxxx>:
>> >
>> >> On Mon, Feb 23, 2009 at 11:23 AM, Kristian Oelgaard
>> >> <k.b.oelgaard@xxxxxxxxxx> wrote:
>> >> > Quoting Kristian Oelgaard <k.b.oelgaard@xxxxxxxxxx>:
>> >> >
>> >> >> Quoting Anders Logg <logg@xxxxxxxxx>:
>> >> >>
>> >> >> > I thought about it some more and I think I might be able to generate
>> >> >> > the indices on the fly as part of the monomial extraction so it
>> might
>> >> >> > not be necessary.
>> >> >> >
>> >> >> > So if it's not needed for quadrature it can be part of the monomial
>> >> >> > extraction. Otherwise, it seems pretty simple to make a transformer
>> >> >> > for index renumbering.
>> >> >>
>> >> >> I don't think index renumbering is needed for quadrature. A thing that
>> is
>> >> >> needed, however, is the component number of functions/basisfunctions
>> but
>> >> is
>> >> >> this
>> >> >> alway represented by index?
>> >> >
>> >> > Sorry, 'index' should be Indexed in the above.
>> >> >
>> >> > Kristian
>> >>
>> >> This question is too inaccurate for me to know what to say... But I'll
>> try.
>> >>
>> >> A (basis) function never _has_ an index, but expressions
>> >> may refer to a component of a function using Indexed.
>> >> However, you can also have e.g. sums of Functions
>> >> on vector elements, and Indexed outside that.
>> >
>> > Does this means that for
>> >
>> > a = V[0].dx(1)*dx
>> >
>> > one will have to return something like [V[0].dx(1), V[1].dx(1)] from
>> > BasisFunction and then let Indexed pick the correct value? This looks very
>> > inefficient and it makes it more complicated to know which variable names
>> are
>> > going to be used in the code.
>>
>> I'm not sure, but if I understand you right, you're talking about using
>> the transformer framework. As I've suggested before, state can be
>> kept on a stack, updated by Indexed and SpatialDerivative, and
>> then basis_function can simply return the current component (0)
>> and derivative (1).
>
> Yes, and I get all that. I just wanted to be sure that Indexed always referred
> to components of basisfunctions. But I see now that Indexed is also used for the
> components of ComponentTensor but in this case a second mapping of index values
> is needed.

I think you've got it right, but just to be sure: It's a bit more
general than this.

Indexed represents components of <any tensor-valued expression>,
which can also be for example a Sum of other tensor-valued expressions,
a ComponentTensor, or a ListTensor.

ComponentTensor represents a tensor-valued expression
with components given by a scalar expression with free indices
that are "bound" to tensor axes.

In a sense ComponentTensor and Indexed are opposite operations,
Indexed mapping from tensor valued to scalar valued with free indices,
and ComponentTensor mapping from scalar valued with free indices to
tensor valued.

I plan to document this in more detail with mathematical notation...


> E.g.,
>
> a = inner(grad(V), grad(U))*dx
>
> IndexSum
> (
>  IndexSum
>  (
>    Product
>    (
>      Indexed
>      (
>        ComponentTensor
>        (
>          Indexed
>          (
>            SpatialDerivative
>            (
>              BasisFunction(VectorElement('Lagrange',1, 2), -2)
>              MultiIndex((Index(16),))
>            )
>            MultiIndex((Index(17),))
>          )
>          MultiIndex((Index(16), Index(17)))
>        )
>        MultiIndex((Index(18), Index(19)))
>      )
> [snip]
>
> Here the first Indexed will set the values of index18 and index19, which
> ComponentTensor should use to map the values of index16 and index17 such that
> BasisFunction can generate the correct component V[index17].dx(index16)
>
> correct?

Seems right.

Having Indexed(ComponentTensor(expr, ii), jj) might seem like
additional garbage in the expression tree, since this is basically
represents a relabeling of the free indices ii in expr to jj, but this is
a result of keeping subexpressions unmodified as long as possible.

>> But as I've said before, I intend to use linearized computational
>> graphs as an intermediate step for quadrature code generation.
>> I'm soon getting to updating the graph tools since differentiation
>> seems to work ok now. (I plan to get back to improving differentiation
>> later with better algorithms (reverse mode AD), but want to get
>> something up and running first!)
>
> OK, that's understandable.
>
> Kristian
>
>> > BTW index renumbering breaks for
>> >
>> > V[0]*V[1]*dx
>>
>> Fixed. (not tested)
>>
>> Martin
>>
>
>
> _______________________________________________
> UFL-dev mailing list
> UFL-dev@xxxxxxxxxx
> http://fenics.org/mailman/listinfo/ufl-dev
>