ffc team mailing list archive

[Marie Rognes <meg@xxxxxxxxx>]

On 18. juni 2010 15:08, 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.
>
>   

This will not (and I think should not) crash at the moment: both V and Q
has rank dimension 4, and so enrichment makes sense.

However, if you try to progagate the enrichment to sub-elements, you
will run into trouble.
Hence, I assume that you will either throw an error (which I would not
like, since the construction is not erranous) or return just the
original EnrichedElement.


>> 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])
>
>   

Agree.

>> 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.
>
>   

In the vector RT/B example above, the first version becomes an
EnrichedElement while the second becomes a MixedElement. I don't find
that transparent.

I would really prefer to have the conversion from enriched to mixed be
explicit. But I'll stop arguing now ;)

--
Marie


> 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
>>
>>