ufl team mailing list archive

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

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.


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


> Either we extend the __repr__ of FiniteElement to include the scheme,
>

No problem.

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.

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
>