ufl team mailing list archive
-
ufl team
-
Mailing list archive
-
Message #01840
Re: [Dolfin] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
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). 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/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
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ufl
> Post to : ufl@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ufl
> More help : https://help.launchpad.net/ListHelp
Follow ups
References
-
Re: [Dolfin] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Kristian Ølgaard, 2011-04-27
-
Re: [Dolfin] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Garth N. Wells, 2011-04-27
-
Re: [Dolfin] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Kristian Ølgaard, 2011-04-27
-
Re: [Dolfin] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Garth N. Wells, 2011-04-27
-
Re: [Dolfin] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Kristian Ølgaard, 2011-04-27
-
Re: [Dolfin] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Martin Sandve Alnæs, 2011-04-27
-
Re: [Dolfin] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Kristian Ølgaard, 2011-04-27
-
Re: [Dolfin] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Martin Sandve Alnæs, 2011-04-27
-
Re: [Dolfin] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Johan Hake, 2011-04-27
-
Re: [Dolfin] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Garth N. Wells, 2011-04-27