ufl team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Wednesday April 27 2011 07:54:14 Anders Logg wrote:
> On Wed, Apr 27, 2011 at 03:48:42PM +0100, Garth N. Wells wrote:
> > 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.
> > 
> > < 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.
> 
> Good point. It's set in the analysis.py in FFC, right after the call
> to preprocess (compute_form_data). 

Well, then I guess the form which get changed is already stripped from any 
DOLFIN specific objects :)

Are there other situations where we per today change the form in a now illegal 
way? Adaptivity comes in my mind...

Johan


> It only relies on the
> 
>   form_data.cell
>   form_data.sub_elements
> 
> So we might be able to handle it by making sure the preprocessed_form
> gets as input the two arguments common_cell and common_degree that are
> computed in the function _adjust_elements in analysis.py.
> 
> --
> Anders
> 
> > > 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
> > >>     >> >>>> 
> > >>     >> >>>>>> 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/Li
> > >>     stHelp
> > >>     
> > >>     >> >>>>> _______________________________________________
> > >>     
> > >>     >> >>>>> 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/Li
> > >>     stHelp
> > >>     
> > >>     >> _______________________________________________
> > >>     
> > >>     >> 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/Li
> > >>     stHelp
> > >> 
> > >> _______________________________________________
> > >> 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/ListHe
> > >> lp
> > > 
> > > _______________________________________________
> > > 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