ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Oct 21, 2008 at 06:14:00PM +0200, Martin Sandve Alnæs wrote:
> 2008/10/21 Anders Logg <logg@xxxxxxxxx>:
> > On Tue, Oct 21, 2008 at 06:03:27PM +0200, Martin Sandve Alnæs wrote:
> >> 2008/10/21 Anders Logg <logg@xxxxxxxxx>:
> >> > On Tue, Oct 21, 2008 at 05:41:15PM +0200, Martin Sandve Alnæs wrote:
> >> >> 2008/10/21 Anders Logg <logg@xxxxxxxxx>:
> >> >> > On Tue, Oct 21, 2008 at 05:27:55PM +0200, Anders Logg wrote:
> >> >> >> Is there a simple way to evaluate tensor expressions? For example, if
> >> >> >>
> >> >> >>  a = dot(v, u)*dx
> >> >> >>
> >> >> >> is there then a way to convert this to
> >> >> >>
> >> >> >>  v[0]*u[0] + v[1]*u[1] + ...
> >> >> >>
> >> >> >> ?
> >> >> >
> >> >> > I found the following in Dot:
> >> >> >
> >> >> >  def as_basic(self, dim, a, b):
> >> >> >      ii = Index()
> >> >> >      aa = a[ii] if (a.rank() == 1) else a[...,ii]
> >> >> >      bb = b[ii] if (b.rank() == 1) else b[ii,...]
> >> >> >      return aa*bb
> >> >> >
> >> >> > Why are the arguments dim, a and b required? A Dot already knows its
> >> >> > operands.
> >> >> >
> >> >> >> On Tue, Oct 21, 2008 at 05:27:55PM +0200, Anders Logg wrote:
> >> >> >> Is there a simple way to evaluate tensor expressions? For example, if
> >> >> >>
> >> >> >>  a = dot(v, u)*dx
> >> >> >>
> >> >> >> is there then a way to convert this to
> >> >> >>
> >> >> >>  v[0]*u[0] + v[1]*u[1] + ...
> >> >> >>
> >> >> >> ?
> >> >> >
> >> >> > I found the following in Dot:
> >> >> >
> >> >> >  def as_basic(self, dim, a, b):
> >> >> >      ii = Index()
> >> >> >      aa = a[ii] if (a.rank() == 1) else a[...,ii]
> >> >> >      bb = b[ii] if (b.rank() == 1) else b[ii,...]
> >> >> >      return aa*bb
> >> >> >
> >> >> > Why are the arguments dim, a and b required? A Dot already knows its
> >> >> > operands.
> >> >> >
> >> >>
> >> >> Because it is used in an algorithm that first expands its operands,
> >> >> so a and b here are not necessarily its original operands.
> >> >> As you see, dim is not used here, but it's used in some other Compounds.
> >> >>
> >> >> These functions could of course also be placed in the algorithm
> >> >> in question instead of in each Compound object, like with several
> >> >> other algorithms. But I think that's a detail we can discuss later,
> >> >> in context with other similar issues.
> >> >
> >> > Yes, if as_basic does not work like a member function, it seems
> >> > strange to make it a member function. Maybe it could be made static if
> >> > necessary.
> >> >
> >>
> >> I'm fine with moving it into the algorithm, I can do that later.
> >>
> >> Keeping it (static) in the class simplifies adding new Compound
> >> objects, that's the only reason I can think of now. But this is not
> >> really necessary since they would have to be handled in e.g. the
> >> latex compiler and maybe other places for that to make any sense.
> >>
> >> This probably makes no sense to you right now, we should set
> >> up a session where I show how these things fit together.
> >
> > There are a lot of things that don't make sense to me right now... :-)
> >
> > So is there any way right now to handle compound expressions, or do I
> > need to implement it?
> >
> > Say that I have a = dot(v, u)*dx, how can I expand it into simpler
> > operations (including only +, *, and [])?
> >
> 
> As I just mentioned, the function expand_compounds will expand
> dot, inner, grad, div, and several others into index-notation.
> Not sure what it is you want beyond that?
> 
> Expanding implicit sums and products into explicit sums and
> products is not implemented in UFL, since so far I've opted
> to do that while converting to swiginac in SFC. It would be nice
> to have it in UFL though, but I didn't think you needed that.

Your explanation of expand_compounds was not addressed to the list and
ended up in another inbox so I missed it... :-) Thanks.

-- 
Anders

Attachment: signature.asc
Description: Digital signature