Hahaha, ok I'm already cracking myself up with this title because, really, who likes debugging and debugging in fortran nonetheless? The title is definitely a misnomer but it's a reality that as a graduate student in earth science (and likely other fields) at some point in time you're going to have to debug something written in Fortran.  

And this is not to say that Fortran is bad, Fortran remains an incredibly popular language (for good reasons!) in the sciences despite it's perceived character as an ancient language.  But this post isn't to defend why scientist's continue to use fortran - for that read : "Why physicists still use Fortran".  

Here I'm just going to pass on a few of the lessons I've learned fighting with Fortran for the last several years.

1. Make sure it compiled correctly
The first thing you're going to need to do when someone gives you a Fortran script is get it compiled.  This can be a daunting task that takes hours, days, weeks even! Thus once you're over the hurdle pat yourself on the back - that's a job well done.  My most common issues getting programs to compile is building codes in the wrong architecture.  There is no easy way around this that I've found.  Usually a combination of different Fortran compiles (try f77, g77, gfortran) and different flags will eventually get the job done.  I've had good luck with the -arch flag in gfortran which allows you to try and force a given architecture when building a program.  

Another good practice is to copy your original makefile to another file name.  If you're anything like me, somewhere down the line (whether it be a few days later or years later) you're going to wish you had the original version to go back to.  To that end, you can actually name your makefiles something other than makefile! To use a different makefile when compiling rather than the default "makefile", just use the command : make -f examplemakefile.  In our group we've found it useful to keep copies of everyone's different makefiles, we just append our names after the file.  This way we can reference each other's different attempts (or different versions of our own attempts) when slogging through complicated compilation attempts.

I've also found it useful to remove all object files (*.o files) in a given directory when I'm re-compiling programs.  These *.o files commonly will be left-over from a previous compilation attempt and may retain old parameters that may cause an otherwise correct makefile to fail. An easy way remove these is the simple command: make clean.  

Last thing, remember this phrase "warnings are warnings, but errors are errors".  If you compile your program and a bunch of warnings are spit out don't be afraid! Likely your attempt was successful and the program is correctly compiled.  Now, this is not true if an error occurred.  Hence, errors are errors and need to be dealt with to get your program compiled.  

2. Google your error codes
This may sound obvious but this has to be your first go to.  Run a program and have it break midway through? It's going to spit out an error and as long as it's not a segmentation fault, you'll likely be able to triage it with a few well versed google searches.  Now with renewed confidence following your successful googling, you're likely going to have to dig into the actual fortran program which leads me to my next piece of advice ...

3. Don't be afraid to dig in
Now take a big breath and keep calm, you're going to need to dig into your Fortran program. When I wast first interacting with Fortran this scared the shoestrings out of me. Just think, you've spent all of this time getting your program compiled and now you need to open it and maybe even modify it? No, no no, no no no.  But what are you going to do? Having it not work is rarely an option.

First off, you may not even need to modify the script.  Most of the time fortran scripts will fail on me because the script can't find a file it's looking for.  In these cases you will need to get your program into a text editor to find the line that points to the file that is missing but at least you're not modifying things ... yet.  

But say some other error is occurring, the numbers being output don't look correct, variables aren't getting assigned, files are coming out in binary and you need them in ascii - this is the time to start modifying the script.  Now full disclaimer here, I have not gone too far into Fortran modifications - most of my solutions are to get variables printed to the screen or to dummy files to check their values and then debug from there.  I also use a healthy number of "Hello World" type commands to find where a script is getting stuck.  And if after all of this you still can't get the program to work move on to step #4.  

4. Ask for help!
Last, but definitely not least, don't be afraid to ask for help! You tried googling the error code for a while and got nowhere? Ask someone for help.  Spent an entire day trying to get a specific program compiled? Ask for help. I can almost 100% assure you that other people have run into the exact issue you're having trouble with and as long you've done your due diligence in trying to solve it yourself, people don't mind helping you.  Hey, they were likely asking the same question too one upon a time.

Ok, that does it for my limited amount of advice for Fortran.  For me the biggest piece of advice is to try and not get frustrated. Attempt to fix the problems yourself and be willing to edit the code but don't be afraid to ask for help. And above all else, backup your work! Right now, go home, and backup!

Until next time, in life as in Fortran, don't be afraid to dig in ;)