dolfin team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

On 27 April 2011 15:53, Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx> wrote:

> On 27 April 2011 15:27, Martin Sandve Alnæs <martinal@xxxxxxxxx> wrote:
> > On 27 April 2011 13:38, Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx> wrote:
> >>
> >> On 27 April 2011 13:03, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
> >> >
> >> >
> >> > On 27/04/11 12:00, Kristian Ølgaard wrote:
> >> >> On 27 April 2011 12:38, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
> >> >>>
> >> >>>
> >> >>> On 27/04/11 11:08, Kristian Ølgaard wrote:
> >> >>>> On 27 April 2011 11:52, Anders Logg <logg@xxxxxxxxx> wrote:
> >> >>>>> On Wed, Apr 27, 2011 at 10:40:50AM +0100, Garth N. Wells wrote:
> >> >>>>>> We need a quick discussion round to resolve this issue - DOLFIN
> is
> >> >>>>>> now
> >> >>>>>> broken. I guess we need the form compiler to decide on the cell
> and
> >> >>>>>> element type, and then have UFL return a new form.
> >> >>>>>
> >> >>>>> Yes, Martin mentioned at some point that it would be easy to add
> >> >>>>> such
> >> >>>>> a function to UFL (that takes a form and replacement elements and
> >> >>>>> returns a new form).
> >> >>>>>
> >> >>>>> Martin, could you add such a function?
> >> >>>>
> >> >>>> I think ufl.algorithm.transformations.replace would work if
> >> >>>> FiniteElementBase derived from 'Terminal'.
> >> >>>> Currently, it derives from 'object', what is the reason for that?
> >> >>>> Anyway, it should be simple enough to add something equivalent for
> >> >>>> elements.
> >> >>>>
> >> >>>
> >> >>> I was thinking that we only need to replace Coefficients, e.g. if a
> >> >>> Coefficient is defined using an 'incomplete element', FFC can create
> >> >>> an
> >> >>> element, a Coefficient and the perform the replacement. Looks like
> UFL
> >> >>> can do this already.
> >> >>
> >> >> Yes, I think that should be possible. But what about quadrature
> >> >> elements?
> >> >>
> >> >> If the scheme is not specified when constructing the element (in the
> >> >> form), then the scheme
> >> >> will be determined by the commandline arguments (or metadata) to FFC.
> >> >> The
> >> >> QuadratureElement needs the scheme information in the constructor in
> >> >> order to
> >> >> generate the points for which it is defined.
> >> >>
> >> >
> >> > I don't see the problem. Couldn't FFC generate a new QuadratureElement
> >> > (of the correct degree) and define a Coefficient on it?
> >>
> >> I guess it could.
> >
> > That would be natural to do simultaneously with replacing elements in
> other
> > coefficients.
>
> Yes, we can start writing the code for this in ffc.analysis, but I
> think that we will end up with something that might just as well
> become a 'replace_element' function in ufl.algorithms.transformations


The replace_elements algorithm will be easy to add to ufl,
the problem is what to do with PyDOLFIN Functions and Expressions.

Martin

>> Another question is if we should have a separate class in UFL for
> >> quadrature elements?
> >> The reason is that UFL uses (family, cell, degree) to check for
> >> uniqueness (through __repr__ --> __hash__),
> >> but the quadrature element will need the 'scheme' as well, which can
> >> be None until FFC determines it.
> >
> > Just set it to None by default.
>
> Sure, since the scheme will be part of the __repr__, I'll add the
> scheme argument between the degree and form_degree argument in
> FiniteElement:
>
> def __init__(self, family, cell, degree=None, quad_scheme=Nonw,
> form_degree=None)
>
> >>
> >> Either we extend the __repr__ of FiniteElement to include the scheme,
> >
> > No problem.
>
> OK, that is my preferred solution. Just wanted to check if anyone had
> a problem with the signature increase, or if there were some design
> reasons to avoid this.
>
> >>
> >> or we can use a separate class QuadratureElement.
> >
> > That would require adding VectorQuadratureElement etc, and the same in
> > PyDolfin, major waste of time if you ask me.
>
> Yes I agree, but necessary if someone objects to extending __repr__.
>
> Kristian
>
> > Martin
> >>
> >> For the majority of finite elements the 'scheme' information in
> >> __repr__ is superfluous, so a separate class might be preferable.
> >> If we use a separate class, then the question is if we want to do:
> >>
> >> 1) element = QuadratureElement(cell, degree, scheme)
> >> or
> >> 2) element = FiniteElement(family, cell, degree, scheme=scheme)
> >>
> >> when creating a quadrature element object.
> >>
> >> For case 2 we probably need to implement FiniteElement.__new__ to
> >> return a QuadratureElement if family == 'Quadrature'.
> >>
> >> Kristian
> >>
> >> > Garth
> >> >
> >> >> Kristian
> >> >>
> >> >>> The problem from the DOLFIN side is that the new UFL Coefficient
> will
> >> >>> be
> >> >>> different from the DOLFIN/UFL Coefficient, and would be a
> >> >>> ufl.Coefficient and not a dolfin.Coefficient.
> >> >>>
> >> >>> Garth
> >> >>>
> >> >>>> Kristian
> >> >>>>
> >> >>>>> --
> >> >>>>> Anders
> >> >>>>>
> >> >>>>>
> >> >>>>>> Garth
> >> >>>>>>
> >> >>>>>> On 26/04/11 07:32, noreply@xxxxxxxxxxxxx wrote:
> >> >>>>>>> ------------------------------------------------------------
> >> >>>>>>> revno: 1014
> >> >>>>>>> committer: Martin Alnæs <martinal@xxxxxxxxx>
> >> >>>>>>> branch nick: ufl
> >> >>>>>>> timestamp: Fri 2011-04-15 21:44:37 +0200
> >> >>>>>>> message:
> >> >>>>>>>   Add warnings to set_foo functions in finiteelement.py,
> >> >>>>>>>   and remove repr modifications after construction time.
> >> >>>>>>>
> >> >>>>>>>   If this will break your code, it likely wasn't working
> >> >>>>>>>   correctly anyway and you need to rewrite it before you
> >> >>>>>>>   can update to this UFL version.
> >> >>>>>>>
> >> >>>>>>>   The set_foo functions will be removed completely before UFL
> 1.0.
> >> >>>>>>>
> >> >>>>>>>   Happy easter holiday :)
> >> >>>>>>> modified:
> >> >>>>>>>   ufl/finiteelement.py
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> _______________________________________________
> >> >>>>>> Mailing list: https://launchpad.net/~dolfin
> >> >>>>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> >> >>>>>> Unsubscribe : https://launchpad.net/~dolfin
> >> >>>>>> More help   : https://help.launchpad.net/ListHelp
> >> >>>>>
> >> >>>>> _______________________________________________
> >> >>>>> Mailing list: https://launchpad.net/~ufl
> >> >>>>> Post to     : ufl@xxxxxxxxxxxxxxxxxxx
> >> >>>>> Unsubscribe : https://launchpad.net/~ufl
> >> >>>>> More help   : https://help.launchpad.net/ListHelp
> >> >>>>>
> >> >>>
> >> >>>
> >> >
> >> >
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~ufl
> >> Post to     : ufl@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~ufl
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
>