ufl team mailing list archive

[Mehdi <m.nikbakht@xxxxxxxxxx>]

On Fri, 2010-06-18 at 15:08 +0200, Kristian Oelgaard wrote:
> On 18 June 2010 14:12, Marie Rognes <meg@xxxxxxxxx> wrote:
> > On 18. juni 2010 13:43, Kristian Oelgaard wrote:
> >
> > On 18 June 2010 13:20, Mehdi <m.nikbakht@xxxxxxxxxx> wrote:
> >
> >
> > On Fri, 2010-06-18 at 12:34 +0200, Marie Rognes wrote:
> >
> >
> > On 18. juni 2010 12:23, Kristian Oelgaard wrote:
> >
> >
> > On 18 June 2010 12:05, Marie Rognes <meg@xxxxxxxxx> wrote:
> >
> >
> >
> > On 18. juni 2010 11:38, Kristian Oelgaard wrote:
> >
> >
> >
> > On 18 June 2010 01:44, Marie Rognes <meg@xxxxxxxxx> wrote:
> >
> >
> >
> >
> > On 17. juni 2010 15:44, Mehdi wrote:
> >
> > On Wed, 2010-06-16 at 18:04 +0200, Kristian Oelgaard wrote:
> >
> >
> >
> > Mehdi and I discussed this a bit, one way to get around this in FFC is to
> > let
> > VectorElement accept a FiniteElement as argument, then you can do
> >
> > element = VectorElement(V + Q)
> >
> > and still be dimension independent.
> >
> > Or in UFL we can tweak the '+' operator, such that enriching a
> > VectorElement means enriching each of the components of 'self' with
> > the components of 'other'. For this to work the dimension of the two
> > vector elements must of course be identical but I guess that will
> > always be the case, otherwise we throw an error.
> >
> >
> > I will go for this option. This allows us to have simpler code and
> > preserves accessing to the sub-elements of enriched mixed element.
> >
> >
> >
> > How do you plan on handling elements such as the following (relevant in
> > connection with the PEERS element for linear elasticity) with this approach?
> >
> > V = FiniteElement("RT", "triangle", 1)
> > Q = VectorElement("B", "triangle", 3)
> > W = V + Q
> >
> >
> >
> >
> > I was planning on throwing an error :)
> >
> >
> >
> >
> > Please don't :)
> >
> >
> >
> >
> > I did not know that one would ever want to enrich a scalar element
> > with a vector bubble function,
> >
> >
> >
> > Since RT is a vector-valued element, enriching it with a vector bubble
> > function
> > is well-defined.
> >
> >
> >
> > Ha, I completely missed the 'RT', that's what you get for working with
> > 'CG' only :)
> > Now it makes a lot more sense to me.
> >
> >
> >
> >
> > Ok :)
> >
> >
> >
> > Strictly speaking, my example is not the enrichment of one UFL VectorElement
> > with another VectorElement. So, I guess you could overload + for
> > VectorElement (and TensorElement) only. However, that would make
> >
> >
> >
> > Yes, that's what we had in mind, then instead of an error we just
> > return an EnrichedElement, then it's up to the user to make sure that
> > the enrichment makes sense. I haven't looked at the code in detail
> > now, but maybe there are other things we need to check for.
> >
> >
> >
> >
> >    V = FiniteElement("CG", "triangle", 1)
> >    V = V*V
> >    B = VectorElement("B", "triangle", 3)
> >    W = V + B
> >
> > and
> >
> >    V2 = VectorElement("CG", "triangle", 1)
> >    W = V2 + B
> >
> > behave differently, which I imagine could be rather confusing.
> >
> >
> >
> > They do?
> >
> >
> >
> > Assumption A: If you only overload + for VectorElement and TensorElement.
> >
> > Under A, yes.
> >
> >
> > I think if we want to overload +, by default we should treat these two
> > cases equally.
> >
> >
> > Well, I never intended to overload '+' for just Vector and Tensor elements,
> > I would overload the MixedElement class which is the base class for
> > the two special types.
> > Then the two cases will result in the same element, we should of
> > course check for equal length of the two mixed elements, and in case
> > of nested mixed elements, we let the '+' operator handle this on the
> > sub elements.
> >
> >
> >
> > Ok, then what will be the effect for a mixed/vector version of my previous
> > example? (which is even more relevant for the PEERS element ;) )
> >
> > V = FiniteElement("RT", "triangle", 1)
> > V = V * V
> > Q = VectorElement("B", "triangle", 3, 4)
> >
> > W = V + Q
> 
> This will (and should) crash for sure, len(V) = 2, len(Q) = 4; so it
> makes no sense to enrich the sub elements.
> 
> > The above W will then be an EnrichedElement of vector-valued elements?
> >
> > V = FiniteElement("RT", "triangle", 1)
> > V = V * V
> > Q = VectorElement("B", "triangle", 3)
> > Q = Q * Q
> >
> > W = V + Q
> 
> V0 = FiniteElement("RT", "triangle", 1)
> V = V0 * V0
> Q0 = VectorElement("B", "triangle", 3)
> Q = Q0 * Q0
> W = V + Q
> 
> This is will end up as:
> 
> E0 = V0 + Q0 # EnrichedElement([V0, Q0])
> W = MixedElement( [E0,  E0] )
> 
> and the example we had before:
> 
> V0 = FiniteElement("CG", "triangle", 1)
> V = V0 * V0
> B0 = FiniteElement("B", "triangle", 3)
> B  = B0 * B0
> W = V + B
> 
> will be:
> E0 = V0 + B0
> W = MixedElement([E0, E0])
> 
> > While this will be a MixedElement of vector-valued Enriched elements?
> >
> > My main interest is just to keep the + operator "predictable".
> 
> That looks pretty predictable to me, but there might be other elements
> that I'm unaware of for which the logic breaks.

If we want to address this issue, the same concept should be also
considered for ElementRestriction. What would we expect if we enrich a
vector element with a restricted vector element?

 V = VectorElement("CG", "triangle", 1)
 B = ElementRestriction(V, dc)

 W = V + B

Since this restricted element is not vector element anymore.

Yours,
Mehdi


> 
> Kristian
> 
> >
> > Another advantages of using this approach is we don't need to define
> > unnecessary scaler elements to just get mixed enriched element. The
> > approach of defining scaler elements can be annoying, if we want to use
> > both enriched and non-enriched vector elements(which is the case often
> > for me).
> >
> > If we overload +, it is just enough to have:
> >
> > V = VectorElement("CG", "triangle", 1)
> > B = VectorElement("B", "triangle", 3)
> > M = V + B
> >
> > We can use M and V both to define our functions.
> >
> >
> > This is definitely and advantage.
> >
> >
> >
> > If we want to extend VectorElement, this would be,
> >
> > V1 = FiniteElement("CG", "triangle", 1)
> > B1 = FiniteElement("B", "triangle", 3)
> > M = VectorElemnet(V1 + B1)
> >
> >
> > But we can still extend the vector element to enable this it you think
> > it will be useful, that was the essence of my earlier and confusing
> > remark which should have been:
> >
> > 'We CAN of course still do this even if we decide on option 1)'
> >
> >
> > Ok, sentence makes sense now!
> >
> > --
> > Marie
> >