ffc team mailing list archive

[Kristian Oelgaard <k.b.oelgaard@xxxxxxxxxx>]

Quoting Marie Rognes <meg@xxxxxxxxxxx>:

> Kristian Oelgaard wrote:
> > Quoting Marie Rognes <meg@xxxxxxxxxxx>:
> >
> >   
> >> Kristian Oelgaard wrote:
> >>     
> >>> Hi,
> >>>
> >>> I think there is a bug in simplify.py. Consider the following simple
> forms
> >>>       
> >> and
> >>     
> >>> their output:
> >>>
> >>>   
> >>>       
> >> What? A bug in simplify? Impossible ;)
> >>     
> >
> > I know, I almost couldn't believe it myself :)
> >  
> >   
> 
> 
> However, this time it is actually not simplify that is the main culprit:
> 
>     After index reassignment:
>      
>           0.5 | vi0[0]*vi1[0]*dX(0) + 0.5 | vi0[0]*vi1[0]*dX(0) + 0.5 |
>     vi0[1]*vi1[1]*dX(0) + 0.5 | vi0[1]*vi1[2]*dX(0) + 0.5 |
>     vi0[2]*vi1[2]*dX(0) + 0.5 | vi0[2]*vi1[1]*dX(0) + 0.5 |
>     vi0[3]*vi1[3]*dX(0) + 0.5 | vi0[3]*vi1[3]*dX(0)
>      
>       After simplification:
>      
>           0.5 | vi0[b0]*vi1[b0]*dX(0) + 0.5 | vi0[b0]*vi1[b0]*dX(0) +
>     0.5 | vi0[1]*vi1[2]*dX(0) + 0.5 | vi0[2]*vi1[1]*dX(0)
> 
> 
> where the index b0 has range [0, 1, 2, 3] in the first term and [0, 3] 
> in the second term. This makes sense.

Maybe, on a side note: the fact that 'b0' can have a different range in each
monomial makes it pretty difficult to debug/understand what is going on by just
looking at the pretty print version of the form. The index should be different
in my opinion.

 However, in the factorization step 
> for the tensor representation, these two terms are considered equal 
> since their signatures are the same and thus a faulty tensor 
> representation is generated.
> 
> This is an inherent complication with regard to letting indices be 
> interpreted as equivalent for the sake of index contractions vs 
> different for factorizations.
> 
> I am not sure of what the best way of approaching this would be. I don't 
> feel like messing too much with the factorization step in the 
> tensorrepresentation...

No, me neither.

> However, I was planning on refactoring the simplify code at some point. 
> I think a key part of this would be to generalize the signatures so that 
> we could use these instead of elaborate checks that are there now... 
> Will not be before spring break though.

Sounds like a good idea, maybe we should switch off simplify until then?

Kristian
 
> --
> Marie
> 
> 
> 
> 
> -- 
> Marie E. Rognes
> Ph.D Fellow, 
> Centre of Mathematics for Applications, 
> University of Oslo
> http://folk.uio.no/meg
>