OpenMP in Fortran

Analogy categoryAnalogies

Introduction to OpenMP in Fortran

OpenMP is a shared-memory parallel programming model that Fortran supports through special comment directives beginning with !$omp, so an OpenMP-unaware compiler simply sees an ordinary comment and ignores it, while an OpenMP-enabled compiler (invoked with a flag such as gfortran -fopenmp) reads the directive and spawns a team of threads. Unlike coarrays or MPI, which distribute separate memory spaces across images or processes, OpenMP threads all share the same address space, so parallelizing a loop is often as simple as adding a directive above it rather than restructuring the data layout.

🏏

Cricket analogy: Like a single dressing room (shared memory) where every player can see the same whiteboard tactics, versus separate team buses (coarrays/MPI) where each squad only sees its own notes unless someone physically delivers a copy.

Parallelizing Loops with parallel do

The most common OpenMP construct in Fortran is !$omp parallel do, placed immediately before a do loop, which splits the loop's iterations across a team of threads so each thread executes a distinct chunk of the index range concurrently. Variables must be classified as shared (visible and modifiable by all threads) or private (each thread gets its own uninitialized copy) using clauses such as private(i,tmp) or default(none), and getting this classification wrong — for instance leaving a loop's temporary scalar shared instead of private — is the single most common source of OpenMP bugs, since threads then overwrite each other's intermediate results.

🏏

Cricket analogy: Like splitting the outfield into zones so five fielders each cover their own sector independently, but if two fielders both think a catch belongs to their zone without a clear boundary, they collide — just as an unclassified shared variable causes threads to collide.

fortran

program omp_saxpy
  use omp_lib
  implicit none
  integer, parameter :: n = 1000000
  integer :: i
  real :: a, x(n), y(n)

  a = 2.5
  x = 1.0
  y = 2.0

  !$omp parallel do private(i) shared(a, x, y)
  do i = 1, n
     y(i) = a * x(i) + y(i)
  end do
  !$omp end parallel do

  print *, 'y(1) =', y(1), ' threads used:', omp_get_max_threads()
end program omp_saxpy

Reductions and Race Conditions

Accumulating a value across loop iterations, such as summing an array, requires the reduction clause rather than a plain shared variable, because !$omp parallel do sum = sum + x(i) without reduction(+:sum) lets multiple threads read-modify-write sum simultaneously, silently dropping updates. Writing reduction(+:sum) on the parallel do directive tells the compiler to give each thread a private partial sum initialized appropriately, accumulate locally, and then combine all partial results into the shared sum once, safely, after the loop finishes.

🏏

Cricket analogy: Like five scorers each tallying their own section of the stadium's attendance count on private notepads, then adding all five notepads together at the end, rather than five scorers scribbling onto one shared notepad and losing counts.

Forgetting reduction(+:sum) — or, worse, forgetting private(i) for the loop index in a nested or non-standard loop — produces a data race. The program will often still run and print a plausible-looking but wrong number, and the wrong result can vary between runs and thread counts, making this class of bug notoriously hard to catch with a single test.

Scheduling, Sections, and Practical Tuning

OpenMP lets you control how loop iterations are assigned to threads with the schedule clause: schedule(static) divides the range into equal contiguous chunks up front (low overhead, best for uniform work per iteration), while schedule(dynamic, chunk) hands out smaller chunks on demand as threads finish, which balances load better when some iterations do far more work than others (for example, a loop whose cost grows with the iteration index). Beyond loops, !$omp sections lets you run a handful of genuinely different code blocks concurrently, and OMP_NUM_THREADS as an environment variable (or omp_set_num_threads at run time) controls how many threads the team actually uses.

🏏

Cricket analogy: Like a coach assigning fixed, equal net-practice slots to five batters up front (static), versus keeping a shared queue where whichever batter finishes their drill first gets the next available net (dynamic), useful when some batters need much longer sessions.

A quick rule of thumb: start with schedule(static) for loops where every iteration does roughly the same amount of work (it has the lowest scheduling overhead), and switch to schedule(dynamic, chunk) only after profiling shows load imbalance — for example a triangular loop bound like do j = i, n where later iterations do less work than earlier ones.

OpenMP directives (!$omp ...) are ignored as ordinary comments by compilers not given an OpenMP flag, making code portable.
OpenMP uses a shared-memory model: all threads see the same variables unless explicitly declared private.
!$omp parallel do splits a loop's iterations across a thread team; loop-local scalars must usually be private.
reduction(+:var) is required for safe cross-thread accumulation; a plain shared accumulator causes a silent data race.
schedule(static) suits uniform-cost loops; schedule(dynamic, chunk) suits loops with unequal per-iteration work.
OMP_NUM_THREADS (or omp_set_num_threads) controls how many threads actually run.
Unlike coarrays or MPI, OpenMP requires no data redistribution since all threads already share one address space.