dolfin team mailing list archive

[Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx>]

On 8 June 2011 14:29, Martin Sandve Alnæs <martinal@xxxxxxxxx> wrote:
> On 8 June 2011 14:18, Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx> wrote:
>> On 8 June 2011 14:08, Martin Sandve Alnæs <martinal@xxxxxxxxx> wrote:
>>> On 8 June 2011 13:55, Martin Sandve Alnæs <martinal@xxxxxxxxx> wrote:
>>>> 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.
>>>
>>> I applied the symmetry mapping inside extract_component for tensor elements,
>>> that way you shouldn't have to do the symmetry mapping in addition to
>>> calling extract_component. The numbering utility I checked in could still
>>> come in handy though, so I'll let it stay.
>>
>> OK, will you add the numbering utility function in extract_component such that
>> calling this function will return the contiguous component and element?
>
> Hm... I'd rather keep extract_component as it is, returning
> the value component tuple and not the element numbering.
>
> Just do
> v, s = build_component_numbering(e.value_shape(), e.symmetry())
> sc, sube = e.extract_component(c)
> sub_element_index = v[sc]

OK, I'll see if I can figure out where to add this.

Kristian

> Martin
>