ufl team mailing list archive

[Kristian Oelgaard <k.b.oelgaard@xxxxxxxxx>]

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.

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
>