By SP-removal branch you mean [4]? I run ffc with [4] and it passes for 1D and 3D but not 2D. The test that I implemented in FIAT is not possible to run.
If you mean [1] by SP-removal, then yes the test that I just implemented in FIAT gives the same error as the tests in ffc and passes for the fenics/master branch. [4] https://bitbucket.org/nschloe/fiat/branch/ <https://bitbucket.org/nschloe/fiat/branch/improve-tests> replace-scientific-python 2014-07-24 19:45 GMT+02:00 Nico Schlömer <[email protected]>: > Okay, then this is a problem. Do you know if your 1D test captures a > difference in behavior between FIAT master and the SP-removal branch? > > --Nico > > On Thu, Jul 24, 2014 at 7:31 PM, Aslak Bergersen > <[email protected]> wrote: > > No, for [3] all tests passes in ffc. > > > > > > [3] https://bitbucket.org/fenics-project/fiat > > > > > > 2014-07-24 19:28 GMT+02:00 Nico Schlömer <[email protected]>: > > > >> Do those tests fail with the latest FIAT master, too? > >> > >> --Nico > >> > >> On Thu, Jul 24, 2014 at 7:27 PM, Aslak Bergersen > >> <[email protected]> wrote: > >> > 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 > >> > > > > > > > > > > > -- > > Mvh > > Aslak Bergersen > > 993 22 848 > > > -- Mvh Aslak Bergersen 993 22 848
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
