ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, May 06, 2008 at 10:38:46AM +0200, Martin Sandve Alnæs wrote:
> 2008/5/6 Anders Logg <logg@xxxxxxxxx>:
> > On Tue, May 06, 2008 at 10:26:27AM +0200, Martin Sandve Alnæs wrote:
> >> 2008/5/6 Anders Logg <logg@xxxxxxxxx>:
> >> > On Mon, May 05, 2008 at 10:45:25PM +0200, Martin Sandve Alnæs wrote:
> >> >> 2008/5/5 Anders Logg <logg@xxxxxxxxx>:
> >> >> > 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.
> >> >> >
> >> >>
> >> >> Basically, yes, but I'm not sure what you mean with the []'s?
> >> >
> >> > I mean that we have a mixed element which has two sub elements,
> >> > each consisting of two (scalar) elements.
> >> >
> >> >> But if I interpret this correctly as Python list, I don't see the
> >> >> advantage of storing this kind of list with None values.
> >> >
> >> > No, it's nested classes. The list notation was just shorthand (and
> >> > confusing).
> >> >
> >> >> I'd rather store a single list of subelements, which can
> >> >> be handled like in any MixedElement most of the time,
> >> >> and store the subelement indices like:
> >> >
> >> > How would you store a simple Taylor-Hood element that way?
> >>
> >> Irrelevant. A Taylor-Hood element is not a TensorElement.
> >
> > No, it's not irrelevant if a TensorElement should be a subclass of
> > MixedElement (which I think it should since it is a special case).
> >
> >> > I think the natural thing would be to have a MixedElement which has
> >> > two sub elements. The first one of these (for u) will be a
> >> > VectorElement (which is a special case of a MixedElement) and that
> >> > element will have a list of two scalar sub elements. The second one
> >> > (for p) will be a FiniteElement (a scalar).
> >> >
> >> > Similarly, one can take a vector-valued BDM-element for u and a scalar
> >> > element for p and combine them into a MixedElement. In that case, each
> >> > of the two sub elements will be a FiniteElement, but one will be
> >> > vector-valued and one scalar.
> >>
> >> I completely agree with that for a general MixedElement.
> >>
> >> I just don't agree that a TensorElement should be
> >> represented as a nested hierarchy of MixedElements,
> >> since this will not be simple as intended for symmetric elements.
> >>
> >> Actually, I'm still not quite comfortable with VectorElement meaning
> >> "vector of element" instead of "vector valued element", and I don't
> >> think that matches what people would expect. Our different opinions
> >> here may be related to this.
> >
> > It's very convenient if one can take any scalar element and use that
> > to create a vector-valued element, and it's also convenient if one can
> > have a single base class (MixedElement) which takes care of it all
> > and have VectorElement and TensorElement as special cases.
> >
> 
> I never said TensorElement shouldn't be a MixedElement.
> I just want it to be a single MixedElement, instead of
> containing a nested hierarchy of MixedElements.
> The reason is that I don't think symmetric elements will fit
> nicely into the hierarchic approach. I suspect using "None"
> as you suggested above will lead to all sorts of special cases.

Do you want the sub elements of TensorElement and VectorElement to
always be scalar?

It looks to me like that would prevent us from doing things like
taking 3 BDM elements and combining them into a matrix-valued element
where each row of the matrix is a BDM-function and then operating on
the basis functions like they were matrix-valued functions. I think
Marie does this.

  BDM = FiniteElement("BDM", ...)

  element = TensorElement(BDM, 3)
  
  u = BasisFunction(element)

  print div(u)

-- 
Anders