Tuesday, November 28, 2006

More on modern Fortran

From the echo on my earlier post about why we use Fortran for number crunching applications, I gather that many people still associate Fortran with the worst features of the now mostly obsolete FORTRAN 77 standard (fixed source form, implicit typing) and are mostly unaware of the great strides the development of the Fortran standard has made in the past 30 (sic!) years. So I feel that this might be a good opportunity to talk a little about the advanced features that make Fortran 95 so convenient for developping computational physics applications. [Note that in the following Fortran 95 will be referred to simply as "Fortran" for the sake of brevity.]

To start with, there are Fortran's superior array features which greatly facilitate working with vectors, matrices and tensors: Being able to write vector addition as

a = b + c

instead of some kind of for-loop is a great boon in terms of code legibility. Having the sum, product, dot_product and matmul intrinsic functions available to perform common mathematical operations on arrays using a (hopefully) efficient vendor-supplied math library also helps.

But where Fortran's array features really shine is when it comes to defining elemental functions and subroutines, which save a huge amount of coding. An elemental function or subroutine is one which is defined with scalar dummy arguments, but which fulfils certain technical conditions that allow it to be called with an array passed as the actual argument. When called in this way, an elemental function is evaluated on each element of the passed array argument, and the results are assembled into an array of the same shape. Most of the mathematical functions Fortran provides as intrinsics are elemental. So one can do something like

Pi = 4.*atan(1.)
x = (/ (i*Pi/n,i=0,n) /) ! array constructor with implied do-loop
y = sin(x) ! an elemental assignment operation

to load y(i) with sin(x(i)) for all i. And better yet, user-defined functions can also be elementary, so you only ever need to write the overloaded operators for your automatically-differentiating spinor type as scalars, and Fortran will take care of dealing with the arrays of those spinors that occur in your code.

Next in usefulness and importance comes the already mentioned support for overloading operators and intrinsic functions on user-defined types. Again, this provides a lot of convenience in terms of maintaining a coding style that stays as close to standard mathematical notation as possible, and of keeping the gory details of complex type operations (such as multiplying two automatically-differentiating spinors) transparent to the programmer/user on the next higher level. The ability to have public and private procedures and variables in modules also helps with this kind of encapsulation.

And that isn't all: namelist I/O provides a cheap kind of configuration files; selected_int_kind and selected_real_kind allow testing whether the system provides sufficient range/precision at compile time; the forall construct allows some measure of parallelization on parallel processors where the compiler supports it.

The next incarnation of the Fortran standard, Fortran 2003, exists only as a standard document at this time, although compiler vendors are beginning to add features from Fortran 2003 to their compilers in a piecewise fashion. Major new features include object orientation (single inheritance, polymorphism and deferred binding) and C interoperability (so you can call C system libraries from Fortran programs, and/or call your Fortran matrix-crunching code from a C application).

And after that, the future Fortran 2008 standard is expected to include co-arrays to support parallel and distributed computing, a bitfield type, a Fortran-specific macro preprocessor, among other things.

Advanced programmers keen to learn about Fortran 2003's new features may want to have a look at the Fortran 95/2003 book by Cohen, Metcalf and Reid. This is the successor to Metcalf and Reid's Fortran 90/95 book, which is still probably the best reference to modern Fortran, as most of the Fortran 2003 features aren't available on most platforms yet, whereas standard Fortran 95 is very portable.

For beginning programmers, or people who have never worked with any flavour of Fortran before, the book by Chapman (which I haven't read personally) may be a better idea from the reviews I've seen, but the reviews also indicate that it is not useful as a reference, so you may have to get the Metcalf et.al. book(s) anyway.

Lattice 2006 proceedings available

The proceedings for the Lattice 2006 conference are now available at Proceedings of Science, so you can read the written versions of the talks and get your own idea about most of what was being said and discussed in Tucson, if you weren't there, except for all the bits that had to be left out due to the fairly strict (for an online publication) page limits.

Wednesday, November 22, 2006

One year on the lattice

I just noticed that I let our first anniversary as the world's first and only lattice QCD group blog slip by unnoticed last week. Yes, it has been over a year now since I joined the blogosphere and took over the role of Lead Contributor to "Life on the Lattice" from Matt!
So far, I have thoroughly enjoyed the experience, and I would not hesitate to suggest it to any other lattice field theorist (or any other kind of physicist) who might be thinking about ways to connect to a wider audience.

Tuesday, November 21, 2006

Lattice Forecast for 2056

Via Cosmic Variance and BioCurious: New Scientist has some well-known scientist forecast where science will be in 50 years.

A lot of the predictions are of the kind that people made 50 years ago for today: AIs more intelligent than people, permanent colonies on other planets, immortality drugs, contact with alien civilisations. They haven't come true in the past 50 years, and (exponential growth laws notwithstanding) I see no reason why they should come true in the next 50 years. The other kind of prediction seems much more likely to come true: detection of gravity waves, important discoveries at the LHC, significant progress in neuroscience, solutions for all of the Millennium problems, a firm understanding of dark matter and dark energy, a means to grow human organs in vitro, working quantum computers. And of course, just like nobody 50 years ago predicted the internet or the role of mobile phones in today's world, we should really expect that something completely unexpected will become the leading technology in 50 years.

What really irks me, though, is that there is no forecast from a lattice field theorist. After all, lattice QCD has made huge progress over the past decade, but apparently it isn't sexy enough for New Scientist these days. So here I am going to contribute my own 50-year forecast:

Over the next few decades, parallel computing will make huge advances, with machines that make today's TOP500 look feeble by comparison becoming readily affordable even to smaller academic institutions. As a consequence, large-scale simulations using dynamical chiral fermions will become feasible and will once and for all lay to rest any remaining scepticism regarding the reliability of lattice simulation results.

Predictions of "gold-plated" quantities will achieve accuracies of better than 0.1%, outshining the precision of the experimental results. If the limits of the Standard Model are at all accessible, discrepancies between accurate lattice predictions and experimental results in the heavy quark sector will be a very likely mode of discovering these limits, and will hint at what comes beyond. The use of lattice QCD simulations of nuclear structure and processes will become commonplace, providing a first principles foundation for nuclear physics and largely replacing the nuclear models used today.

On the theoretical side, the discovery of an exact gauge dual to quantum gravity will allow the study of quantum gravity using Monte Carlo simulations of lattice gauge theory, leading to significant quantitative insights into the earliest moments of the universe and the nature of black holes.

Thursday, November 09, 2006

Lisa Randall online chat

At the request of Coco Ballantyne of Discover Magazine, here's a link to the online chat with Lisa Randall hosted by discover magazine today at 14:00 EST. Personally, I won't be joining the chat since I don't believe I have anything pertinent to say about warped extra dimensions (in fact, I doubt I even know enough to ask a relevant question), but some readers of this blog might be interested in chatting with a rather famous physicist about her research and her efforts to popularise modern physics ideas.

Thursday, November 02, 2006

Why we use Fortran and Python

From Mark Chu-Carroll, a post on why C/C++ aren't always fastest, which is of course well known in (large parts of) the scientific computing community: Fortran compilers can perform much better optimisation than C compilers, because Fortran has true arrays and loop constructs, as opposed to C's sugar-coated assembler. C is a great language to develop an operating system or a device driver, but not to write computationally intensive code that could benefit from parallelisation, where Fortran beats it easily. And what about C++? The object-oriented features of C++ are nice for scientific applications, sure; you can have matrix, vector and spinor types with overloaded operators and such. But Fortran 95 has those things, too, but doesn't suffer from the problems that C++'s C-heritage brings. And Fortran 95 has even nicer features, such as elemental functions; that's something that no C-based language can give you because of C's poor support for arrays. And in case there is some object-oriented feature that you feel is missing in Fortran 95, just wait for Fortran 2003, which includes those as well.

But what about developing graphical user interfaces? Fortran doesn't have good support for those, now, does it? No, it doesn't, but that's besides the point; Fortran ("FORmula TRANslation") is meant as a number-crunching language. I wouldn't want to write a graphical user interface for my code in either Fortran or C/C++. For these kinds of tasks, I use Python, because it is the most convenient language for them; the user interface is not computationally intensive, so speed isn't crucial, and for the number crunching, the front end calls the fast Fortran program, getting you the best of both worlds -- and without using any C anywhere (other than the fact that the Python interpreter, and probably the Fortran compiler, were written in C, which is the right language for those kinds of tasks).

Most lattice people I have personally worked with use Fortran, and a few use Python for non-numerical tasks. Of course there are large groups that use C or C++ exclusively, and depending on what they are doing, it may make sense, especially if there is legacy C or assembly code that needs to be linked with. But by and large, computational physicists are Fortran users -- not because they are boring old guys, but because they are too smart to fall for the traps that the cool C++ kids run into. (Oh, and did I mention that Fortran 95 code is a lot easier to read and debug than C++ code? I have debugged both, and the difference is something like an hour versus a day to find a well-hidden off-by-one bug.)