In this file we list some of the techniques that may be used to increase one's efficiency when developing PETSc application codes. We have learned to use these techniques ourselves, and they have improved our efficiency tremendously.

Editing and Compiling

The biggest time sink in code development is generally the cycle of EDIT-COMPILE-LINK-RUN. We often see users working in a single window with a cycle such as:

In addition, during this process the user often moves manually among different directories for editing, compiling, and running.

Several easy ways to improve the cycle:

Admittedly, it takes a while to get the hang of using emacs. But we've found that the increase in our programming efficiency has been well worth the time spent learning to use this editor. We seriously believe that we could not have developed PETSc as it is today if we had not switched to emacs.

vi and Eclipse also provide tools for quickly finding things and searching in PETSc source code, see the Emacs, VI/Vim and Eclipse sections of the users manual. GNU Global is a richer alternative to etags, see the user's manual for more details.


Most code development for PETSc codes should be done on one processor; hence, using a standard debugger such as dbx, gdb, xdbx, etc. is fine. For debugging parallel runs we suggest Totalview if it is available on your machine. Otherwise, you can run each process in a separate debugger; this is not the same as using a parallel debugger, but in most cases it is not so bad. The PETSc run-time options -start_in_debugger [-display xdisplay:0] will open separate windows and debuggers for each process. You should debug using the debugging versions of the libraries (run ./configure with the additional option --with-debugging (the default)).

It really pays to learn how to use a debugger; you will end up writing more interesting and far more ambitious codes once it is easy for you to track down problems in the codes.

Other suggestions

Fortran notes

Since Fortran77 does not provide type checking of routine input/output parameters, we find that many errors encountered within PETSc Fortran77 programs result from accidentally using incorrect calling sequences. Thus, if your Fortran program is crashing, one of the first things to check is that all subroutines are being called with the correct arguments.

When passing floating point numbers into Fortran subroutines, always make sure you have them marked as double precision (e.g., pass in 10.d0 instead of 10.0). Otherwise, the compiler interprets the input as a single precision number, which can cause crashes or other mysterious problems. Make sure to declare all variables (do not use the implicit feature of Fortran). In fact, we highly recommend using the implicit none option at the begining of each Fortran subroutine you write.

Fortran 90 provides the ability to do some type checking of subroutine calls by using Fortran 90 interfaces or modules. PETSc now provides interfaces and modules for Fortran 90; see the manual page for how to use them.