Fortran

Modern Fortran Development

This skill covers writing modern, maintainable Fortran (2003/2008 and later) for scientific and numerical computing, including module organization, kind parameters, procedure design, memory safety, and testing.

Workflow for Writing a Modern Fortran Module

1. Define shared kinds first — Create a kinds_mod (or similarly named) module with iso_fortran_env or selected_real_kind/selected_int_kind parameters used across the whole project.
2. Design the module — Group related derived types and procedures into one focused module per file; declare implicit none at the top.
3. Write procedure interfaces — Give every dummy argument an explicit intent(in), intent(out), or intent(inout); use use, only: to import exactly what's needed.
4. Implement with early validation — Check preconditions (array bounds, allocation state, valid ranges) at the top of each procedure and return/stop early rather than nesting deeply.
5. Manage arrays explicitly — Use allocatable arrays, check allocated() before use, and deallocate when the lifetime isn't naturally scoped.
6. Build with warnings on — Compile with -Wall -Wextra -std=f2008 (gfortran) or the equivalent, and fail CI on new warnings.
7. Test — Write unit tests for individual procedures and integration tests for full numerical workflows, checking tolerances rather than exact floating-point equality.

Basic Principles

• Target modern Fortran standards — Fortran 2003, 2008, or newer — and avoid writing in a legacy FORTRAN 77 style just because the compiler still accepts it.
• Put implicit none in every program unit (module, program, and — via inheritance from a module or explicit statement — every procedure) so undeclared-variable typos are caught at compile time instead of producing silent wrong answers.
• Put procedures in modules rather than external subprograms; module procedures get automatically-generated explicit interfaces, which lets the compiler catch argument mismatches that external procedures cannot.
• Keep modules focused on one concern and place each major module in its own file, named to match the module (e.g., module linear_solver in linear_solver.f90).
• Prefer clear, structured code over clever language tricks — Fortran numerical code is read far more often than it's written, usually by someone other than the original author.
• Avoid obsolete features: COMMON blocks (replace with modules), GOTO-heavy control flow (replace with structured if/do/select case, plus block where useful), and numeric statement labels used as jump targets.

Kinds and Types

• Define numeric kind parameters in one shared module (e.g., kind_mod or precision_mod) so the whole codebase can change precision in one place.
• Use real(kind=dp) (or the project's approved real kind) for floating-point values — never bare real or double precision, whose actual precision is compiler- and flag-dependent.
• Use integer(kind=i4) (or the project's approved integer kind) for integers where the width matters, especially in interfaces to C or binary I/O.
• Define constants such as pi explicitly and precisely (e.g., real(dp), parameter :: pi = 4.0_dp * atan(1.0_dp)) rather than truncated literals.
• Include the physical units in a comment for any variable representing a physical quantity (real(dp) :: velocity ! m/s).
• Use derived types to group related data (e.g., a particle_t type with position, velocity, and mass fields) instead of passing many loose primitive arguments through procedure calls.

Example: Kinds Module and a Numerical Procedure

module kinds_mod
  use iso_fortran_env, only: real64, int32
  implicit none
  private
  public :: dp, i4

  integer, parameter :: dp = real64
  integer, parameter :: i4 = int32
end module kinds_mod

module stats_mod
  use kinds_mod, only: dp
  implicit none
  private
  public :: mean, standard_deviation

contains

  pure function mean(x) result(m)
    real(dp), intent(in) :: x(:)
    real(dp) :: m

    m = sum(x) / real(size(x), dp)
  end function mean

  pure function standard_deviation(x) result(s)
    real(dp), intent(in) :: x(:)
    real(dp) :: s
    real(dp) :: m
    integer :: n

    n = size(x)
    if (n < 2) then
      s = 0.0_dp
      return
    end if

    m = mean(x)
    s = sqrt(sum((x - m)**2) / real(n - 1, dp))
  end function standard_deviation

end module stats_mod

program demo
  use kinds_mod, only: dp
  use stats_mod, only: mean, standard_deviation
  implicit none

  real(dp) :: samples(5)
  samples = [1.0_dp, 2.0_dp, 3.0_dp, 4.0_dp, 5.0_dp]

  print '(A, F0.4)', 'mean = ', mean(samples)
  print '(A, F0.4)', 'stddev = ', standard_deviation(samples)
end program demo

Naming and Style

• Use lowercase for language keywords and most identifiers; Fortran is case-insensitive, so consistent lowercase avoids visual noise from mixed-case keywords.
• Use underscores for multi-word names (particle_velocity, not particleVelocity or ParticleVelocity).
• Avoid names that differ only by case (Count vs count) since Fortran treats them as identical, inviting confusion.
• Use descriptive names for procedures and state (compute_residual, not cr or calc2).
• Repeat the procedure or module name after end statements (end module kinds_mod, end subroutine compute_residual) so long units are easy to verify by eye.
• Keep indentation consistent (2 or 4 spaces, matching the project) inside do, if, select case, and module blocks.