Mentioned in questions and answers.

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 90, 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 the Sun/HP/IBM compilers)

So I'm thinking of imposing stuff that is widely 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 and 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, re-usability 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 URLs, advice, reference paper/books on this subject?

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.

In the book Fortran 95/2003 for Scientists and Engineers, there is much talk given to the importance of recognizing that the first column in a format statement is reserved for control characters. I've also seen control characters referred to as carriage control on the internet.

To avoid confusion, by control characters, I refer to the characters "1, a blank (i.e. \s), 0, and +" as having an effect on the vertical spacing of output when placed in the first column (character) of a FORMAT statement.

Also, see this text-only web page written entirely in fixed-width typeface : Fortran carriage-control (because nothing screams accuracy and antiquity better than prose in monospaced font). I found this page and others like it to be not quite clear.

According to Fortran 95/2003 for Scientists and Engineers, failure to recall that the first column is reserved for carriage control can lead to horrible unintended output. Paraphrasing Dave Barry, type the wrong character, and nuclear missiles get fired at Norway.

However, when I attempt to adhere to this stern warning, I find that gfortran has no idea what I'm talking about.

Allow me to illustrate my point with some example code. I am trying to print out the number Pi:

PROGRAM test_format
IMPLICIT NONE

REAL :: PI = 2 * ACOS(0.0)

WRITE (*, 100) PI
WRITE (*, 200) PI
WRITE (*, 300) PI
100 FORMAT ('1', "New page: ", F11.9)
200 FORMAT (' ', "Single Space: ", F11.9)
300 FORMAT ('0', "Double Space: ", F11.9)
END PROGRAM test_format

This is the output:

1New page: 3.141592741
Single Space: 3.141592741
0Double Space: 3.141592741

The "1" and "0" are not typos. It appears that gfortran is completely ignoring the control character column.

My question, then, is this:

Are control characters still implemented in standards compliant compilers or is gfortran simply not standards compliant?

For clarity, here is the output of my gfortran -v

Using built-in specs. Target: powerpc-apple-darwin9 Configured with: ../gcc-4.4.0/configure --prefix=/sw --prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib --build=powerpc-apple-darwin9 --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9 Thread model: posix gcc version 4.4.0 (GCC)

In years past, ignoring this use of the first column could cause bad things on a line printer, like page ejects -- but when was the last time that you saw a line printer? Otherwise it was output device, compiler and OS dependent. The advice of "Fortran 95/2003 for Scientists and Engineers" was excellent for about 15 or 20 years ago. With terminals, postscript and other modern printers, column one isn't special any more. I don't pay special attention to column one anymore and I haven't gotten into trouble.

The Fortran 2003 standard lists carriage control as deleted, which is something that the Fortran language standards rarely do. See page 359 of "Fortran 95/2003 explained" or page 326 of "The Fortran 2003 Handbook". Perhaps selecting -std=f2003 or -std=f2008 with gfortran will guarantee that column 1 won't be used a carriage control so that "bad things" are completely impossible.

I'm working on a model written in Fortran 95, which I am completely new to. The concept of statement labels seems strange, and I've so far only found the explanation that the labels can be arbitrarily decided by the author, usually incrementing by 10's.

Are there any practical uses of these labels, other than picking out more easily where a statement is ending? AND a generally accepted standard on how to label.

The only way I can think of statement labels being useful in modern Fortran is for error control when using gotos (yes, they can be useful sometimes - when handled with care ;-)). Chapman lists them under "obsolescent".

Construct names, on the other hand, might be useful sometimes to help the reader understand your code e.g. for large loops or if statements. Another use for construct names is advanced loop control, e.g. when cycling an outer loop:

outer: do i=1,10
  do ii=1,10
    if ( i == 2 .and. ii == 3 ) cycle outer
    z(ii,i) = 1.d0
  enddo
enddo outer

I have just got a job, starting in a months time which requires me to use fortran.

I have brought a couple of books, but they seem to lack any questions or problems and that is how i learn best.

I would like to know if you could recommend and books or websites that offer problems that i could practise with.

Thanks

I can recommend several, depending on your previous programming in general knowledge and Fortran specific knowledge.

For an absolute beginner (and don't take this in a negative context; it just means you're starting anew, and unlike someone who has a habit of some bad Fortran77 practices, you'll start with a clean mindset) I would definitely go with Chapman's Fortran 95/2003 for Scientists & Engineers. It is an excellent learning book, and although it has some drawbacks they're not important at this stage. It also has a plethora of examples useful in real life. It also emphasises good modern Fortran concepts and ideas (Fortran 90 and newer).

After it, or maybe instead of it, if you're looking for more of a reference book one cannot recommend enough one of the following:
- Metcalf, Reid and Cohen's Fortran 95/2003 Explained (btw, a new edition covering the latest Fortran standard is coming up in a few days) - a classical reference book. Some swear by it instead of Chapman's.
- The Fortran 2003 Handbook: The Complete Syntax, Features and Procedures by several authors; a standard reference book, dealing with the finer aspects of the language. Not important at this stage but just so you know it's there.

Apart from these, which I like to call "the big three", there are numerous tutorials, scriptas and handbooks all over the web (free) and on Amazon. Some links were given in here as well, so I won't repeat those. Also, your compiler is bound to have a good reference manual I don't know about the free g* ones, but all commercial ones do.)

Apart from that, you know you can always ask any question that comes to your mind in here, and on comp.lang.fortran (usenet group; google for a "Usenet client" or "newsclient" and check it out.). Some very(!) knowledgeable people lurk in there.

I see that Fortran has 'call' and 'include' statements. what is the difference between the two? Does the .i filetype have some significance?

i.e:

include 'somefile.i'
call 'somesubroutine.f'

Thanks!

INCLUDE statement lets you include source from some other file, as if it was in the file in which the statement is located. Its usefulness in organizing code is somewhat dubious, but some swear by it. In F77 it was a common extension (from MIL-STD 1971, I believe), in F90 it made it into the Standard. Filetypes have no significance. As the matter of fact, in fortran most filetypes (even the more common ones as f77, f90 and such) have no significance. Most compilers merely use them to automatically "detect" and differentiate free form from fixed form source code, but they also allow for other.

CALL statement is used for calling subroutines. It is of the form CALL subroutine_name(list-of-arguments). Subroutines are one of the more simple ways of structuring and dividing your program into logical sub-units.

But this is all relatively basic, and covered in every Fortran tutorial out there. Some are better, some are worse. A few good starting points for learners would be the Wikipedia page (not perfect, but not that bad either), FortranWiki and two books. One IRO-bot already mentioned, other would be Chapman's Fortran 95/2003 for scientists and engineers. It is generally considered more suitable for beginners, having an easy going approach and a plethora of practical examples, while Metcalf is aiming to be more of a reference book as well.