dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #22848
Re: [Ufl] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
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
>>
>> 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
>
>
Follow ups
References
-
Re: [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Garth N. Wells, 2011-04-27
-
Re: [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Anders Logg, 2011-04-27
-
Re: [Ufl] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Kristian Ølgaard, 2011-04-27
-
Re: [Ufl] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Garth N. Wells, 2011-04-27
-
Re: [Ufl] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Kristian Ølgaard, 2011-04-27
-
Re: [Ufl] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Garth N. Wells, 2011-04-27
-
Re: [Ufl] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Kristian Ølgaard, 2011-04-27
-
Re: [Ufl] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
From: Martin Sandve Alnæs, 2011-04-27