ufl team mailing list archive

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

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.
>
> --
> Anders

Basically, yes, but I'm not sure what you mean with the []'s?
But if I interpret this correctly as Python list, I don't see the
advantage of storing this kind of list with None values.

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:

2D:
[
 [0, 1],
 [1, 2]
]

3D:
[
 [0, 1, 2],
 [1, 3, 4],
 [2, 4, 5]
]

--
Martin