Next: , Previous: Subprogram modification, Up: Customized Coding


5.5 Creating your own Subprograms

The next step in interacting with the SPA is to release yourself from the limitation of using only subprograms provided with the archive. For example, let's say that you've just come up with the latest and greatest atmospheric variable of all time and decided to call it foo. But of course the SPA doesn't know all about your brilliant insight, so you need to teach it how to compute foo. For simplicity, we'll assume that the calculation of foo requires only the temperature field, so that all of the basic modifications are identical to those outlined in the interfacing section (see Subprogram interfaces). (We can, of course, skip the step involving the use-association of the thermodynamics module if we wish since our new subprogram will exist locally.)

Instead of calling the tttopt function, we'll call the foo function for our calculation. This will look something like: pt = foo(tt,dim). (Note that we're now storing our precious foo variable in the pt data array, but that will work fine in the end so we'll go with it for simplicity.) Before generating the Makefile using the comp90.d command, however, we need to create the func_foo.f90 subprogram. The naming of this external function is important, since it is through the program name that the Makefile dependencies are generated. All functions must have the func_ prefix, and all subroutines must have the sub_ prefix. You should try to program primarily functions for the implementation of simple calculations.

To get started writing func_foo.f90, we can extract a simple function from the archive and imitate the format found within. For example, we could run spaextract density and then use func_density.f90 as a "template" for our own subprogram. All coding of SPA subprograms must conform to FORTRAN90 standards - consult FORTRAN90 manuals for assistance in writing subprograms. If an interface is required for your newly-developed func_foo.f90 (array-valued return, optional arguments, or just general safety), then insert it following the variable declarations in the main program before attempting to compile the project.

Now that you have func_foo.f90 ready to go (and making sure that you've removed the local copy of func_density.f90 that you used as a guide), enter comp90.d to generate the Makefile. If your nomeclature is correct, then you should be able so see a dependency in the Makefile: the main program will depend on the func_foo.o object file. Now you're ready to compile and run the project by entering make exec (or the project name) and runnin the resulting executable (once you've worked out any compile-time errors).

Once you've checked (and double checked, and had your buddy down the hall check) func_foo.f90 and are convinced that all is copacetic, the most important step of SPA development arrives. In order to allow all users access to your fantastic foo variable, you need to submit func_foo.f90 to the SPA. You can do so by contacting the developers or using one of the MetCal mailing lists on the SourceForge servers (http://sourceforge.net/projects/metcal). Provide as much information and documentation as possible to ease the introduction of the comptation into the archive. Please do not omit this very important step since it is the only way that the SPA will continue to grow and be of use to the community.