ffc team mailing list archive

[Marie Rognes <meg@xxxxxxxxx>]

On 18. juni 2010 17:09, Kristian Oelgaard wrote:
> On 18 June 2010 16:28, Marie Rognes <meg@xxxxxxxxx> wrote:
>   
>> 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)
>>     
> Not sure what that should accomplish though.
> The whole point of this discussion is how we avoid doing:
>
> V = FiniteElement("CG", "triangle", 1)
> B = FiniteElement("B", "triangle", 3)
> W = MixedElement([V + B]*2)
>
>   


I meant

    V = VectorElement("CG", "triangle", 1)
    B = VectorElement("B", "triangle", 3)
    W = MixedElement(V + B)


> This is more work and dimension dependent. Extending FFC such that:
>
> W = VectorElement(V + B)
>
> is easier and dimension independent.
>
> But in either case, as you also pointed out, one will probably have to
> define elements like
>
> V1 = VectorElement("CG", "triangle", 1)
>
> anyway.
>
> Therefore we proposed that adding VectorElements should behave like
> adding any other vectors i.e., component by component.
> But it looks like it's difficult to agree on a syntax which is fool
> proof to achieve this.
>
>   


Yes. But you are the ones who need to deal with this, and the ones
who will be doing the implementation, so ... ;)

--
Marie


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