dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #22847
Re: [Ufl] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,
On 27 April 2011 15:34, Anders Logg <logg@xxxxxxxxx> 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.
>
I'm fairly pessimistic... Let me look into it and come back later.
I spent quite a lot of time trying to get rid of (which failed) and
then minimize the requirement that an expr has a cell.
That problem may still work out ok for now, since
grad(Expression("sin(x[0]")) wouldn't work anyway.
Martin
> --
> Anders
>
>
>
>
>
> > 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
>
>
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