ufl team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

When is the element/cell set for a coefficient? If it is during code generation we can add that process to preprocess or what ne it now has, and the changes will only apply to the preprocessed form. 

Johan


On Apr 27, 2011, at 7:00, Martin Sandve Alnæs <martinal@xxxxxxxxx> wrote:

> 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
> >
> >
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~ufl
> Post to     : ufl@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ufl
> More help   : https://help.launchpad.net/ListHelp