ffc team mailing list archive

[Marie Rognes <meg@xxxxxxxxx>]

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