ufl team mailing list archive

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

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.

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

Kristian

> V = VectorElement("CG", "triangle", 1)
>
> So we also need to define V explicitly.
>
> Mehdi
>
>>
>> > I would expect both instances to end up meaning
>> > W = MixedElement([FiniteElement('CG', 'triangle', 1) + B]*2)
>> >
>> > or can you spell it out for me?
>> >
>> >
>>
>> Again, under A:
>>
>> In the first case, V becomes a MixedElement, and then MixedElement +
>> VectorElement -> EnrichedElement
>>
>> In the second case V is a VectorElement and then VectorElement +
>> VectorElement -> VectorElement
>>
>>
>> >>
>> >>> but since this appears to be the case
>> >>> the only two options, as I see it, are:
>> >>>
>> >>> 1) do nothing such that one will have to do
>> >>>
>> >>>   P1 = FiniteElement("Lagrange", tetrahedron, 1)
>> >>>   B = FiniteElement("Bubble", tetrahedron, 3)
>> >>>   Q = FiniteElement("CG", triangle, 1)
>> >>>   Mini = MixedElement([P1 + B], [P1 + B], [P1 + B])*Q
>> >>>
>> >>> manually.
>> >>>
>> >>> 2) have VectorElement accept FiniteElementBase as argument to allow
>> >>>
>> >>>   Mini = VectorElement(P1 + B)*Q
>> >>>
>> >>> which will reduce the labour of defining elements and still be
>> >>> independent of dimensions.
>> >>>
>> >>>
>> >>>
>> >>
>> >> Option 2) sounds neat and useful in other contexts too :)
>> >>
>> > We of course still do this even if we decide on option 1).
>> >
>> >
>>
>>
>> Sorry, this statement was too deep for me: we of course do something
>> even if we do nothing?
>>
>> --
>> Marie
>>
>> > Kristian
>> >
>> >
>> >>
>> >>> We could of course try to 'guess' what the user wants but I don't
>> >>> think that is a good idea.
>> >>>
>> >>>
>> >>>
>> >>
>> >> Agree.
>> >>
>> >> --
>> >> Marie
>> >>
>> >>
>> >>
>> >>> Kristian
>> >>>
>> >>>
>> >>>
>> >>>> v = TestFunction(W)
>> >>>> u = TrialFunction(W)
>> >>>> a = dot(v, u)*dx
>> >>>>
>> >>>> --
>> >>>> Marie
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> Mehdi
>> >>>>
>> >>>>
>> >>>> Kristian
>> >>>>
>> >>>>
>> >>>>
>> >>>> Garth
>> >>>>
>> >>>>
>> >>>>
>> >>>> Kristian
>> >>>>
>> >>>>
>> >>>>
>> >>>> Garth
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Marie
>> >>>>
>> >>>>
>> >>>>
>> >>>>  Mehdi
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Marie
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> Mehdi
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Mailing list: https://launchpad.net/~ffc
>> >>>> Post to     : ffc@xxxxxxxxxxxxxxxxxxx
>> >>>> Unsubscribe : https://launchpad.net/~ffc
>> >>>> More help   : https://help.launchpad.net/ListHelp
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Mailing list: https://launchpad.net/~ffc
>> >>>> Post to     : ffc@xxxxxxxxxxxxxxxxxxx
>> >>>> Unsubscribe : https://launchpad.net/~ffc
>> >>>> More help   : https://help.launchpad.net/ListHelp
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Mailing list: https://launchpad.net/~ffc
>> >>>> Post to     : ffc@xxxxxxxxxxxxxxxxxxx
>> >>>> Unsubscribe : https://launchpad.net/~ffc
>> >>>> More help   : https://help.launchpad.net/ListHelp
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Mailing list: https://launchpad.net/~ffc
>> >>>> Post to     : ffc@xxxxxxxxxxxxxxxxxxx
>> >>>> Unsubscribe : https://launchpad.net/~ffc
>> >>>> More help   : https://help.launchpad.net/ListHelp
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>
>> >>
>>
>
>