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.

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.

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.

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.