Writing fortran robust and "modern" code

Question

In some scientific environments, you often cannot go without FORTRAN as most of the developers only know that idiom, and there is lot of legacy code and related experience. And frankly, there are not many other cross-platform options for high performance programming ( C++ would do the task, but the syntax, zero-starting arrays, and pointers are not compatible with some people ).

So, let's assume a new project must use FORTRAN (F90), but I want to build the most modern software architecture out of it. while being compatible with most "recent" compilers (intel ifort, but also including sun/HP/IBM own compilers)

So I'm thinking of imposing stuff that is wildely known as common good sense, but not yet a standard in my environment:

• global variable forbidden, no gotos, no jump labels, "implicit none", etc.
• "object-oriented programming" (modules with datatypes + related subroutines)
• modular/reusable functions, well documented, reusable libraries
• assertions/preconditions/invariants (implemented using preprocessor statements)
• unit tests for all (most) subroutines and "objects"
• an intense "debug mode" (#ifdef DEBUG) with more checks and all possible Intel compiler checks possible (array bounds, subroutine interfaces, etc.)
• uniform and enforced legible coding style, using code processing tool helpers.

The goal with all that is to have trustworthy, maintainable and modular code. Whereas, in lot of legacy codes, reusability was not a important target.

I searched around for references about object-oriented fortran, programming-by-contract (assertions/preconditions/etc.), and found only ugly and outdated documents, syntaxes and papers done by people with no large-scale project involvement, and dead projects.

Any good URL, advice, reference paper/books on the subject?

Answer 1

Fortran 90/95/2003 is designed so that one can write modular code, if one wants to, via addition of modules, private/public, user defined types, etc. Fortran 2003 introduces further object oriented features. It makes no sense to connect to C to add malloc when Fortran 90 has "allocate" to directly dynamically allocate Fortran arrays in a safer way. Placing your procedures (functions and subroutines) in modules and then "using" the modules will cause the interfaces to be checked. One can use the many debug / checking options of the compilers, such as subscript bounds checking.

An excellent book to learn about these and other features: "Fortran 95/2003 Explained" by Metcalf, Reid and Cohen. It is definitely a good idea to learn the best features of modern Fortran rather than continuing to write FORTRAN 77 -- if necessary, write coding standards / guide.

Answer 2

My 5 cents.

The Fortran Wiki is a good starting point. It has articles about different aspects of programming using modern Fortran. Unit testing, debugging, generic programming, etc. Also very interesting table on Compiler Support for the Fortran 2003 Standard is available. (As Blklight already mentioned some 2003 features are not available in compilers. It's good place to compare different compilers.)

I'm a C++ guy but I'm stuck with some F90 projects.

I recommend to read this course: Introduction to Modern Fortran. M. S. B. mentioned famous "Fortran 95/2003 Explained" but this book is big enough and full of details. The course mentioned above on the contrary is a good place to start. Also take a look at An Interactive Fortran 90 Programming Course from University of Liverpool.

Mistakes in Fortran 90 Programs That Might Surprise You. This page title speaks for itself. =)

Hmmm... I also have in my bookmarks some link to PSTI RESEARCH LECTURE SERIES "SCIENTIFIC COMPUTING WITH FORTRAN 95". Give it a try.

J.F. Sebastian mentioned F2Py and give the advice to teach Python. I subscribe to his opinion. Python is not my favorite language. But it useful enough to teach it. In adition to already mentioned preprocessors (many of which written in Python) and F2Py don't pass up SCons - modern software construction tool.

P.S. The last week I bought an e-book at lulu.com. Scientific Software Development in Fortran by Drew McCormack. I hope it to be good reading but suddenly have no time. The author is the developer of Forpedo (one of Fortran-specific preprocessors mentioned in Fortran Wiki) and author of many books and tutorials on Objective-C and Python programming.

Answer 3

I suggest that OP drops the attitude that Fortran is something nasty to be endured in high-performance scientific computing and dives into it enthusiastically. If OP retains that rather dismissive mindset then his/her entire Fortran coding career is going to be a struggle. And really, there's nothing you can do with Fortran that you can't do with C++ so why bother if you really don't want to ?

There is nothing in OP's list of bullets that a lot of us who have been working with Fortran for the last 30 years haven't been doing (since the widespread availability of Fortran 90 compilers but some of it before then too). Yes, there are computational scientists, and scientific software engineers, who understand pointers, know that a lot of (misguided) people start counting at 0 and that global variables are A BAD THING.

Like @MSB I'd recommend Metcalf et al's book as a source of information on the capabilities and features of modern Fortran. And, like @MSB, I raise an eyebrow at the idea of using C or C++ to wrap libraries for which there are either Fortran equivalents or better approaches entirely. The 2003 standard's interoperability with C features, which are implemented in Intel Fortran, make it easier than ever to call C libraries directly.

I'd take issue with OP that having modular code is a goal in its own right. The goals are, I suggest, correct, verifiable and validatable, robust, reliable code. Modularity is one way of supporting the achievement of those goals but it's a tactic, not an end point. If I thought that we could write good (in the foregoing senses) programs comprising 10^6 lines of code without modularity, I wouldn't bother with modularity.

OK, now some concrete tips to add to what OP already intends to do or has been told:

• use KINDs on variable declarations to enforce the precision you require; don't leave this to compiler options or guesses about what this compiler might do on that processor;
• use array operations wherever possible rather than explicit loops; this helps to make code safer -- sometimes at the expense of performance but you need to check this on a case-by-case basis;
• write PURE functions;
• don't depend on pre-processors or other non-Fortran approaches to code correctness (etc), write your assertions and preconditions (etc) in Fortran; the pre-processors (etc) will not survive as long as well-written Fortran programs and will be a major barrier to portability now and in the future;
• if you have access to Intel Fortran get access to Intel MKL (and IPP) and use those libraries rather than writing your own code;
• plan to tackle OpenMP and MPI for parallelisation, they both fit Fortran very well; oh, and plan to go parallel as soon as possible, it's a lot more fun than serial programming;
• this set of Fortran Coding Standards is a good start, but probably no more than that; the 1st edition of Code Complete had a lot more about Fortran (77) programming than the current edition, but most of its advice can be applied whatever language you write in.

And, finally, these days I think that Fortran programs and programmers are better informed by ideas from functional programming than ideas from object-oriented programming.

Answer 4

I'm in a rather hurry, so forgive me if I'm making this answer in the form of checkpoints instead of reasonable sentences.

• try adhering to the standard (Fortran is a standardized language, and by adhering to standard language features, and avoiding vendor specific extensions, you'll have a portable between platforms program, for which you can be sure the compiler will give no problems). I don't know where I downloaded my copy, but I'm pretty sure you can download the latest draft (beware; many features of fortran 2008 or 2003 for that matter are still not implemented in the currect compiler, although many are almost there nowadays ... Cray being one) from J3's page
• for all questions regarding the above, I heartily recommend comp.lang.fortran usenet group - not only does it have some very knowledgeable people there (for example. mr. Richard Maine ... will probably be willing to answer any standard compliance questions you may ask, with much detail, if asked nicely ... same goes for many others) but it also has people who've worked on large scale problems and will certanly know and be willing to give advice on your subject
• books - in addition to all of the already mentioned (Metcalf, Reid and Cohen's book also has my recommendation, also "Fortran 2003 handbook" by Maine and others ...), try finding yourself a copy of Stephen J. Chapman's "Fortran 95/2003 for scientists and engineers" ... takes a little too confident stand on some topics, but still, overall a very nice book, with many "good programming practices" mentioned)
• also, don't know if you've comed across this one "Object oriented programming via Fortran 90/95"

---

Some comments on your text:

( This may all seem "evident" modern programming assumptions, but in a legacy fortran world, most of these are big changes in the typical programmer workflow )

Even in a modern fortran world, some of these assumptions are questionable ... remember, fortran programmers are not programmers (I'm repeating this in condensed form; I've already written this on this forum so many times) but engineers, scientists and so on. To them (us?) code is not a goal, but merely a tool ... to professional programmers code is everything; they have nothing "beyond it" ... therefore, they cherish it so much. To us engineers, it is merely a means of getting the result we want ... with that in mind, although good programming practices pay later, do not necessary insist on them where there is no obvious need for them.

The goal with all that is to have trustworthy, maintainable and modular code. Whereas, in typical fortran, modularity is often not a primary goal, and code is trustworthy only if the original developer was very clever, and the code was not changed since then ! (i'm a bit joking here, but not much)

Somebody once said, and you wouldn't believe how true it is:
"There is nothing more permanent than a temporary fix".

Any good URL, advice, reference paper/books on the subject?

Given several above.

Also, while writing this answer, I see High Perf. Mark posted a very nice answer, with which I mostly agree ... it goes a little more into detail about standard adhering.

Also, my recommendation would be to definitely post this question also on comp.lang.fortran ... I gather you can get much more quality answers there, then in here (I believe there isn't more then 20 or so fortran programmers on whole of stackoverflow).

There was a set of code writing guidelines published freely by some european union commitee; they would be very useful as part of this answer, but unfortunatelly, I cannot find them in my quick google search, and haven't got the time to look extensively. Try searching on the topic ... maybe you'll have better luck.