← Back to team overview

ufl team mailing list archive

Re: [HG UFL] Implement recursive initialization of tensor elements.

 

On Mon, May 05, 2008 at 03:34:41PM +0200, Martin Sandve Alnæs wrote:
> 2008/5/5 Anders Logg <logg@xxxxxxxxx>:
> > On Mon, May 05, 2008 at 03:05:24PM +0200, Martin Sandve Alnæs wrote:
> >> 2008/5/5 Anders Logg <logg@xxxxxxxxx>:
> >> > On Mon, May 05, 2008 at 02:02:39PM +0200, Martin Sandve Alnæs wrote:
> >> >> 2008/5/2 UFL <ufl@xxxxxxxxxx>:
> >> >> > One or more new changesets pushed to the primary ufl repository.
> >> >> > A short summary of the last three changesets is included below.
> >> >> >
> >> >> > changeset:   99:ab1f19b9eb5545605d2651bf95508956aa27ad0b
> >> >> > tag:         tip
> >> >> > user:        Anders Logg <logg@xxxxxxxxx>
> >> >> > date:        Fri May 02 23:16:10 2008 +0200
> >> >> > files:       ufl/basisfunctions.py ufl/finiteelement.py
> >> >> > description:
> >> >> > Implement recursive initialization of tensor elements.
> >> >> > Unit tests pass, but see what you think of it.
> >> >>
> >> >> I don't agree with this, we want to have e.g. symmetric
> >> >> second order tensor elements, which do not fit into this.
> >> >
> >> > In what way do they not fit?
> >> >
> >> > The flag is_symmetric() is still there.
> >> >
> >>
> >> For a symmetric tensor in 3D, there should be only 6 subelements,
> >> and this recursive initialization will create 9.
> >
> > Does that matter? Creating an UFL element is very lightweight so it
> > shouldn't matter that we have a few extra elements. The important
> > thing is for algorithms (and form compilers) to look at is_symmetric
> > and use that to optimize.
> 
> I'm not sure, but I feel that this should closely match the resulting
> UFC element hierarchy that comes out at the other side.

Then what should the hierarchy look like for a symmetric 2x2 tensor
element?

We could do

  [[e, e], [None, e]]

if we like.

-- 
Anders


Follow ups

References