ffc team mailing list archive

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

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.

--
Marie




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