(under construction — stay tuned)
Often, the most time consuming part of programming is not writing the code but figuring why it’s not working correctly and then fixing it.
A corollary to the above is that many programs aren’t working correctly even when they superficially appear to be running without errors! You should always assume that a program you have written to perform computations or to analyze a dataset is giving incorrect results until you have proven otherwise.
Sometimes, the best way to do this is to run the program on a smaller or simpler case for which which the answer is known. For example, if you’re calculating emitted radiances by an arbitrary atmosphere, you might want to test your calculation on an isothermal atmosphere for which the brightness temperature should equal the actual temperature.
Other times, your only option might be to examine intermediate results at various points in the program and verify to your own satisfaction that they are consistent with the data and lines of code that preceded them. One way to do this is to insert temporary print statements at strategic points in the code to display the values of intermediate variables or calculations.
Another way is to use a source-level debugger that lets you manually step through a compile program and examine the results of various operations. I would say that the vast majority of inexperienced programmers aren’t even aware debuggers exist, let alone how powerful they can be for troubleshooting questionable code.
Under most Unix/Linux-like operating systems, including Mac OS X, ‘gdb’ is the command line debugger that is most likely to be available. The standard way to use it is to supply the -g option when compiling a C or Fortran program and then invoking gdb on the resulting executable:
gcc -g -o myprog myprog.c gdb myprog
On Macs, it has been my experience that the free Fortran compiler gfortran does not generate debuggable executables even when the -g option supplied. So I have only had success debugging Fortran programs compiled with the commercial ifort compiler:
ifort -g -o myprog myprog.f90 gdb myprog
Using the command line version of gdb can also be a bit tedious, especially before you are very familiar with the commands. Consequently, I strongly recommend the GUI-based front end for gdb called ddd. It can be installed on Macs via the fink package:
fink install ddd
Depending on what’s already on your Mac, it may need to install a lot of other packages on which ddd depends. You then run it as follows:
The Intel package that includes ifort also has its own debugger that is similar to gdb but which presumably has even more functionality. It is called idb. But for it to work under Mac OS X 10.7 (Lion), you have to add some options when compiling with ifort:
ifort -g -save-temps -fpic -Wl,-no_pie -o myprog myprog.f90 idb myprog
You can use the GUI-based ddd with idb as follows:
ddd --debugger /usr/bin/idb myprog
provided that you substitute the correct path to idb for /usr/bin/idb in the above, if necessary.