11. Subprograms

When a program is more than a few hundred lines long, it gets hard to follow. Fortran codes that solve real engineering problems often have tens of thousands of lines. The only way to handle such big codes, is to use a modular approach and split the program into many separate smaller units called subprograms.

A subprogram is a (small) piece of code that solves a well defined subproblem. In a large program, one often has to solve the same subproblems with many different data. Instead of replicating code, these tasks should be solved by subprograms . The same subprogram can be invoked many times with different input data.

Fortran has two different types of subprograms, called functions and subroutines.


Fortran functions are quite similar to mathematical functions: They both take a set of input arguments (parameters) and return a value of some type. In the preceding discussion we talked about user defined subprograms. Fortran 77 also has some intrinsic (built-in) functions.

A simple example illustrates how to use a function:

      x = cos(pi/3.0)

Here cos is the cosine function, so x will be assigned the value 0.5 (if pi has been correctly defined; Fortran 77 has no built-in constants). There are many intrinsic functions in Fortran 77. Some of the most common are:

      abs     absolute value
      min     minimum value
      max     maximum value
      sqrt    square root
      sin     sine
      cos     cosine
      tan     tangent
      atan    arctangent
      exp     exponential (natural)
      log     logarithm (natural)

In general, a function always has a type. Most of the built-in functions mentioned above, however, are generic. So in the example above, pi and x could be either of type real or double precision. The compiler would check the types and use the correct version of cos (real or double precision). Unfortunately, Fortran is not really a polymorphic language so in general you have to be careful to match the types of your variables and your functions!

Now we turn to the user-written functions. Consider the following problem: A meteorologist has studied the precipitation levels in the Bay Area and has come up with a model r(m,t) where r is the amount of rain, m is the month, and t is a scalar parameter that depends on the location. Given the formula for r and the value of t, compute the annual rainfall.

The obvious way to solve the problem is to write a loop that runs over all the months and sums up the values of r. Since computing the value of r is an independent subproblem, it is convenient to implement it as a function. The following main program can be used:

      program rain
      real r, t, sum
      integer m
      read (*,*) t
      sum = 0.0
      do 10 m = 1, 12
         sum = sum + r(m, t)
  10  continue
      write (*,*) 'Annual rainfall is ', sum, 'inches'


Note that we have declared 'r' to be 'real' just as we would a variable. In addition, the function r has to be defined as a Fortran function. The formula the meteorologist came up with was

      r(m,t) = t/10 * (m**2 + 14*m + 46) if this is positive
      r(m,t) = 0                         otherwise        

The corresponding Fortran function is

      real function r(m,t)
      integer m
      real t

      r = 0.1*t * (m**2 + 14*m + 46)
      if (r .LT. 0) r = 0.0


We see that the structure of a function closely resembles that of the main program. The main differences are:

To sum up, the general syntax of a Fortran 77 function is:

      type function name (list-of-variables)

The function has to be declared with the correct type in the calling program unit. If you use a function which has not been declared, Fortran will try to use the same implicit typing used for variables, probably getting it wrong. The function is called by simply using the function name and listing the parameters in parenthesis.

It should be noted that strictly speaking Fortran 77 doesn't permit recursion (functions which call themselves). However, it is not uncommon for a compiler to allow recursion.


A Fortran function can essentially only return one value. Often we want to return two or more values (or sometimes none!). For this purpose we use the subroutine construct. The syntax is as follows:

      subroutine name (list-of-arguments)

Note that subroutines have no type and consequently should not (cannot) be declared in the calling program unit. They are also invoked differently than functions, using the word call before their names and parameters.

We give an example of a very simple subroutine. The purpose of the subroutine is to swap two integers.

      subroutine iswap (a, b)
      integer a, b
c Local variables
      integer tmp

      tmp = a
      a = b
      b = tmp


Note that there are two blocks of variable declarations here. First, we declare the input/output parameters, i.e. the variables that are common to both the caller and the callee. Afterwards, we declare the local variables, i.e. the variables that can only be used within this subprogram. We can use the same variable names in different subprograms and the compiler will know that they are different variables that just happen to have the same names.


Fortran 77 uses the so-called call-by-reference paradigm. This means that instead of just passing the values of the function/subroutine arguments (call-by-value), the memory address of the arguments (pointers) are passed instead. A small example should show the difference:

      program callex
      integer m, n
      m = 1
      n = 2 

      call iswap(m, n)
      write(*,*) m, n


The output from this program is "2 1", just as one would expect. However, if Fortran 77 had been using call-by-value then the output would have been "1 2", i.e. the variables m and n were unchanged! The reason for this is that only the values of m and n had been copied to the subroutine iswap, and even if a and b were swapped inside the subroutine the new values would not have been passed back to the main program.

In the above example, call-by-reference was exactly what we wanted. But you have to be careful about this when writing Fortran code, because it is easy to introduce undesired side effects. For example, sometimes it is tempting to use an input parameter in a subprogram as a local variable and change its value. Since the new value will then propagate back to the calling program with an unexpected value, you should never do this unless (like our iswap subroutine) the change is part of the purpose of the subroutine.

We will come back to this issue in a later section on passing arrays as arguments (parameters).

Copyright 1995-7 by Stanford University. All rights reserved.