ffc team mailing list archive

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

Quoting Anders Logg <logg@xxxxxxxxx>:

> On Wed, Mar 19, 2008 at 12:08:16PM +0100, Kristian Oelgaard wrote:
> > Quoting Anders Logg <logg@xxxxxxxxx>:
> > 
> > > On Tue, Mar 18, 2008 at 02:37:49PM -0400, Marie Rognes wrote:
> > > > Kristian Oelgaard wrote:
> > > > > Quoting Marie Rognes <meg@xxxxxxxxxxx>:
> > > > >
> > > > >   
> > > > >>
> > > > >> 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.
> > > > >
> > > > >   
> > > > 
> > > > Agree. Maybe we could have two versions of printing indices, one with 
> > > > the ranges (if set) ala
> > > > 
> > > >     b0 (0, 1, 2, 3)
> > > > 
> > > > for debug purposes and a denser one for non-debug purposes?
> > > > 
> > > > Actually, that would be a starting point for an accurate factorization
> 
> > > > check too.
> > > 
> > > See if it works now. It was a simple fix (assuming it works) to
> > > include the index range in the computation of signatures (see
> > > signature.py).
> > 
> > Yes, it works, but the output could be optimised:
> > 
> >     // Compute geometry tensors
> >     const double G0_ = det;
> >     const double G1_ = det;
> >     const double G2_ = det;
> >     const double G3_ = det;
> >     
> >     // Compute element tensor
> >     A[0] = 0.25*G0_ + 0.25*G1_;
> >     A[1] = 0;
> >     A[2] = 0;
> >     A[3] = 0;
> >     A[4] = 0;
> >     A[5] = 0.25*G0_;
> >     A[6] = 0.25*G2_;
> >     A[7] = 0;
> >     A[8] = 0;
> >     A[9] = 0.25*G3_;
> >     A[10] = 0.25*G0_;
> >     A[11] = 0;
> >     A[12] = 0;
> >     A[13] = 0;
> >     A[14] = 0;
> >     A[15] = 0.25*G0_ + 0.25*G1_;
> > 
> > So something in factorization should change.
> 
> Yes, but I don't want to mess with it unless I really have to.
> A lot of work needs to be done when we move to UFL anyway, so
> I'd rather wait.

OK.
 
> > And it would be nice to include some information about the range of the
> indices
> > in the form signature:
> > 
> >   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)
> > 
> > b0 in first product 0-3, in second 0-1.
> 
> ok, see if you like it now.

The output is definitely much more informative without being cluttered.

Kristian


> -- 
> Anders
> _______________________________________________
> FFC-dev mailing list
> FFC-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/ffc-dev
>