July 2017 - firedrake - imperial.ac.uk

broken install using python3
by Shipton, Jemma 09 Aug '17

09 Aug '17

Hi All, I have tried to run "python3 firedrake-install --install gusto" and almost succeeded. I've attached the log file... I had to interrupt a previous install but I just removed the directory and started again - not sure if that's the problem. Thanks! Jemma

4 11

Firedrake is now Python3
by Lawrence Mitchell 28 Jul '17

28 Jul '17

Dear all, as of today, Firedrake now only supports Python 3. In particular, we require Python >= 3.5 Rationale ========= The Python development team have formally end-of-lifed Python 2. Python 2.7 will be the last ever Python in the 2 series (see https://www.python.org/dev/peps/pep-0373/#update) Similarly, many large Python packages have stopped new feature releases compatible with Python 2. For example, the most recent IPython releases are Python 3 only. The Scientific Python community is also commited to dropping support for Python 2 by 2020. See http://www.python3statement.org/ for details. What does this mean for you? ============================ Upgrading existing installations -------------------------------- For technical reasons to do with how we package a firedrake installation, upgrading an existing (Python 2) install is *not possible*. You will instead have to reinstall from scratch. Should you attempt to update your old install, you will get an error message informing you to reinstall. Fresh installations ------------------- The installation procedure is as before (but remember to download a new copy of the firedrake-install script). See http://firedrakeproject.org/download.html for details. Porting your code to Python 3 ----------------------------- Most Python code that you have been writing will be compatible with Python 3 already, especially if you have been writing: from __future__ import division, print_function, absolute_import at the top of your Python files. To find out what to do in detail, we recommend the advice on http://python-future.org/, in particular, their cheat sheet: http://python-future.org/compatible_idioms.html You of course do not need to write compatible code, but you can use this to see how to convert your Python 2isms to Python 3. The most common gotchas are: . print is no longer a statement, but a function. You cannot write: print "foo" But instead should write: print("foo") This is enforced in Python 2 with "from __future__ import print_function" . division of integers returns a floating point number. In Python 2: 1 / 2 => 0 In Python 3: 1 / 2 => 0.5 If you actually want integer division, write: 1 // 2 => 0 This is enforced in Python 2 with "from __future__ import division" . Iteration constructs now return generators, not lists In Python 2, calls like dict.keys(), or range, return a list (i.e. they are eager). In Python 3, they return a generator that may be iterated over (i.e. they are lazy). You must explicitly convert them to a list if you want that. As ever, if you have any problems installing or updating, please do get in touch with bug reports. Cheers, Lawrence (& the rest of the Firedrake team)

1 0

Reminder: Firedrake is transitioning to Python 3
by Ham, David A 21 Jul '17

21 Jul '17

Dear Firedrakers, This is just a reminder that Firedrake is about to transition from Python 2.7 to Python 3. The core developers will be undertaking the work next week. What does this mean for Firedrake users? 1. You'll need to reinstall Firedrake. The install mechanism won't be changing, and we'll send another email telling you when to update. 2. You may need to make a few changes in your own code that uses Firedrake in order to be Python 3 compatible. These changes are typically very small and our upgrade email will provide pointers to documentation which helps. Why is this happening? Python 2.7 was released in 2010 and is effectively end of life. The latest release of iPython no longer supports Python 2.7, so we took that as our cue that 2.7 is really dead and we need to move. There are new features of recent Pythons that we'll also get to use. The first one that some Firedrake users will notice is that we'll switch from the third party virtualenv to Python 3's inbuilt venv. This will get rid of the irritating and confusing need to run the install script twice on some new computers. (At a lighter level, you can also now use all the Unicode letters as variable names, so if you want to write your test functions as φ and ψ, you now can!) Why aren't we supporting both Python 2.7 and 3? While it is possible to write code which is compatible with both versions, this would just be a brief delaying of the inevitable demise of Python 2.7. More importantly, it would create a situation where users and developers were running on significantly different platforms with different bugs. This is a recipe for confusion and additional work for both users and developers. We're therefore going to swap in one clean move. Regards, David

1 0

Firedrake install fails
by William Booker 13 Jul '17

13 Jul '17

Hi, I've tried to install Firedrake on a new machine and can't seem to get passed this error. I've attached the log, where it says it fails due to an outdated autoconf dependency. I've asked IT, and they've said "The default version of autoconf on mat-lin4123 is the most recent Centos version (2.63). I've installed the EPEL version of autoconf (version 2.68), which is accessible as autoconf268." But the install script still fails with the same error. How can I work around this? Thanks Will

3 2

Problems with the Linear Solver
by Keegan Cove 13 Jul '17

13 Jul '17

Hello, We are using a one-layer quasi-geostrophic model to find a steady linear solution. The code we are using is attached. It is very similar in structure to working code that we have used previously. However, when we try running it, we get an error, copied below. The issue seems to be occurring in a structure that the user would not normally be interacting with. If you could offer any advice, that would be very much appreciated. Thank you, Keegan UFL:WARNING Form has no parts with arity 2. Traceback (most recent call last): File "QG1L-interface-drag.py", line 83, in <module> soln0 = steadylinearQG2d(ZTrial, ZTest, Gwinds, bcs) File "QG1L-interface-drag.py", line 29, in steadylinearQG2d linear_problem = LinearVariationalProblem(lhs(G), rhs(G), soln, bcs=bcs) File "/Users/krcove/firedrake/src/firedrake/firedrake/variational_solver.py", line 255, in __init__ F = ufl.action(J, u) - L File "/Users/krcove/firedrake/src/ufl/ufl/formoperators.py", line 121, in action return compute_form_action(form, coefficient) File "/Users/krcove/firedrake/src/ufl/ufl/algorithms/formtransformations.py", line 416, in compute_form_action u = arguments[-1] IndexError: tuple index out of range _____________ Keegan Cove Undergraduate Research Intern Department of Applied Math University of Waterloo Student ID: 20513673 Email: krcove(a)edu.uwaterloo.ca Telephone: +1 519 888 4567 x32746

2 1

Navier Stokes solver for engineering applications (flow around an airfoil)
by Eike Mueller 10 Jul '17

10 Jul '17

Dear Firedrakers, has anyone ever used Firedrake to solve the (fully compressible) Navier-Stokes equations in engineering applications? I’m talking to a colleague here in Bath who would like to model the flow of air around an aircraft wing, and am trying to find out how best to approach this. The flow is turbulent in some regions, but smooth in others. Not exactly sure which equations and turbulence model would be appropriate, but I suspect it will require (adaptive) refinement in parts of the domain where the turbulent eddies are shedded. Also, the domain to be modeled would contain a hole (which is taken up by the wing) and we’d likely use an unstructured mesh. The wing is allowed to transform. For this a continuum mechanics code implemented in DUNE is used, so we would need to feed this the boundary conditions from Firedrake. As a result of the DUNE calculation, the Firedrake mesh would change from one timestep to the next. It might be possible to re-write the DUNE code in Firedrake, but it contains a very specific multigrid-preconditioner developed by Rob’s group and implemented by Linus Seelinger, which uses global eigenfunctions in the coarse space - so can’t just throw AMG at it. If anyone has ever done something similar or has any suggestions I would be very curious to hear about it. Thanks a lot, Eike

3 5