Weak Scaling
Weak scaling grows the problem size in proportion to the processor count, testing whether a code can tackle larger problems in constant time.
Work grows with the machine
Weak scaling keeps the work per processor fixed and increases the total problem size as processors are added. The question is whether run time stays roughly constant. Ideal weak scaling means solving a problem twice as large on twice the processors in the same wall-clock time. This is the relevant test when the goal is higher resolution or larger domains, not just faster answers to a fixed problem.
The governing law
Weak scaling is described by Gustafson's law, which is more optimistic than Amdahl's because the parallel part of the work grows while the serial part stays fixed. As the problem grows, the serial fraction shrinks relatively, so large machines can be used efficiently even when strong scaling would have saturated.
What still limits it
- Communication that grows faster than local work (for example global reductions)
- Load imbalance that worsens at scale
- Memory and I/O capacity that must grow with the problem
Weak-scaling efficiency
Efficiency is the single-processor time for the base problem divided by the N-processor time for the N-times-larger problem. Perfect efficiency is a flat line at 1.0. A gently rising run-time curve is normal and acceptable; a steep rise signals communication or imbalance costs that will cap usable scale.
When each matters
Strong scaling matters when a fixed problem must finish sooner. Weak scaling matters when the science needs finer grids or bigger models, as in high-resolution plasma turbulence or large neural networks. Most real campaigns care about both and report each separately.