ffc team mailing list archive

[Marie Rognes <meg@xxxxxxxxx>]

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


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

While this will be a MixedElement of vector-valued Enriched elements?

My main interest is just to keep the + operator "predictable".


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