ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, May 06, 2008 at 11:13:06AM +0200, Kent-Andre Mardal wrote:
> 
> tir, 06.05.2008 kl. 10.38 +0200, skrev Martin Sandve Alnæs:
> > 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.
> > 
> 
> I think a mixed element is a collection of (typically different)
> elements, a vector element is an element with values that are vectors, a
> tensor element is an element with values that are tensors. Symmetric
> tensors are useful because then appear often.  
> 
> You can of course create a 2D vector element as a mixed element
> containing two scalar elements. This is not typical, but can be done.
> Still this should not make VectorElement a subclass of MixedElement or
> vica versa.  

I think it's typical. And it's also the way it's implemented in UFC.
At least this is what FFC does; if you create a vector Lagrange
element then you can ask for the sub elements representing each of the
components. This means you can do things like

  w = solve(stokes)

  u = w[0]
  p = w[1]

  ux = u[0]
  uy = u[1]

FIAT used to have vector-valued Lagrange elements but I think they
have been removed since they are not used by FFC anymore. FFC just
takes the scalar elements and adds them up to a mixed element.

-- 
Anders


> The famous AFW elasticity elements is a mixed element where the first
> element is a (possibly symmetric) tensor, the second element is a vector
> element and additionally you can have a scalar element if you want. 
> 
> Kent
> 
> 
> 
> _______________________________________________
> UFL-dev mailing list
> UFL-dev@xxxxxxxxxx
> http://fenics.org/mailman/listinfo/ufl-dev