the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
Quantifying the scaling penalty of sequential coupling: The sequential coupling cost (Cseq) metric for Earth System Model components
Abstract. Coupling strategies in Earth System Models significantly influence their computational performance and resource efficiency. While coupling costs are traditionally evaluated in the context of concurrent implementations, the cost implications of sequential coupling approaches remain poorly quantified. In this work, we define and formalize the sequential coupling cost (Cseq): the additional computational resources required for a sequentially coupled ESM to achieve performance parity with an optimized concurrent setup.
We develop an analytical framework that utilizes individual component scalability profiles, derived directly from model execution logs, to diagnose inefficiencies inherent in sequential coupling architectures. To demonstrate the versatility of the metric, we apply it to three structurally distinct coupling scenarios, using models widely used by the community: atmosphere–ocean (IFS–NEMO), ocean–sea ice (NEMO–SI3), and atmosphere–aerosols (IFS–M7).
Our analysis reveals that sequential coupling imposes a substantial, yet often overlooked, efficiency deficit. By forcing all components to share a fixed resource pool, this approach ignores potential component-level parallelism and creates an exclusive reliance on domain-decomposition as a scaling strategy. While scaling solely via domain decomposition is sustainable in linear scaling regimes, it accelerates the loss of efficiency as soon as components enter sub-linear scaling regimes. We demonstrate that to achieve target throughputs, sequential setups often necessitate significant over-provisioning of computational resources, leading inefficiencies that traditional metrics fail to capture. The proposed Cseq metric quantifies these structural overheads, offering a quantitative basis for informing the design and architectural choices of next-generation exascale Earth System Models.
- Preprint
(591 KB) - Metadata XML
- BibTeX
- EndNote
Status: final response (author comments only)
-
RC1: 'Comment on egusphere-2026-1661', Anonymous Referee #1, 13 Jul 2026
The comment was uploaded in the form of a supplement: https://egusphere.copernicus.org/preprints/2026/egusphere-2026-1661/egusphere-2026-1661-RC1-supplement.pdfCitation: https://doi.org/
10.5194/egusphere-2026-1661-RC1 -
RC2: 'Comment on egusphere-2026-1661', Anonymous Referee #2, 19 Jul 2026
General comments
This paper addresses an important and timely question in Earth system model performance analysis: how to quantify the computational penalty associated with sequential coupling. The proposed sequential coupling cost metric, C_seq, is conceptually clear, practically useful, and fills a gap in the existing ESM performance-analysis toolbox, where traditional coupling-cost metrics are mainly designed for concurrent coupling configurations.
The methodology is sound, and the paper demonstrates the usefulness of the metric through three relevant and well-chosen examples: IFS–NEMO, NEMO–SI3, and OIFS–M7. These use cases show that sequential coupling can lead to substantial hidden resource inefficiencies, especially when individual components have different scaling behaviour. Overall, this is a useful contribution that should be of interest to model developers and HPC performance analysts working on coupled Earth system models.
I support publication after minor revisions, mainly aimed at improving clarity and presentation.
Specific comments
- Line 26: Please define MPMD when it is first introduced. This will make the introduction more accessible to readers who are less familiar with HPC terminology.
- Introduction: The introduction would benefit from a short paragraph, or at least a few sentences, explaining why some modelling systems choose a single-executable/sequential design in the first place. For example, in the IFS–NEMO case, data assimilation applications and operational constraints are important practical motivations. This would help present the architectural choice as a trade-off rather than simply an inefficiency.
- Lines 75–76: The text currently emphasises that Earth science models scale sub-linearly. I think an even more important point is that different Earth system components often scale differently. This is central to why sequential coupling can be inefficient: all components are forced to use the same resource pool, even when their optimal resource allocations differ substantially.- Figure 1: The figure is useful and the logic is clear. However, in the sequential panels, the labels T and >T appear above pairs of bars. Although this is logically correct, it may be visually misread as each individual bar having duration T or >T. I suggest labelling the individual sequential bars more explicitly, for example: linear sequential case as T/2+T/2=T, and sub-linear sequential case as >T/2+>T/2=>T.
- Figure 2: I would avoid labelling the y-axis simply as “Speed”. For the red and green curves, this is not the speed of an individual component, but rather the effective speed of completing the coupled system. A label such as “Effective coupled throughput”, “Effective system speed”, or simply “Coupled simulation speed” would reduce possible ambiguity.
- Lines 136–142: Around line 133 the paper states that no specialised performance analysis software is required, but shortly afterwards the Escalador library is introduced for the analysis workflow. This is slightly confusing.
- Section 4.1 and later sections: Expressing node counts as decimal numbers, for example 30.6 nodes, feels somewhat artificial from a practical HPC perspective. Since real allocations use integer node counts, I suggest rounding these values, at least in the main text, or clearly stating that decimal node counts come from the analytical fits and represent idealised estimates. This would make the results easier to interpret operationally.Citation: https://doi.org/10.5194/egusphere-2026-1661-RC2
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 47 | 26 | 4 | 77 | 4 | 1 |
- HTML: 47
- PDF: 26
- XML: 4
- Total: 77
- BibTeX: 4
- EndNote: 1
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1