Archive for August, 2010

Fwrap has moved to github

August 25, 2010

From mercurial to git

After speaking with some folks at SciPy-Austin this year (in particular, Fernando Perez), I wanted to try out git & github as an alternative to mercurial & bitbucket.  As with anything with so much overlap, there are pros and there are cons, and it comes down to small differences.  The deciding factor, ultimately, was the hg-git mercurial plugin, which allows someone to use a mercurial client with a git repository, with improved branch functionality.  So all of the nice, smooth, user-friendly mercurial commands you’re used to are available, and you can push/pull bookmarks a-la git branches.  (I’ve not used this extensively, so caveat emptor.)

Some of my reasons for the move:

  • As mentioned above, the hg-git plugin allows both mercurial and git users to collaborate using the same repository, so there is no need for current mercurial users to have to change to git.
  • The numpy/scipy ecosystem is converging on git & github for SCM.  Arguably Cython (which uses mercurial) would be more influential here, but pretty much every fwrap user would be coming from a numerical & Fortran background, which would be more numpy/scipy-centric, hence git & github.
  • The way Git handles branches fits my style much better.  And I really like the index.  Mercurial seems to encourage enabling the ‘queue’ extension for advanced stuff, but it just plain doesn’t fit my brain, and I always screw it up.  Granted, it’s plenty easy to blow off your hand using git, although I’ve become quite proficient at messing up whatever SCM I’m using at the time.
  • It seems that mercurial goes to great lengths to keep their design pure, which I can respect.  Unfortunately by not allowing bookmarks to be pushed/pulled as part of the wire protocol, they force you to use mercurial branches, which are much heavier than I need them to be.  If mercurial would just allow bookmarks (which are the closest analogue to git branches) to be pushed-pulled, I’d have a much harder time justifying the switch to git.

Github repository

Fwrap’s new home:


Fwrap wiki & roadmap

August 17, 2010

FYI, fwrap has a wiki that is slowly filling-in.  There are (or will be) tutorials that guide you through getting everything set-up correctly, FAQs, etc.

Specifically, I just posted a rough roadmap on the fwrap wiki, outlining what fortran features are currently supported and what will be supported in upcoming versions:

I commend it to your attention.

Fwrap vis-a-vis f2py

August 8, 2010

Some have asked how fwrap relates to f2py.

Broadly, fwrap can be seen as an update of f2py for all of Fortran 90/95, addressing the features that f2py does not support at the present time.  My understanding is that the 3rd version of f2py intends to address many of these features, but that version of f2py is far from complete.  This is not intedended as a critique of f2py, merely a brief comparison of the two projects.

Fwrap focuses on generating Cython wrappers for Fortran code, and the Python-level wrappers come for free, in a sense.  Fwrap uses the Fortran parser–named ‘fparser’–that Pearu Peterson (the author of f2py) created for the latest incarnation of f2py.  In contrast to Fwrap using Cython, f2py generates the C extension module directly–quite an undertaking.  Fwrap focuses on all 3 levels of wrapping: C, Cython and Python; and the C wrappers can be used without any Cython or Python dependency.

Fwrap generates one more wrapping layer than f2py; this allows fwrap to eventually support every desirable feature in Fortran 90/95 (and, in principle, 2003).

F2PY has a very nice interface file functionality, and supports comment directives in the fortran source to specify how it is to handle different arguments.  These features are planned for fwrap, but currently it is easier to make ‘pythonic’ wrappers with f2py, while fwrap just wraps every argument directly, taking into account the argument’s intent.

Fwrap has planned some features that are not in f2py: for instance, a fortan inline module that is similar to scipy’s weave, user derived types, automatic type discovery, and (way in the future) wrapping a Fortran module in a Cython class.

Pearu and I are on good terms and we both collaborate to make fparser better along with the other fparser & f2py developers.  F2PY is an impressive project and provides the skeleton for many Python & Fortran projects, most prominently among them being SciPy.

Fwrap would not exist if f2py had not blazed the trail, and paved over half of it 🙂

Announcing the first release of Fwrap

August 7, 2010

Fwrap v0.1.0

I am pleased to announce the first release of Fwrap v0.1.0, a utility for
wrapping Fortran code in C, Cython and Python. Fwrap focuses on supporting the
features of Fortran 90/95, but will work with most well-behaved Fortran 77
code, too.

Fwrap is BSD licensed.

Fwrap is beta-level software; all public APIs and commandline options are
subject to change.

Features in the v0.1.0 release:

  • Fortran source parsing and automatic wrapper generation;
  • Top-level (non-module) Fortran subroutines and functions;
  • Supports all intrinsic types (integer, real, complex, logical &
  • Default and non-default intrinsic types properly wrapped;
  • Scalar and array arguments supported;
  • Supports assumed-shape, assumed-size, and explicit-shape array arguments;
  • Intent ‘in’, ‘inout’, ‘out’ and no intent arguments supported;
  • Automatic docstring generation for extension module and functions;
  • Wrappers are portable w.r.t. both Fortran and C compilers.

Upcoming features:

  • “Use” statement support;
  • Python & Cython callback support;
  • Kind-parameters in type specification;
  • Module-level data and parameters;
  • User-derived types.

See the README and documentation for requirements, compiler support, etc.


You can get fwrap from pypi or from its sourceforge download page:

More Info

Project homepage, including links to wiki & bug tracker:

Mailing list:

Development blog:

Fortran + CUDA

August 5, 2010

PGI has some very nice CUDA support in the latest version of their fortran compiler.  Here’s the article. []  This may be old news to some of you, but I’m impressed.  Hopefully CUDA support is in the pipeline for the other fortran vendors as well, and something of a standard can emerge from this.

My first impression is that this is an ideal sweet spot, allowing the usage of nice high-level fortran array expressions on the host when convenient, and dropping into CUDA code where speed is a must.  Granted the host-device bandwith is painfully slow, so there is a significant overhead, but ideally it would allow incremental speedups, all within fortran.

I’m glad to see Fortran adapting to the latest technology, as it has done every generation or so; brings to mind the quip:

“What language will they be using 30 years from now?”

“I don’t know, but they’ll call it ‘Fortran’.”

And yet the standard is still backwards compatible with code from almost 35 years ago.  AFAICT, it’s the combination of adaptibility and backwards compatibility that keeps Fortran around.

Now if they would only get better I/O syntax, named goto labels (not ‘assign 10 to n’, more like C’s goto), etc…