ffc team mailing list archive

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

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)

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.

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