On 8 June 2011 14:08, Martin Sandve Alnæs <[email protected]> wrote: > On 8 June 2011 13:55, Martin Sandve Alnæs <[email protected]> wrote: >> On 8 June 2011 13:46, Kristian Ølgaard <[email protected]> wrote: >>> On 8 June 2011 13:31, Martin Sandve Alnæs <[email protected]> wrote: >>>> On 8 June 2011 13:11, Kristian Ølgaard <[email protected]> wrote: >>>>> On 8 June 2011 12:11, Martin Sandve Alnæs <[email protected]> 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? > Note that when I pushed now I pushed the float formatting fix as well, > so some FFC references will probably need regeneration again :) Yes, I noticed that :) Kristian > Martin > _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
