Next: SPA subprograms, Previous: Subprogram modification, Up: Customized Coding
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.