dolfin team mailing list archive

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

On 8 June 2011 13:46, Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx> wrote:
> On 8 June 2011 13:31, Martin Sandve Alnæs <martinal@xxxxxxxxx> wrote:
>> On 8 June 2011 13:11, Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx> wrote:
>>> On 8 June 2011 12:11, Martin Sandve Alnæs <martinal@xxxxxxxxx> wrote:
>>>> Done and checked in. If someone updates FFC to support this, we can
>>>> hopefully close this bug.
>>>
>>> I'm not sure this is enough to handle the bug. If you look at the
>>> output of printing M in the example code I posted you'll see that the
>>> list tensor contains component '7'. This is what you'll get from
>>> calling self.component(), but the
>>> TT.symmetry() only contains:
>>> {(2,): (1,), (6,): (5,)}
>>>
>>> Is there some function we need to call first to map the component '7'
>>> --> '6', before looking at symmetries to map '6' --> '5'?
>>> Doing so will get us into trouble with mapping '3' --> '2' since
>>> symmetry will map that to '1'.
>>> The TT element has 2 x 3 sub elements due to symmetry.
>>
>> The 7 is an index into the value index space of the coefficient and is
>> correct. It has nothing (directly) to do with subelement indexing. I
>> think you're assuming a closer relation between them than there is?
>> Let me try to clear it up...
>>
>> The value index space is contiguous from the point of view of UFL
>> expressions, but has holes when symmetries are considered. The
>> noncontiguous value index space will then need to be mapped to a
>> contiguous subelement space by associating each value index that is
>> not in the symmetry mapping with a subelement index.
>>
>> 1) We have a component/value index
>> 2) We map that value index to another value index using a symmetry
>> mapping (e.g. 6->5 and 7->7 in your example)
>> 3) We map from the noncontiguous value index space to the contiguous
>> subelement index space
>>
>> Clear as mud? :)
>
> Yes, but since we only deal with the (sub)elements that are actually
> present in FFC, it's really inconvenient that we can't get a mapping
> from the component to the subelement.
> I somehow suspected the FiniteElement.extract_component() to do this,
> but it turns out not to be the case.
>
>> UFL handles (2) for you only when you apply expand_indices.
>>
>> FFC will have to handle (3) when generating code, it doesn't touch
>> anything UFL needs to know about. I'll see if I can whip up a quick
>> utility function for it though.
>
> That would really be nice.

Done :) The latest patch contains code and test showing usage.

But maybe it should be integrated into extract_component, I'll take a
look at that now that I'm into this.

Martin