ffc team mailing list archive

[Mehdi <m.nikbakht@xxxxxxxxxx>]

On Fri, 2010-06-18 at 16:23 +0200, Kristian Oelgaard wrote:
> On 18 June 2010 15:25, Mehdi <m.nikbakht@xxxxxxxxxx> wrote:
> > On Fri, 2010-06-18 at 15:08 +0200, 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.
> >>
> >> > 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])
> >>
> >> > 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.
> >
> > If we want to address this issue, the same concept should be also
> > considered for ElementRestriction. What would we expect if we enrich a
> > vector element with a restricted vector element?
> >
> >  V = VectorElement("CG", "triangle", 1)
> >  B = ElementRestriction(V, dc)
> >
> >  W = V + B
> >
> > Since this restricted element is not vector element anymore.
> 
> Can't we just check, inside the '+' operator, if an element is an
> ElementRestriction and then if the restricted element is a
> VectorElement
> BTW, shouldn't it be RestrictedElement (like EnrichedElement) rather
> than ElementRestriction?

Yes, it would be better.

> 
> Another possibility is to propagate the restriction to the subelements
> when creating the restricted element and then return a VectorElement
> with restricted sub elements. Did we try that and fail at some point?
> I forgot.

I think so. We tried to propagate this, but it didn't work for mixed
element as far as remember. Give it a try one more time. If we don't
have this in place, I can't use new functionalities for enriched mixed
element.

Mehdi 

> 
> Kristian
> 
> >
> > Yours,
> > Mehdi
> >
> >
> >>
> >> 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
> >> >
> >
> >