dolfin team mailing list archive

[Marie Rognes <meg@xxxxxxxxx>]

On 16. juni 2010 15:51, Mehdi wrote:
> On Wed, 2010-06-16 at 14:03 +0200, Marie Rognes wrote:
>   
>> On 16. juni 2010 13:41, Mehdi wrote:
>>     
>>> On Tue, 2010-06-15 at 15:35 +0200, Marie Rognes wrote:
>>>   
>>>       
>>>> -------- Original Message -------- 
>>>>                           Subject: 
>>>> Re: function on EnrichedElement
>>>>                              Date: 
>>>> Tue, 15 Jun 2010 15:27:44 +0200
>>>>                              From: 
>>>> Marie Rognes <meg@xxxxxxxxx>
>>>>                                To: 
>>>> Mehdi <m.nikbakht@xxxxxxxxxx>
>>>>                                CC: 
>>>> gnw20@xxxxxxxxx, Anders Logg
>>>> <logg@xxxxxxxxx>
>>>>
>>>>
>>>> On 15. juni 2010 15:12, Mehdi wrote:
>>>>     
>>>>         
>>>>> On Tue, 2010-06-15 at 14:26 +0200, Marie Rognes wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> On 14. juni 2010 19:57, Marie Rognes wrote:
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> On 14. juni 2010 19:37, Mehdi wrote:
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>> On Mon, 2010-06-14 at 19:18 +0200, Marie Rognes wrote:
>>>>>>>>   
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> On 14. juni 2010 18:10, Mehdi wrote:
>>>>>>>>>     
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>>>> Hi Marie,
>>>>>>>>>>
>>>>>>>>>> I have a function defined on Enriched Element. I want to have access to
>>>>>>>>>> the subfunctions defined on this space. How ffc/ufl can be extended to
>>>>>>>>>> handle this issue? 
>>>>>>>>>>
>>>>>>>>>>   
>>>>>>>>>>       
>>>>>>>>>>         
>>>>>>>>>>             
>>>>>>>>>>                 
>>>>>>>>>>                     
>>>>>>>>> Could you give me a piece of sample code?
>>>>>>>>>     
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>> The input is something like this,
>>>>>>>>
>>>>>>>> Elem1 = VectorElement("Lagrange", triangle, 2)
>>>>>>>> Elem2 = VectorElement("Lagrange", triangle, 1)
>>>>>>>>
>>>>>>>> Element = Elem1 + Elem2
>>>>>>>>
>>>>>>>> u = Coefficient(Element)
>>>>>>>>
>>>>>>>> # I want to have this functionality
>>>>>>>> u1, u2 = split(u)
>>>>>>>>
>>>>>>>> Thank you in advance.
>>>>>>>>
>>>>>>>>   
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>> Will see what I can do tomorrow.
>>>>>>>
>>>>>>> Note that functions on enriched spaces can be a bit treacherous since
>>>>>>> the basis is not a nodal basis.
>>>>>>>
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> I've been thinking some about this. Let me try to explain why this is
>>>>>> nontrivial.
>>>>>>
>>>>>> Say, we have two element spaces
>>>>>>
>>>>>>     V = span ( {v_i} )
>>>>>>     Q = span ( {q_j})
>>>>>>
>>>>>> and create an "enriched space"
>>>>>>
>>>>>>     W = V + Q
>>>>>>
>>>>>> so that
>>>>>>
>>>>>>     W = span ( {v_i, q_j})
>>>>>>
>>>>>> We also define the degrees of freedom on W by taking the set of
>>>>>> all degrees of freedom on V (L_i) and all degrees of freedom on Q (K_j)
>>>>>>
>>>>>>     ( {L_i}, {K_j} )
>>>>>>
>>>>>> At this point, we are starting to tweak the ffc element framework a bit,
>>>>>> because the basis for W is _not_ a nodal basis with respect to the
>>>>>> degrees of freedom: it might be (actually, quite often is) that
>>>>>>
>>>>>>     L_i (q_j) \not = 0
>>>>>>
>>>>>> for all i, j and vice versa for K_j (v_i).)
>>>>>>
>>>>>> A function f in W can be represented as
>>>>>>
>>>>>>     f = \alpha_i v_i + beta_j q_j
>>>>>>
>>>>>> However, note that for some degree of freedom L_k,
>>>>>>
>>>>>>     L_k(f) = \alpha_k + \beta_j L_k(q_j)
>>>>>>
>>>>>> Hence, the coefficients in the vector do _not_ directly correspond to
>>>>>> the degrees of freedom, unless L_k(q_j) = 0 for all k, j. This means
>>>>>> that most kinds of function manipulation on enriched elements give you
>>>>>> something different than what you might think you get.
>>>>>>    
>>>>>> There are however exceptions where things are good: Take for instance
>>>>>> continuous linears plus bubble:
>>>>>>
>>>>>>     V = FiniteElement("CG", "triangle", 1)
>>>>>>     Q = FiniteElement("B", "triangle", 3)
>>>>>>     W = V + Q
>>>>>>
>>>>>> Since the bubble basis functions are zero on the boundary of each
>>>>>> element, with the above notation
>>>>>>
>>>>>>     L_k (q_j) = 0
>>>>>>         
>>>>>>             
>>> This is not the case for the enrichment space(Q) in the partition of
>>> unity method. They are often defined on the same dofs that we have
>>> defined standard space V.
>>>
>>>   
>>>       
>>>>>> for all k, j. This means that you can do
>>>>>>
>>>>>>     f = Function(W)
>>>>>>     g = interpolate(f, V)
>>>>>>
>>>>>> Then g will be what I think you want from
>>>>>>
>>>>>>     (g, h) = split(f)
>>>>>>    
>>>>>> In order to get h, you could do
>>>>>>
>>>>>>     h = f - g
>>>>>>
>>>>>>
>>>>>> It would be possible to extract the vectors {\alpha_i} and {\beta_j}
>>>>>> from a Function on an enriched elements, but this requires quite a bit
>>>>>> of work, and is mainly DOLFIN related (rather than FFC/UFL).
>>>>>>
>>>>>>         
>>>>>>             
>>> To handle this inside DOLFIN, we extract required data form vectors. Why
>>> performing the approach inisde FFC/UFL is difficult? Isn't it just
>>> enough to pick up the components corresponding to a specific space from
>>> enriched space?
>>>
>>>   
>>>       
>>
>> I don't see how to do this. If you or anyone else know how, go ahead :)
>>     
> OK. let me give it a try. Maybe this is a hack, but I think we may need
> to attach offsets for the sub functions derived from enriched space. Is
> there any reason why not this should work?
>
>   


I probably misunderstood your original request, thinking that you wanted
to extract
(v, w) from {v + w}...

One way of doing what I now _think_ that you want, is to add some
functionality to FFC/UFL to convert an enriched mixed element to a mixed
enriched element and then do split. This is feasible. But I still think
that this should _not_ be the default behaviour for enriched mixed elements.


--
Marie

>  Mehdi
>
>   
>> --
>> Marie
>>
>>
>>     
>>> Mehdi
>>>
>>>   
>>>       
>>>>      
>>>>     
>>>>         
>>>>> Actually we were handling this inside main file before, but we didn't
>>>>> like it. It makes code dirty especially for the nonlinear problems in
>>>>> which we need to obtain these functions in each iteration explicitly.
>>>>>
>>>>>  We think that handling enriched elements inside FFC/UFL is not
>>>>> consistent with the rest. This causes problems while working with
>>>>> enriched elements.
>>>>>   
>>>>>       
>>>>>           
>>>> So, let's take this discussion on a mailing list instead?
>>>>
>>>> --
>>>> Marie
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~ffc
>>>> Post to     : ffc@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~ffc
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>     
>>>>         
>>>   
>>>       
>>     
>