the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
Task aggregation as a strategy to optimize Earth System Model workflows in HPC: assessing real scenarios with EC-Earth
Abstract. Earth System Models (ESMs) are commonly executed as complex workflows consisting of numerous interdependent tasks – the atomic unit of computation within the workflow – which comprise steps as model and data deployment, simulation, data transfer, and post-processing. Workflows facilitate the execution of long high-resolution configurations by splitting the runtime of the simulation into different tasks, in order to ensure frequent checkpointing and to comply with the restrictions of the large High-Performance Computing (HPC) machines where they are executed. These machines are frequently congested and, therefore, implement scheduling policies to share the resources among the users, complicating the execution of long ensemble simulation workflows due to the accumulated queue time, because each successive simulation task can only be submitted once the preceding one finishes. These queue times are the duration for which the jobs – the compute units sent to be executed remotely – wait for the HPC platform to allocate the required resources for their execution.
To alleviate this issue, we propose achieving shorter times-to-response, which are the durations from the first submission to the completion of the final task, by applying task aggregation to reduce subsequent requests for resources and, consequently, reducing queue times. Task aggregation is a strategy that consists of grouping multiple tasks and submitting them as a single job, respecting their dependencies, and without altering their underlying logic.
In this paper, we performed the first controlled assessment on the effects of task aggregation by conducting concurrent pairs of climate simulations in production machines, with the sole difference that one uses aggregation. These simulations were executed on three European supercomputers: MeluXina, MareNostrum 4, and MareNostrum 5. We measured the evolution of the fair share, a scheduling factor that normally plays a major role in the priority of the jobs. Besides absolute time, we compute the impact of aggregation by obtaining the differences between the Simulated Years Per Day (SYPD) and the Actual Simulated Years Per Day (ASYPD), two consolidated performance metrics for climate models within the community.
We prove the benefits of the task aggregation using EC-Earth3, a widely used European community climate model that shares main features with many other ESMs and has a representative workload. The experimental findings of our research indicate that across the three evaluated supercomputing platforms, applying task aggregation decreases total queue times by 11.17 to 12.33 times compared to a workflow that does not, representing an improvement in the ASYPD of up to 23,04 % in the case of the platform with the highest congestion.
Therefore, results have shown that task aggregation proves to be beneficial for long climate simulations. Moreover, we have credible reasons to believe that any vertical (also called chained) workflow should benefit from using it. We explain that this reduction in the time-to-solution comes from the decrease in the number of submitted jobs and the congestion of the machine. By aggregating tasks, we had many times less jobs queued and, albeit their longer length, we observed that they are in queue less time than if they had been submitted individually. Our results also show that the user's jobs are being held in queue in spite of their utilization due to the fair share being influenced by the other members of the HPC account, which is a direct consequence of the fair share policy of the machine.
-
Notice on discussion status
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
-
Preprint
(2082 KB)
-
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(2082 KB) - Metadata XML
- BibTeX
- EndNote
- Final revised paper
Journal article(s) based on this preprint
Interactive discussion
Status: closed
-
RC1: 'Comment on egusphere-2026-539', Anonymous Referee #1, 27 May 2026
- AC1: 'Reply on RC1', Pablo Goitia, 25 Jun 2026
-
RC2: 'Comment on egusphere-2026-539', Anonymous Referee #2, 06 Aug 2026
General Comments:
This paper expands on work by Marciani et al. (2025) by examining the impact of vertical task aggregation on total queue wait time using production climate models on active systems instead of the simulated load and slurm system examined in Marciani. They use a well established climate model and 3 prominent European HPC platforms. The overall experiment design of doing the same simulations with and without aggregation by users who have similar fair-share status is reasonable and the resulting data is clearly presented. However the details of the experiments do not seem to allign with typical climate model practice.
Specific Comments:
A key element missing in the description is the size of the jobs and what percentage of the system they represent. Small jobs will bias the results. The total queue time was so small compared to the run time that even when aggregating reduced total queue time, it had little impact on the ASYPD for MareNostrum 5 and MeluXina (results in Table 2).
But the biggest flaw in the experiment design is that a typical CMIP-class long (100 year) simulation will have each job use nearly the maximum allowed wall time, especially on a crowded machine. This makes it impossible to do any vertical aggregation of successive jobs since putting even 2 jobs together will exceed the maximum wall time. If the wrapper is creating job sizes that are effectively 10 years long that tells me the chunk should be 120 months, not 12. In the Mickelson 2020 paper, each CESM job submission is 10-years long. While it does make sense that fewer queue submissions will result in a shorter total queue time, this is not an option for most CMIP-class climate simulations. The results presented are not representative of production climate simulations and not applicable to other models/centers.
Citation: https://doi.org/10.5194/egusphere-2026-539-RC2 - AC2: 'Reply on RC2', Pablo Goitia, 25 Aug 2026
Peer review completion
Interactive discussion
Status: closed
-
RC1: 'Comment on egusphere-2026-539', Anonymous Referee #1, 27 May 2026
General comments
Task aggregation as a strategy to optimize Earth System Model workflows in HPC: assessing real scenarios with EC-Earth by P. Goitia et al. describes a specific feature of the autosubmit workflow software to wrap multiple task into a single (SLURM) job. The authors compare performance measurements with the focus on time to solution by submitting tasks as single jobs versus aggregating tasks into a larger job. The authors point out the benefits of task aggregation and show a gain in time to solution of up top 20%. As pointed out by the authors this technique as such is not new but has not been used in the context of climate modelling with its considerably complex workflows. The general idea is well described and discussed. The use cases (here EC-Earth run on three different HPC system) are relevant for the climate modelling community. The paper is not general in the sense that it does not provide a guideline for someone who would like to take autosubmit and apply this to a different workflow like a different numerical model to be run on yet another HPC system. The manuscript is concise and well written. Nevertheless, I stumbled over some repetitions which could be avoided for the sake of providing new information.
I well accept the authors choice of keeping the focus on task scheduling as such. Having said that, in this light I am missing some more in-depths discussion of the interrelation between queue waiting times, shortcomings of SLURM parameter adjustments and its bypassing with the task aggregation approach. While I understand the underlying problem and the proposed solution I wonder if this can also be approached by simply making a single task running for longer time, e.g. using chunks of 10 years rather than 1 month. Thus I am left with a bit of a doubt that task aggregation is the only solution for any Earth system model to reduce the time to solution.
Specific comments
Abstract
A matter of taste, but to me the abstract does not read as a short summary highlighting the most important findings but already provides very detailed information (e.g. congested machines). Task aggregation and queue time are mentioned before they are defined.
Introduction
The introduction already provides details of the methods. I propose to shift these to your section 3 (Methods).
L 68ff I propose to move the introduction to autosubmit after the introduction of other work (as state of the art) and thus address the mentioned problems mentioned rather than jumping back and forth between your approach and other work.
L 95ff The political impact of simulations with EC-Earth3 is not really relevant in this context.
L 99 I have had a hard time understanding why your solution is transversal (see my remark for your sec. 3)
L 102/103 Isn’t this sentence better placed in the next and final paragraph of the introduction? You assume that the reader is already familiar with “fair share”. Thus I wonder if its mentioning here is too early.
L 104 tells me what I have just read and can be deleted.
L 111ff This is just a plain repetition of what was said in line 105 and 106.
Background
L 155 I do not get why the backfill algorithm plays a negative role. It is just designed to fill gaps if possible to guarantee an efficient use of the whole system.
L 187 is of an account: please rephrase.
L 215ff Is the detailed description of EC-Earth3 really necessary in this context here?
L 226, 227 Repetition from the introdction
L 236 we tried: Did you succeed?
Methods
Why does a chunk size has to be 12 months? Why can’t it be 120? This would allow one to run 5 single jobs without the need of wrapping? Is there some limitation set by EC-Earth3 or any of the internal components which stand in the way? Are there any other advantages using chunk sizes of 12 and thus a wrapper size > 1 to reach the maximum allowed queue time?
How and where in the manuscript do you make use of Slurm parameters fair share, Level Fair Share, and raw usage that you collected? Earlier on, you explained Level Fair Share. How is this related to Fair Share and Raw usage mentioned in the figures. I am afraid that the reader gets a bit lost here. A bit more guidance would be nice.
Results and discussion
I interpret the differences in SYPD for the wrapped vs unwrapped cases as system fluctuations. The percentage and speedup with a precision of up to two decimals (even though true for these single cases) suggest an exactness which is questionable. I assume that these numbers are rather volatile and depend on the overall load of the system at a given time.
Figures 4, 5 and 6: The figure title is a repetition of the figure caption.
Conclusions
You described task aggregation of rather homogenous tasks. If other tasks like postprocessing were added would you expect similar benefits? Would there still be a benefit if all users on a congested system opted for task aggregation? How much could be compensated by adjusting the SLURM parameters? Wouldn’t it make more sense to use reservations to runs those long experiments.
Citation: https://doi.org/10.5194/egusphere-2026-539-RC1 - AC1: 'Reply on RC1', Pablo Goitia, 25 Jun 2026
-
RC2: 'Comment on egusphere-2026-539', Anonymous Referee #2, 06 Aug 2026
General Comments:
This paper expands on work by Marciani et al. (2025) by examining the impact of vertical task aggregation on total queue wait time using production climate models on active systems instead of the simulated load and slurm system examined in Marciani. They use a well established climate model and 3 prominent European HPC platforms. The overall experiment design of doing the same simulations with and without aggregation by users who have similar fair-share status is reasonable and the resulting data is clearly presented. However the details of the experiments do not seem to allign with typical climate model practice.
Specific Comments:
A key element missing in the description is the size of the jobs and what percentage of the system they represent. Small jobs will bias the results. The total queue time was so small compared to the run time that even when aggregating reduced total queue time, it had little impact on the ASYPD for MareNostrum 5 and MeluXina (results in Table 2).
But the biggest flaw in the experiment design is that a typical CMIP-class long (100 year) simulation will have each job use nearly the maximum allowed wall time, especially on a crowded machine. This makes it impossible to do any vertical aggregation of successive jobs since putting even 2 jobs together will exceed the maximum wall time. If the wrapper is creating job sizes that are effectively 10 years long that tells me the chunk should be 120 months, not 12. In the Mickelson 2020 paper, each CESM job submission is 10-years long. While it does make sense that fewer queue submissions will result in a shorter total queue time, this is not an option for most CMIP-class climate simulations. The results presented are not representative of production climate simulations and not applicable to other models/centers.
Citation: https://doi.org/10.5194/egusphere-2026-539-RC2 - AC2: 'Reply on RC2', Pablo Goitia, 25 Aug 2026
Peer review completion
Journal article(s) based on this preprint
Data sets
Machine utilization and statistics of EC-Earth3 workflows running on MareNostrum 4, MareNostrum 5, and MeluXina Pablo Goitia https://doi.org/10.5281/zenodo.15292084
Model code and software
EC-Earth3 workflow with wrappers in MareNostrum 4 Pablo Goitia et al. https://doi.org/10.48546/workflowhub.workflow.2067.1
EC-Earth3 workflow without wrappers in MareNostrum 4 Pablo Goitia et al. https://doi.org/10.48546/workflowhub.workflow.2066.1
EC-Earth3 workflow with wrappers in MareNostrum 5 Pablo Goitia et al. https://doi.org/10.48546/workflowhub.workflow.2065.1
EC-Earth3 workflow without wrappers in MareNostrum 5 Pablo Goitia et al. https://doi.org/10.48546/workflowhub.workflow.2064.1
EC-Earth3 workflow with wrappers in MeluXina Pablo Goitia et al. https://doi.org/10.48546/workflowhub.workflow.2063.1
EC-Earth3 workflow without wrappers in MeluXina Pablo Goitia et al. https://doi.org/10.48546/workflowhub.workflow.2062.1
Header scripts to gather statistics and usage records of EC-Earth3 workflows from MareNostrum 4, MareNostrum 5, and Meluxina Pablo Goitia and Manuel G. Marciani https://doi.org/10.5281/zenodo.15673462
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 320 | 117 | 29 | 466 | 32 | 36 |
- HTML: 320
- PDF: 117
- XML: 29
- Total: 466
- BibTeX: 32
- EndNote: 36
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Manuel G. Marciani
Miguel Castrillo
Mario C. Acosta
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(2082 KB) - Metadata XML
General comments
Task aggregation as a strategy to optimize Earth System Model workflows in HPC: assessing real scenarios with EC-Earth by P. Goitia et al. describes a specific feature of the autosubmit workflow software to wrap multiple task into a single (SLURM) job. The authors compare performance measurements with the focus on time to solution by submitting tasks as single jobs versus aggregating tasks into a larger job. The authors point out the benefits of task aggregation and show a gain in time to solution of up top 20%. As pointed out by the authors this technique as such is not new but has not been used in the context of climate modelling with its considerably complex workflows. The general idea is well described and discussed. The use cases (here EC-Earth run on three different HPC system) are relevant for the climate modelling community. The paper is not general in the sense that it does not provide a guideline for someone who would like to take autosubmit and apply this to a different workflow like a different numerical model to be run on yet another HPC system. The manuscript is concise and well written. Nevertheless, I stumbled over some repetitions which could be avoided for the sake of providing new information.
I well accept the authors choice of keeping the focus on task scheduling as such. Having said that, in this light I am missing some more in-depths discussion of the interrelation between queue waiting times, shortcomings of SLURM parameter adjustments and its bypassing with the task aggregation approach. While I understand the underlying problem and the proposed solution I wonder if this can also be approached by simply making a single task running for longer time, e.g. using chunks of 10 years rather than 1 month. Thus I am left with a bit of a doubt that task aggregation is the only solution for any Earth system model to reduce the time to solution.
Specific comments
Abstract
A matter of taste, but to me the abstract does not read as a short summary highlighting the most important findings but already provides very detailed information (e.g. congested machines). Task aggregation and queue time are mentioned before they are defined.
Introduction
The introduction already provides details of the methods. I propose to shift these to your section 3 (Methods).
L 68ff I propose to move the introduction to autosubmit after the introduction of other work (as state of the art) and thus address the mentioned problems mentioned rather than jumping back and forth between your approach and other work.
L 95ff The political impact of simulations with EC-Earth3 is not really relevant in this context.
L 99 I have had a hard time understanding why your solution is transversal (see my remark for your sec. 3)
L 102/103 Isn’t this sentence better placed in the next and final paragraph of the introduction? You assume that the reader is already familiar with “fair share”. Thus I wonder if its mentioning here is too early.
L 104 tells me what I have just read and can be deleted.
L 111ff This is just a plain repetition of what was said in line 105 and 106.
Background
L 155 I do not get why the backfill algorithm plays a negative role. It is just designed to fill gaps if possible to guarantee an efficient use of the whole system.
L 187 is of an account: please rephrase.
L 215ff Is the detailed description of EC-Earth3 really necessary in this context here?
L 226, 227 Repetition from the introdction
L 236 we tried: Did you succeed?
Methods
Why does a chunk size has to be 12 months? Why can’t it be 120? This would allow one to run 5 single jobs without the need of wrapping? Is there some limitation set by EC-Earth3 or any of the internal components which stand in the way? Are there any other advantages using chunk sizes of 12 and thus a wrapper size > 1 to reach the maximum allowed queue time?
How and where in the manuscript do you make use of Slurm parameters fair share, Level Fair Share, and raw usage that you collected? Earlier on, you explained Level Fair Share. How is this related to Fair Share and Raw usage mentioned in the figures. I am afraid that the reader gets a bit lost here. A bit more guidance would be nice.
Results and discussion
I interpret the differences in SYPD for the wrapped vs unwrapped cases as system fluctuations. The percentage and speedup with a precision of up to two decimals (even though true for these single cases) suggest an exactness which is questionable. I assume that these numbers are rather volatile and depend on the overall load of the system at a given time.
Figures 4, 5 and 6: The figure title is a repetition of the figure caption.
Conclusions
You described task aggregation of rather homogenous tasks. If other tasks like postprocessing were added would you expect similar benefits? Would there still be a benefit if all users on a congested system opted for task aggregation? How much could be compensated by adjusting the SLURM parameters? Wouldn’t it make more sense to use reservations to runs those long experiments.