Doctor Fortran in "We All Live in a Yellow Submodule"

Fortran 90 introduced the concept of modules, a separately compiled collection of declarations and procedures that could be referenced by other program units. This was borrowed from Ada, (and probably other languages), but omitted one very useful Ada feature: IS SEPARATE. Why is this important? With Fortran modules, a source file that USEs a module is dependent on the entire module; if any change is made to the module, every source that USEs it must be recompiled even if the changes have no effect on the interface. If you have nested modules, as many applications do, this can lead to a "recompilation cascade" that dramatically increases build time for even the most minor change.

Ada's IS SEPARATE let you separate the implementation of module procedures from the declaration so that changes in the implementation simply required a recompilation of that implementation and not all the users of the modules. It's been a long time, but separate implementation has finally come to Fortran with the Fortran 2008 submodule feature, and submodules are now in Intel® Fortran Compiler version 16.0. Let's see how this works...

Consider the following module:

module colors
...
contains
  subroutine sub1 (arg)
  integer, intent(in) :: arg
  ...
  end subroutine sub1
  function func2 (arg)
  real :: func2
  real, intent(in) :: arg
  ...
  end function func2
  ...
  subroutine sub47 (arg)
  character(*), intent(inout) :: arg
  ...
  end subroutine sub47
end module colors

The first thing we do is pull out the contains section and add interface blocks for the module procedures, with the addition of the keyword module before each function or subroutine. Like so:

module colors
…
interface
  module subroutine sub1 (arg)
  integer, intent(in) :: arg
  end subroutine sub1
  module function func2 (arg)
  real :: func2
  real, intent(in) :: arg
  end function func2
  …
  module subroutine sub47 (arg)
  character(*), intent(inout) :: arg
  end subroutine sub47
end interface
end module colors

The use of the module prefix tells the compiler that the implementation is separate. Now let's supply that. In a new source file, I'll call it colors_yellow.f90; we start out with:

submodule (colors) yellow

The name in parentheses is the parent of this submodule. Submodules can have other submodules as parents, so you can have a tree structure of them. Siblings can't see each other's declarations, but they can see their parent's.

Next would be any declarations that should be local to the submodule (or its children). use statements can be here too if needed - the submodule will automatically inherit all declarations from its parent. (And this leads to a cute trick - Module A can use module B, and a submodule of B can use module A! This doesn't create a circular dependency because module A can't see into the submodule of B.) So let's add some submodule-only declarations...

use, intrinsic :: ISO_FORTRAN_ENV
real(REAL64) :: localvar
contains

Now comes the fun part - the implementation of the procedures declared in the parent. Here you have a choice; you can repeat the subroutine or function statement and all the declarations from the interface, or you can use module procedure and inherit the interface. Repeating the declarations is perhaps easier for maintainers, as you don't have to reference two files to see how dummy arguments are declared. But the downside is that you have to type the declarations twice, introducing the possibility of a mismatch. (The compiler will complain, though, if they don't match.) module procedure is cleaner, with the declarations appearing only once, but may be a bit harder for maintainers to follow. Choose whichever model most appeals to you, and yes, you can mix and match. So let's do that...

module subroutine sub1 (arg)
integer, intent(in) :: arg
localvar = REAL(arg,REAL64)
end subroutine sub1
!
module procedure func2
func2 = arg + localvar
end procedure func2
!
module procedure sub47
arg = TRIM(arg) // "***"
end procedure sub47
!
end submodule yellow

You build a submodule just like any other Fortran source, and include its object output in the link of your application. When constructing your makefile or other build script that cares about build dependencies, the only new thing is that a submodule depends on its parent; nothing (except a child submodule) depends on the submodule. If you are using Intel® Visual Fortran in Microsoft Visual Studio*, this is handled for you automatically. The compilation of a submodule creates a file with a .smod file type, so you would create a rule for that in a makefile and have any child submodule depend on the .smod of its parent. The filename has the form parentmod@submod.smod, for example, colors@yellow.smod. Remember that the link is dependent on all the object files from all the submodules.

Now that we have the submodule created we can build the application. Oh, we need to change a line of code in sub47. When we do that, only the submodule gets recompiled and then the application is relinked. If we were doing this without submodules, any source that referenced module colors would also get recompiled. But what if we want to add or change the interface? Then, everything does need to be recompiled.

Submodules don't make your code any faster (nor any slower), but they can lead to a dramatic improvement in programmer productivity through better partitioning and reduced build times. Intel Fortran 16.0, part of Intel® Parallel Studio XE 2016, is the first Intel version to support submodules. Support in other Fortran compilers is limited as I write this, but I expect to see broader implementation as time goes on.

Got questions about using submodules or anything else Fortran? Ask in our user forums (Linux, OS X, Windows)!

For more complete information about compiler optimizations, see our Optimization Notice.