dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #22846
Re: [Ufl] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
On Wed, Apr 27, 2011 at 02:39:17PM +0100, Garth N. Wells wrote:
>
>
> On 27/04/11 14:34, Anders Logg wrote:
> > On Wed, Apr 27, 2011 at 03:24:05PM +0200, Martin Sandve Alnæs 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 started some time before easter, but as Garth says...
> >>
> >>
> >> > 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.
> >>
> >> 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.
> >>
> >>
> >> ... this may be a problem. Since I don't really know the motivation for this
> >> feature request, I can't solve this problem for you.
> >
> > The motivation is that we want to accomplish what we now accomplish
> > with the set_cell/degree functions that you have decided to remove.
> >
> > This allows us to write f = Expression("sin(x[0])") and let the form
> > compiler choose a suitable approximation for the expression.
> >
>
> Just to keep the caching discussion alive ;), perhaps a DOLFIN
> Expression (which is a subclass of ufl.Coefficient) with an incomplete
> function space could have a cache ufl.Expressions that have completely
> defined elements, but which share the eval() function of the original. I
> don't know on a technical level how to make this work.
>
> The JIT compiler would need to return a map of replaced -> new coefficients.
I don't really understand why the set_degree/cell functions are so
bad. I understand that a form should be immutable, but if the cell and
degree are set to "?", we're not really changing anything.
Perhaps it would be enough to insert a check in the set_cell/degree
functions that they can only be called on objects where the cell/degree
has not been set?
--
Anders
> Garth
>
>
> >> Martin
> >>
> >>
> >>
> >>
> >> Garth
> >>
> >> > Kristian
> >> >
> >> >>
> >> >>
> >> >>> 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/~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
> >
>
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: Martin Sandve Alnæs, 2011-04-27
-
Re: [Ufl] [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: Garth N. Wells, 2011-04-27