Posted by a.hay on 10 October 2014 - 5:00pm

By Leanne Mary Wake, 2014 Fellow and Anniversary Research Fellow, Department of Geography, University of Northumbria.

The instructor heartened me when he kicked off the Introduction to F95 workshop, which took place at the Culham Centre for Fusion Energy on August 18th-19th, by saying "we want software engineers, not hackers." Science has reached a point where we produce and manipulate ever larger datasets, yet amongst the short-of-time and short-of-patience there is a temptation to produce code more with survival than sophistication in mind. This comes down to a clash between code that works versus code that works again, which is part of the Software Sustainability Institute’s mission and something which I will bring into my teaching from now on.

Immediately, I reflected on some of the less-then-useful code I had written in the past, along with my own learning experience as an undergraduate. Words such as ALLOCATION, SUBROUTINES, MODULES and FUNCTIONS, the latter, which has never been a characteristic of my writing, were mostly absent from my training as an undergraduate. Here are some others - PORTABILITY and GENERALISATION. These are not commands, but two virtues of a code produced by a software engineer as opposed to a hacker. Before I proceed, I make no apologies for using metaphors from Star Wars - it was on my mind at the time of writing - to highlight some of the learning outcomes of the workshop that I intend to use as pillars of my own teaching material and which, funnily enough, align themselves with the sustainability mantra.

"Your father fought in the code wars"

PORTABILITY. Why write the same code over and over again? There are ways to write the code so that the computer/hacker work ratio is 95:5 rather than 70:30 in which the latter is usually caused by direct ALLOCATION of features such as matrix sizes, which may vary, input file names and so on. Writing a portable code will limit the amount of manipulation by hand that is done prior to computation, which is essential to reproducibility and sustainability. However, as an undergraduate I was assessed as follows: as long as the correct answer comes from the input - you pass. Less emphasis was placed on steering the learners towards eloquent coding. Thankfully, the opposite was a feature of this workshop.

"Good. I can feel your anger"

I am guilty of christening my codes with less-than-useful names. Please name codes something sensible. fudgesticks.f90 (I’m censoring myself here) is much less useful compared to circlearea.f90.  It also stops you building up a clone army of codes which all do the same thing but have different names reflecting the mood of the coder at the time. Keep these super-useful codes as SUBROUTINES/FUNCTIONS

"Hokey religions and ancient weapons are no match for a good blaster"

This is related more to READABILITY of a code and is prevalent in many a FORTRAN code I have encountered. The parallel to Han Solo’s blaster here is the GOTO statement. It’s a quick and easy get-out statement that stops a loop dead in its tracks and jumps somewhere else. Not a good thing to have when you have a 30 page print out of code looping over several dimensions that you are reading for the first time. WHILE and IF are more reader-friendly. I’m pleased to say that there are few practitioners of GOTO, and it wasn’t taught at the workshop. It also wasn’t mentioned in the 80 pages of course guidance and won’t be mentioned in mine, either.

"My name is C3PO, I am fluent in over six million forms of communication."

I bet one of those doesn’t include FORTRAN error messages. One element I would say is missing from the course (and indeed most courses) is a Google translate-type database of the error messages FORTRAN spews out. Most are non-intuitive to non-mathematicians and engineers. I imagine this was the reason I heard a lot of “I don’t know what I am doing wrong”. No, and unless you are C3PO with a built in FORTRAN snark library, you intuitively won’t. My Top 5 language-mindbenders, experienced from my undergraduate days until present, along with my translation, are the following:

1. Segmentation Fault

Sadly, not one of Alan Partridge’s cut-price Terry’s chocolate oranges. You’ve told the code to expect to read in ten numbers from a file, sequentially. But the file contains less than ten. “Not enough numbers, sunshine” is more appropriate. This is where FORTRAN could learn from MATLAB. A similar error produces the warning “Index exceeds matrix dimensions” or ”Attempted to access temperature(1701,2) but size(temperature)=1700,2.” Key word: ALLOCATION

2. Incorrect/Missing Argument

Simply an input to a built-in function in FORTRAN. For example, to calculate the area of a triangle, you must provide both base length and height. These are ‘arguments’. Missing one of these results in the return of this confrontational-sounding error message to your terminal screen.

3. Floating Point, Integers, Reals, Rounding Errors…

Integer and reals are intuitive to most people, but what on Earth is a floating point error? Rather than trying to explain this myself in this short space, I found a really cool resource that explains these errors clearly and without computer speak.

However, errors in the above, such as when numbers are rounded to infinity and zero and are passed through the program, are manifested usually with the following error message:

4. ‘                    ‘

The worst and most mysterious of them all: NOTHING. The terminal screen says nothing, you’ve had no complaints from the program but you just KNOW something didn’t go right as the code ran too quickly. You investigate the output file and see INF as far as the eye can see. Inclusions of IF statements, IOSTAT and IERR warnings can greatly increase your chances of guessing what’s wrong with your output. A tool I largely ignored at first and will promote the use of in my classes – if anything, to save me pain when assessing work.

5. IMPLICIT NONE

Like when Luke finds out that Vader is his father, I had a similar life affirming epiphany at the workshop. I had never been taught why we insert IMPLICIT NONE at the head of a FORTRAN program. It prevents FORTRAN from turning any variables you have christened with a name beginning with a letter between I and N into integers. This might not sound mind blowing, but the course exercises demonstrated quite clearly what happens if you mis-declare a real number - a number with decimal places 10.001 = as an integer (no decimal place: 10). The moral here is to not treat the students, whatever their backgrounds, as idiots. Instead, explain the reasoning behind the statements in a program, no matter how wacky their meaning.

If there is a single thing I will take from the workshop to aid teaching of all kinds of software – not just FORTRAN – it will be a thorough crash course in error messages, or like the workshop, creating an environment where beginners are not afraid to ask for help with simple errors. Creating a resource like The Floating Point Guide for FORTRAN would be a good starting point.