ufl team mailing list archive

[Marie Rognes <meg@xxxxxxxxx>]

On 18. juni 2010 16:16, Kristian Oelgaard wrote:
> On 18 June 2010 15:19, Marie Rognes <meg@xxxxxxxxx> wrote:
>   
>> 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.
>>     
> I think it should, because you will make FFC guess how you want to
> enrich your element V because the number of sub-elements is not equal.
> Using the same logic as in the first 'RT' example:
>
> V = FiniteElement("RT", "triangle", 1)
> Q = VectorElement("B", "triangle", 3)
> W = V + Q
>
> Which is an EnrichedElement([V, Q])
>
> What you want should be implemented as:
>
> V0 = FiniteElement("RT", "triangle", 1)
> V = V0 * V0
> Q = VectorElement("B", "triangle", 3)
>
> W = V + (Q * Q)
>
> Then FFC will know what to do because it sees two VectorElements with
> two sub elements and it will proceed to enrich sub elements such that:
>
> W = MixedElement([ V0 + Q, V0 + Q ])
>
> which is a vector version of the first example.
>
>   
>> 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.
>>     
> It is if you use MY definition :)
>
>   
>> I would really prefer to have the conversion from enriched to mixed be
>> explicit. But I'll stop arguing now ;)
>>     
> So you would prefer if we just implemented
>
> W = VectorElement(V + Q) ?
>
>   


Yes. Or

    W = MixedElement(EnrichedElement)

--
Marie

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