ufl team mailing list archive

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

2008/5/6 Anders Logg <logg@xxxxxxxxx>:
> On Mon, May 05, 2008 at 10:45:25PM +0200, Martin Sandve Alnæs wrote:
>> 2008/5/5 Anders Logg <logg@xxxxxxxxx>:
>> > On Mon, May 05, 2008 at 03:34:41PM +0200, Martin Sandve Alnæs wrote:
>> >> 2008/5/5 Anders Logg <logg@xxxxxxxxx>:
>> >> > On Mon, May 05, 2008 at 03:05:24PM +0200, Martin Sandve Alnæs wrote:
>> >> >> 2008/5/5 Anders Logg <logg@xxxxxxxxx>:
>> >> >> > On Mon, May 05, 2008 at 02:02:39PM +0200, Martin Sandve Alnæs wrote:
>> >> >> >> 2008/5/2 UFL <ufl@xxxxxxxxxx>:
>> >> >> >> > One or more new changesets pushed to the primary ufl repository.
>> >> >> >> > A short summary of the last three changesets is included below.
>> >> >> >> >
>> >> >> >> > changeset:   99:ab1f19b9eb5545605d2651bf95508956aa27ad0b
>> >> >> >> > tag:         tip
>> >> >> >> > user:        Anders Logg <logg@xxxxxxxxx>
>> >> >> >> > date:        Fri May 02 23:16:10 2008 +0200
>> >> >> >> > files:       ufl/basisfunctions.py ufl/finiteelement.py
>> >> >> >> > description:
>> >> >> >> > Implement recursive initialization of tensor elements.
>> >> >> >> > Unit tests pass, but see what you think of it.
>> >> >> >>
>> >> >> >> I don't agree with this, we want to have e.g. symmetric
>> >> >> >> second order tensor elements, which do not fit into this.
>> >> >> >
>> >> >> > In what way do they not fit?
>> >> >> >
>> >> >> > The flag is_symmetric() is still there.
>> >> >> >
>> >> >>
>> >> >> For a symmetric tensor in 3D, there should be only 6 subelements,
>> >> >> and this recursive initialization will create 9.
>> >> >
>> >> > Does that matter? Creating an UFL element is very lightweight so it
>> >> > shouldn't matter that we have a few extra elements. The important
>> >> > thing is for algorithms (and form compilers) to look at is_symmetric
>> >> > and use that to optimize.
>> >>
>> >> I'm not sure, but I feel that this should closely match the resulting
>> >> UFC element hierarchy that comes out at the other side.
>> >
>> > Then what should the hierarchy look like for a symmetric 2x2 tensor
>> > element?
>> >
>> > We could do
>> >
>> >  [[e, e], [None, e]]
>> >
>> > if we like.
>> >
>>
>> Basically, yes, but I'm not sure what you mean with the []'s?
>
> I mean that we have a mixed element which has two sub elements,
> each consisting of two (scalar) elements.
>
>> But if I interpret this correctly as Python list, I don't see the
>> advantage of storing this kind of list with None values.
>
> No, it's nested classes. The list notation was just shorthand (and
> confusing).
>
>> I'd rather store a single list of subelements, which can
>> be handled like in any MixedElement most of the time,
>> and store the subelement indices like:
>
> How would you store a simple Taylor-Hood element that way?

Irrelevant. A Taylor-Hood element is not a TensorElement.

> I think the natural thing would be to have a MixedElement which has
> two sub elements. The first one of these (for u) will be a
> VectorElement (which is a special case of a MixedElement) and that
> element will have a list of two scalar sub elements. The second one
> (for p) will be a FiniteElement (a scalar).
>
> Similarly, one can take a vector-valued BDM-element for u and a scalar
> element for p and combine them into a MixedElement. In that case, each
> of the two sub elements will be a FiniteElement, but one will be
> vector-valued and one scalar.

I completely agree with that for a general MixedElement.

I just don't agree that a TensorElement should be
represented as a nested hierarchy of MixedElements,
since this will not be simple as intended for symmetric elements.

Actually, I'm still not quite comfortable with VectorElement meaning
"vector of element" instead of "vector valued element", and I don't
think that matches what people would expect. Our different opinions
here may be related to this.

--
Martin