ffc team mailing list archive

[Mehdi <m.nikbakht@xxxxxxxxxx>]

On Wed, 2010-06-16 at 18:04 +0200, Kristian Oelgaard wrote:
> On 16 June 2010 17:28, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
> >
> >
> > On 16/06/10 15:55, Kristian Oelgaard wrote:
> >>
> >> On 16 June 2010 16:45, Garth N. Wells<gnw20@xxxxxxxxx>  wrote:
> >>>
> >>>
> >>> On 16/06/10 15:20, Marie Rognes wrote:
> >>>>
> >>>> 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.
> >>>>
> >>>
> >>> A simple example of what's missing is the Stokes mini element. It's not
> >>> presently possible to prescribe only one of the displacement components
> >>> (e.g. u_x) on the boundary. Using V.sub(0).sub(0) in DOLFIN to get the
> >>> u_x
> >>> component breaks.
> >>
> >> Could it work if instead of doing:
> >>
> >> P1 = VectorElement("Lagrange", triangle, 1)
> >> B = VectorElement("Bubble", triangle, 3)
> >> Q = FiniteElement("CG", triangle, 1)
> >> Mini =  (P1 + B)*Q
> >>
> >> you did:
> >>
> >> P1 = FiniteElement("Lagrange", triangle, 1)
> >> B = FiniteElement("Bubble", triangle, 3)
> >> Mini = MixedElement([P1 + B], [P1 + B])*Q
> >>
> >
> > Yes, that will work, but is it what we want? It's a bit clumsy and we lose
> > the dimension-independence since in 3D we would need
> >
> >  P1 = FiniteElement("Lagrange", tetrahedron, 1)
> >  B = FiniteElement("Bubble", tetrahedron, 3)
> >  Mini = MixedElement([P1 + B], [P1 + B], [P1 + B])*Q
> 
> 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.

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