ufl team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On 27/04/11 15:43, Johan Hake wrote:
> When is the element/cell set for a coefficient? 

It's decided by the form compiler, which does the setting by calling the
UFL set_foo functions.

Garth


< 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
> <mailto:martinal@xxxxxxxxx>> wrote:
> 
>> On 27 April 2011 15:53, Kristian Ølgaard
>> <<mailto:k.b.oelgaard@xxxxxxxxx>k.b.oelgaard@xxxxxxxxx
>> <mailto:k.b.oelgaard@xxxxxxxxx>> wrote:
>>
>>     On 27 April 2011 15:27, Martin Sandve Alnæs
>>     <<mailto:martinal@xxxxxxxxx>martinal@xxxxxxxxx
>>     <mailto:martinal@xxxxxxxxx>> wrote:
>>     > On 27 April 2011 13:38, Kristian Ølgaard
>>     <<mailto:k.b.oelgaard@xxxxxxxxx>k.b.oelgaard@xxxxxxxxx
>>     <mailto:k.b.oelgaard@xxxxxxxxx>> wrote:
>>     >>
>>     >> On 27 April 2011 13:03, Garth N. Wells
>>     <<mailto:gnw20@xxxxxxxxx>gnw20@xxxxxxxxx <mailto:gnw20@xxxxxxxxx>>
>>     wrote:
>>     >> >
>>     >> >
>>     >> > On 27/04/11 12:00, Kristian Ølgaard wrote:
>>     >> >> On 27 April 2011 12:38, Garth N. Wells
>>     <<mailto:gnw20@xxxxxxxxx>gnw20@xxxxxxxxx <mailto:gnw20@xxxxxxxxx>>
>>     wrote:
>>     >> >>>
>>     >> >>>
>>     >> >>> On 27/04/11 11:08, Kristian Ølgaard wrote:
>>     >> >>>> On 27 April 2011 11:52, Anders Logg
>>     <<mailto:logg@xxxxxxxxx>logg@xxxxxxxxx <mailto: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,
>>     <mailto:noreply@xxxxxxxxxxxxx>noreply@xxxxxxxxxxxxx
>>     <mailto:noreply@xxxxxxxxxxxxx> wrote:
>>     >> >>>>>>>
>>     ------------------------------------------------------------
>>     >> >>>>>>> revno: 1014
>>     >> >>>>>>> committer: Martin Alnæs
>>     <<mailto:martinal@xxxxxxxxx>martinal@xxxxxxxxx
>>     <mailto: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>https://launchpad.net/~dolfin
>>     >> >>>>>> Post to     :
>>     <mailto:dolfin@xxxxxxxxxxxxxxxxxxx>dolfin@xxxxxxxxxxxxxxxxxxx
>>     <mailto:dolfin@xxxxxxxxxxxxxxxxxxx>
>>     >> >>>>>> Unsubscribe :
>>     <https://launchpad.net/~dolfin>https://launchpad.net/~dolfin
>>     >> >>>>>> More help   :
>>     <https://help.launchpad.net/ListHelp>https://help.launchpad.net/ListHelp
>>     >> >>>>>
>>     >> >>>>> _______________________________________________
>>     >> >>>>> Mailing list:
>>     <https://launchpad.net/~ufl>https://launchpad.net/~ufl
>>     >> >>>>> Post to     :
>>     <mailto:ufl@xxxxxxxxxxxxxxxxxxx>ufl@xxxxxxxxxxxxxxxxxxx
>>     <mailto:ufl@xxxxxxxxxxxxxxxxxxx>
>>     >> >>>>> Unsubscribe :
>>     <https://launchpad.net/~ufl>https://launchpad.net/~ufl
>>     >> >>>>> More help   :
>>     <https://help.launchpad.net/ListHelp>https://help.launchpad.net/ListHelp
>>     >> >>>>>
>>     >> >>>
>>     >> >>>
>>     >> >
>>     >> >
>>     >>
>>     >> _______________________________________________
>>     >> Mailing list:
>>     <https://launchpad.net/~ufl>https://launchpad.net/~ufl
>>     >> Post to     :
>>     <mailto:ufl@xxxxxxxxxxxxxxxxxxx>ufl@xxxxxxxxxxxxxxxxxxx
>>     <mailto:ufl@xxxxxxxxxxxxxxxxxxx>
>>     >> Unsubscribe :
>>     <https://launchpad.net/~ufl>https://launchpad.net/~ufl
>>     >> More help   :
>>     <https://help.launchpad.net/ListHelp>https://help.launchpad.net/ListHelp
>>     >
>>     >
>>
>>
>> _______________________________________________
>> Mailing list: <https://launchpad.net/~ufl>https://launchpad.net/~ufl
>> Post to     : <mailto:ufl@xxxxxxxxxxxxxxxxxxx>ufl@xxxxxxxxxxxxxxxxxxx
>> <mailto:ufl@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : <https://launchpad.net/~ufl>https://launchpad.net/~ufl
>> More help   :
>> <https://help.launchpad.net/ListHelp>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