If you run ffc with this version of fiat then all 1D tests fails with both
python 2 and python 3. Isn't that a problem that
needs to be addressed now? Try running the following (got this from Martin):
$ more test.ufl
element = FiniteElement("Lagrange", interval, 1)
ffc --verbose test.ufl
Aslak
2014-07-24 19:14 GMT+02:00 Nico Schlömer <[email protected]>:
> Okay, so the issue seems to be that the API for 1D differs from 2D and
> 3D. Consequently, the test needs to look differently, too.
>
> The 1D `tabulate_derivatives()` says:
> """Returns a tuple of length one (A,) such that
> A[i,j] = D phi_i(pts[j]). The tuple is returned for
> compatibility with the interfaces of the triangle and
> tetrahedron expansions."""
>
> 2D and 3D say:
> # Put data in the required data structure, i.e.,
> # k-tuples which contain the value, and the k-1 derivatives
> # (gradient, Hessian, ...)
>
> This should probably be aligned, but the API will break. I would say
> that this needs to be addressed at some point, but the removal of
> ScientificPython/Python3 operability is a different issue. For now,
> you could just adjust the test for 1D.
>
> Cheers,
> Nico
>
>
> On Thu, Jul 24, 2014 at 6:06 PM, Aslak Bergersen
> <[email protected]> wrote:
> > I have added a test for 1D now, you can see it in [2].
> >
> > Yes, I was talking about [1].
> >
> > Aslak
> >
> > [2]
> >
> https://bitbucket.org/aslakbergersen/fiat/branch/aslakbergersen/topic-prepare-py3
> >
> >
> > 2014-07-24 17:31 GMT+02:00 Nico Schlömer <[email protected]>:
> >
> >> > The code is a little opaque and the returned data structure is a mix
> of
> >> > lists and tuples and
> >> > numpy arrays that differ between 2D and 1D and is not documented well.
> >>
> >> Indeed! When I dived into the code it was hard to figure out what data
> >> structure is needed since everything seems quite convoluted at first.
> >> Cleanup and documentation is needed here.
> >>
> >> --Nico
> >>
> >> On Wed, Jul 23, 2014 at 3:28 PM, Martin Sandve Alnæs <
> [email protected]>
> >> wrote:
> >> > Note: This is about 1D elements, not linear.
> >> >
> >> > Aslak, can you link to the bitbucket branch where you've fixed some of
> >> > the
> >> > other issues with Nicos branch, so others can download it and get to
> the
> >> > issue?
> >> >
> >> > Basically the tabulate_derivative method doesn't return a data
> structure
> >> > in
> >> > the right format so indexing errors occur. The code is a little opaque
> >> > and
> >> > the returned data structure is a mix of lists and tuples and numpy
> >> > arrays
> >> > that differ between 2D and 1D and is not documented well.
> >> >
> >> > Martin
> >> >
> >> >
> >> >
> >> > On 23 July 2014 13:59, Aslak Bergersen <[email protected]>
> >> > wrote:
> >> >>
> >> >> Hi!
> >> >>
> >> >> I found an error in your implementation in fiat, Nico. And I'm having
> >> >> some
> >> >> trouble removing it. It is an error for all linear elements (which is
> >> >> not
> >> >> tested by fiat), and can be easy be reconstructed by running
> >> >>
> >> >> element = FiniteElement("Lagrange", interval, 1)
> >> >>
> >> >> The problem seems to be that tabulate_derivative in LineExpansionSet
> is
> >> >> not changed to return the same as tabulate_derivative in
> >> >> TriangleExpansionSet and TetrahedronExpansionSet. Is there an easy
> fix
> >> >> for
> >> >> this?
> >> >>
> >> >> Aslak
> >> >>
> >> >>
> >> >> 2014-06-29 22:31 GMT+02:00 Nico Schlömer <[email protected]>:
> >> >>
> >> >>> > Changing idioms
> >> >>> > 2py3 changes idioms that are "outdated". When running the script
> it
> >> >>> > changes
> >> >>> > type(t) != type(q) to not isinstance(t, type(q)). Is this this
> >> >>> > something I
> >> >>> > should do?
> >> >>> >
> >> >>> > Python syntax
> >> >>> > The 2to3 scripts have the possibility to change the comma-syntax
> to
> >> >>> > correct
> >> >>> > python syntax. For example, it changes (a,b) to (a, b). Should I
> run
> >> >>> > this on
> >> >>> > the files as well?
> >> >>>
> >> >>> Those are things that Python2 linters like
> >> >>>
> >> >>> pep8
> >> >>> pyflakes
> >> >>> flake8
> >> >>>
> >> >>> usually bring up too. I would say that getting FEniCS clean w.r.t.
> to
> >> >>> those three (largely overlapping) improves the code readability and
> >> >>> quality.
> >> >>>
> >> >>> Cheers,
> >> >>> Nico
> >> >>>
> >> >>>
> >> >>> On Fri, Jun 27, 2014 at 9:21 AM, Aslak Bergersen
> >> >>> <[email protected]> wrote:
> >> >>> > Hi!
> >> >>> >
> >> >>> > I have some questions about the supporting to python 3.x. You can
> >> >>> > take
> >> >>> > a
> >> >>> > look at the changes I have done if you want (or need).
> >> >>> >
> >> >>> > Testing with python 3.3
> >> >>> > I have installed python 3.3 such that I can use it when I want
> (e.g.
> >> >>> > py3
> >> >>> > script.py). However, when I'm running the tests all the
> dependencies
> >> >>> > are
> >> >>> > missing (For now I'm running python -3). So how do I build it with
> >> >>> > python 3?
> >> >>> >
> >> >>> > Support python 3.1
> >> >>> > callable() returned in python 3.2, so there is no need to change
> it,
> >> >>> > unless
> >> >>> > we want to support python 3.1?
> >> >>> >
> >> >>> > Changing idioms
> >> >>> > 2py3 changes idioms that are "outdated". When running the script
> it
> >> >>> > changes
> >> >>> > type(t) != type(q) to not isinstance(t, type(q)). Is this this
> >> >>> > something I
> >> >>> > should do?
> >> >>> >
> >> >>> > Python syntax
> >> >>> > The 2to3 scripts have the possibility to change the comma-syntax
> to
> >> >>> > correct
> >> >>> > python syntax. For example, it changes (a,b) to (a, b). Should I
> run
> >> >>> > this on
> >> >>> > the files as well?
> >> >>> >
> >> >>> > Six module
> >> >>> > I have used the six modules to make it compatible with 2.x and
> 3.x,
> >> >>> > but
> >> >>> > I'm
> >> >>> > a bit unsure where to put it, or how to properly include it to the
> >> >>> > project
> >> >>> > such that all files have access.
> >> >>> >
> >> >>> > --
> >> >>> > Mvh
> >> >>> > Aslak Bergersen
> >> >>> > 993 22 848
> >> >>> >
> >> >>> >
> >> >>> > 2014-05-23 12:56 GMT+02:00 Martin Sandve Alnæs <
> [email protected]>:
> >> >>> >
> >> >>> >> UFL doesn't use __metaclass__ but it uses __new__, is the
> behaviour
> >> >>> >> of
> >> >>> >> that the same? I'd like to clean up those parts at some point
> but I
> >> >>> >> won't
> >> >>> >> have time before the summer.
> >> >>> >>
> >> >>> >> If we have to change behaviour of Expression we should consider
> >> >>> >> doing
> >> >>> >> that
> >> >>> >> simultaneously with the introduction of an Expression-like ufl
> type
> >> >>> >> which
> >> >>> >> will have several advantages.
> >> >>> >>
> >> >>> >> Martin
> >> >>> >>
> >> >>> >>
> >> >>> >> On 23 May 2014 12:24, Johan Hake <[email protected]> wrote:
> >> >>> >>>
> >> >>> >>> And then there is the change of syntax for metaclasses in
> >> >>> >>> Python3...
> >> >>> >>> Just
> >> >>> >>> goggle metaclass python 3 and there are several pointers to the
> >> >>> >>> different
> >> >>> >>> syntax.
> >> >>> >>>
> >> >>> >>> Maybe this will be a good point to throw out the usage of
> >> >>> >>> metaclasses
> >> >>> >>> in
> >> >>> >>> DOLFIN? What we need is to add a distinction between
> >> >>> >>> CompiledExpression and
> >> >>> >>> Expression. I have tried this before with no luck ;)
> >> >>> >>>
> >> >>> >>> Johan
> >> >>> >>>
> >> >>> >>>
> >> >>> >>> On Thu, May 22, 2014 at 11:40 AM, Martin Sandve Alnæs
> >> >>> >>> <[email protected]> wrote:
> >> >>> >>>>
> >> >>> >>>> Yes, and if we're lucky we can get to that point without as
> much
> >> >>> >>>> work as
> >> >>> >>>> sympy, since we don't have as much code.
> >> >>> >>>>
> >> >>> >>>> The 2to3 tool can do selective changes like change print "" to
> >> >>> >>>> print("")
> >> >>> >>>> and fix exception syntax, which are compatible with 2.7.
> >> >>> >>>>
> >> >>> >>>> It can also do things like change "a = dict.iteritems()" into
> "a
> >> >>> >>>> =
> >> >>> >>>> dict.items()" which changes the memory usage when run on 2.7.
> >> >>> >>>> These
> >> >>> >>>> differences can instead be resolved by using the python module
> >> >>> >>>> "six"
> >> >>> >>>> which
> >> >>> >>>> implements cross-compatible helper functions for a lot of
> things.
> >> >>> >>>>
> >> >>> >>>> Btw when we switch we should go straight to python 3.3-3.4.
> >> >>> >>>> Supporting 3.0-3.2 side by side with 2.7 is apparently harder.
> >> >>> >>>>
> >> >>> >>>> (Note to Aslak: read the link from Jan!)
> >> >>> >>>>
> >> >>> >>>> Martin
> >> >>> >>>>
> >> >>> >>>>
> >> >>> >>>> On 22 May 2014 11:22, Jan Blechta <[email protected]>
> >> >>> >>>> wrote:
> >> >>> >>>>>
> >> >>> >>>>> Note that there is also an approach of having simultaneously
> 2.x
> >> >>> >>>>> and
> >> >>> >>>>> 3.x
> >> >>> >>>>> compatible codebase without a need of using 2to3. Allegedly,
> >> >>> >>>>> this
> >> >>> >>>>> is
> >> >>> >>>>> used in SymPy, NumPy and SciPy projects. See
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>>
> http://ondrejcertik.blogspot.cz/2013/08/how-to-support-both-python-2-and-3.html
> >> >>> >>>>>
> >> >>> >>>>> Jan
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>> On Thu, 22 May 2014 11:05:43 +0200
> >> >>> >>>>> Martin Sandve Alnæs <[email protected]> wrote:
> >> >>> >>>>>
> >> >>> >>>>> > The plan for the initial work here is to keep the code
> python
> >> >>> >>>>> > 2.7
> >> >>> >>>>> > compatible but ready for a later swift switch to 3 only. I
> >> >>> >>>>> > suggest we
> >> >>> >>>>> > release fenics 1.5 with python 2.7 compatibility intact but
> >> >>> >>>>> > convertible to python 3 by just running py2to3. Otherwise
> >> >>> >>>>> > there
> >> >>> >>>>> > will
> >> >>> >>>>> > be too much simultaneous breakage. Then we can discuss
> whether
> >> >>> >>>>> > we
> >> >>> >>>>> > leave python 2.7 behind in fenics 1.6 or not.
> >> >>> >>>>> >
> >> >>> >>>>> > However, I haven't thought about the swig side in dolfin,
> and
> >> >>> >>>>> > as
> >> >>> >>>>> > Johan
> >> >>> >>>>> > mentions keeping the Python CAPI code compatible is not
> >> >>> >>>>> > covered
> >> >>> >>>>> > by
> >> >>> >>>>> > py2to3. I'll discuss this with Johan and Aslak.
> >> >>> >>>>> >
> >> >>> >>>>> > Martin
> >> >>> >>>>> >
> >> >>> >>>>> >
> >> >>> >>>>> > On 22 May 2014 10:49, Garth N. Wells <[email protected]>
> wrote:
> >> >>> >>>>> >
> >> >>> >>>>> > > Nice. Do we want to support Python 2.7 and 3, or would it
> be
> >> >>> >>>>> > > more
> >> >>> >>>>> > > sustainable to go all Python 3? My preference is for
> >> >>> >>>>> > > simplicity
> >> >>> >>>>> > > and
> >> >>> >>>>> > > low maintenance, which points to Python 3 only support.
> >> >>> >>>>> > >
> >> >>> >>>>> > > Garth
> >> >>> >>>>> > > On Thu, 22 May, 2014 at 9:39 AM, Martin Sandve Alnæs
> >> >>> >>>>> > > <[email protected]> wrote:
> >> >>> >>>>> > >
> >> >>> >>>>> > >> We have a summer intern at Simula, Aslak Bergersen,
> >> >>> >>>>> > >> who will work on preparations for python 3 support in
> >> >>> >>>>> > >> FEniCS,
> >> >>> >>>>> > >> as well as some other FEniCS tasks, from late June and
> >> >>> >>>>> > >> throughout July.
> >> >>> >>>>> > >>
> >> >>> >>>>> > >> The preparations for python 3 involves mainly:
> >> >>> >>>>> > >> - Replacing ScientificPython for AD in FIAT
> >> >>> >>>>> > >> - Applying and committing backwards compatible parts of
> >> >>> >>>>> > >> py2to3
> >> >>> >>>>> > >> - Replacing several functions such as dict.iteritems with
> >> >>> >>>>> > >> six.iteritems in UFL and possibly FFC to make sure we
> keep
> >> >>> >>>>> > >> the
> >> >>> >>>>> > >> same performance and memory behaviour with python 2 and
> 3.
> >> >>> >>>>> > >>
> >> >>> >>>>> > >> I will be on vacation part of his time here so please
> >> >>> >>>>> > >> help him out if he has questions to the list.
> >> >>> >>>>> > >>
> >> >>> >>>>> > >> Martin
> >> >>> >>>>> > >>
> >> >>> >>>>> > >
> >> >>> >>>>> > >
> >> >>> >>>>>
> >> >>> >>>>
> >> >>> >>>>
> >> >>> >>>> _______________________________________________
> >> >>> >>>> fenics mailing list
> >> >>> >>>> [email protected]
> >> >>> >>>> http://fenicsproject.org/mailman/listinfo/fenics
> >> >>> >>>>
> >> >>> >>>
> >> >>> >>
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > --
> >> >>> > Mvh
> >> >>> > Aslak Bergersen
> >> >>> > 993 22 848
> >> >>> >
> >> >>> >
> >> >>> > _______________________________________________
> >> >>> > fenics mailing list
> >> >>> > [email protected]
> >> >>> > http://fenicsproject.org/mailman/listinfo/fenics
> >> >>> >
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Mvh
> >> >> Aslak Bergersen
> >> >> 993 22 848
> >> >>
> >> >
> >
> >
> >
> >
> > --
> > Mvh
> > Aslak Bergersen
> > 993 22 848
> >
>
--
Mvh
Aslak Bergersen
993 22 848
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
