Publisher’s note: the content of this comment was removed on 26 May 2025 since the comment was posted by mistake.

This manuscript investigates the impact of task aggregation (i.e., wrapping multiple workflow tasks into a single submission) on job queue time in high-performance computing (HPC) environments. Using the MONARCH air quality model as a case study, the authors employ a Slurm simulator and synthetic workloads based on LUMI and historical HPC data to assess how task wrapping influences queue time and its correlation with factors such as fair share, CPU request, and runtime. The study finds that task aggregation can reduce total runtime by up to 7% and shows a strong negative correlation (−0.87) between queue time and fair share. Despite the relevance of the topic to HPC workflow optimization, this manuscript suffers from several major deficiencies that preclude publication in its current form. First, the introduction is poorly structured and lacks a coherent logical flow, making it difficult to understand the motivation and novelty of the study. The authors are strongly advised to thoroughly revise the introduction, clearly stating the research gap, objectives, and context within existing literature. Second, the overall structure of the manuscript is not conducive to clarity. It is recommended that the manuscript be reorganized into five standard sections: Introduction, Data and Methods, Results and Analysis, Discussion, and Conclusion. Currently, the paper lacks a meaningful discussion section, which is essential for interpreting results, evaluating strengths and weaknesses, and situating the work in a broader scientific context. Third, the content is overly simplistic, with limited methodological depth and superficial analysis, which significantly reduces the academic value of the paper. The authors focus primarily on a technical implementation without formulating or addressing a well-defined scientific problem. Furthermore, the figures and quantitative results, while potentially useful in a production context, do not provide sufficient insight or generalizability for a scientific audience. Lastly, the lack of rigorous validation or real-world deployment results further weakens the credibility of the conclusions. In summary, the manuscript lacks scientific depth, a clear problem formulation, and a meaningful discussion of results. Substantial revisions are needed to improve the structure, expand the analytical depth, and provide a more comprehensive evaluation of the methodology and its implications. Based on these significant shortcomings, I recommend rejection of this manuscript.

The core objective of this study is to quantify the impact of task aggregation on job queue times and to understand its relationship with the fair share factor, CPU, and runtime requests in HPC environments. The authors utilized a Slurm simulator, designed from actual Slurm executables, to reproduce scheduler behavior. They conducted experiments using both synthetic static workloads derived from LUMI supercomputer data and a dynamic workload from the decommissioned Curie machine to represent typical HPC usage patterns. The key findings indicate that aggregating tasks can reduce the total workflow runtime by up to 7% , which translates to substantial time savings (e.g., over eight days for half of the IS-ENES3 CMIP6 simulations). Furthermore, the study identified a strong inverse correlation (-0.87) between queue time and the fair share factor.

The quantitative results are compelling and offer valuable insights for optimizing workflow submissions on congested HPC systems. However, there are still significant issues. I agree with another reviewer that the submission is much like a technical report, instead of a scientific paper. Further more, several technical problems should be addressed. 

(1) The manuscript states that the observed 7% reduction in runtime could be "larger in reality". Please expand on the specific real-world factors or complexities (e.g., more dynamic system loads, nuanced fair share policies, or varied backfill algorithm effectiveness) that might contribute to a greater benefit in practice. This would enhance the practical applicability and persuasiveness of the findings.

(2) While the Slurm simulator is a strength, a more explicit discussion of its known limitations and how these might influence the generalizability of the results is warranted. For instance, the paper mentions that the simulator "does not have support for dynamic submission times" for constrained jobs as a real Workflow Management System like Autosubmit would. While the authors address this by calculating submission times based on assumed predecessor completion, further detail on the potential implications of this approximation on the reported queue times would be beneficial.

(3)  The methodology for controlling fair share in static workloads using "dummy" jobs is clear. However, consider adding a brief discussion on whether this method fully captures the complex and dynamic evolution of fair share in a truly live, highly utilized HPC system.

(4) The paper outlines several categories of wrappers (vertical, horizontal, vertical-horizontal, and horizontal-vertical) but focuses solely on vertical wrappers. A brief justification for this specific focus, and perhaps a suggestion for future research avenues exploring the impact of the other wrapper types, would strengthen the introduction or discussion.

This paper discusses an interesting use of a SLURM simulator to investigate the use of pilot jobs (which they call using wrappers) to improve the actual throughput of some small air quality simulations. The results obtained suggest an improvement in throughput of about 7%, and identified a high inverse correlation between the queue time and the fair share factor (a key slurm parameter).

Unfortunately the paper has some flaws, in particular around putting itself in context with other work, and on the wider applicability of the results, and until these are rectified, I do not think it should appear in GMD. I recommend major revisions.  

I have three significant concerns:

1. The material is not put well in the context of prior work, not only on measurement (e.g. Balaji et al 2017, whose results differ from those presented here - my quick calculation from their table 2 suggests the problem is of order 30%, so I don't know where the 10-20% they use as their motivation came from), and the large literature on pilot jobs on distributed and high throughput computing. The concept of wrapping things together is quite well established, but that leads me to my second concern:

2. One of the reasons that this is not done substantially in large-scale climate simulation is that the "chunks" of simulation (their nomenclature) provide natural checkpointing, and with bigger jobs than those they discuss model and hardware failures do lead to the need to checkpoint. Hardware failures are more prevalent now, and with bigger jobs that can be problematic. Perhaps this is why they only did Vertical Wrapping (they are only using one node per job if they only need 96 cores). Possibly horizontal wrapping would be more subject to this issue, but it might also be possible for the workflow manager to cope. 

3. The use of MONARCH and 96 core jobs (which are small for these systems) means that these results might not be typical of bigger jobs, not least because most large systems also prioritise bigger jobs, and so the fair-share factor influence may be less important. There is a large problem space that has not been examined. It's certainly the case that the CMIP extrapolation cannot be substantiated without exploring this in their simulations.

This last concern meant that I didn't read through their methodology in great detail, as I think this confounding factor for wider applicability needs to be addressed first.

Minor concerns/notes:

1. There is a language (ASYPD, SYPD) for the difference between the overall throughput and the peak throughput that was introduced in Balaji et al (2017) - a paper that shares a co-author with this one, so it is surprising that language is not used, and that Balaji et al is not cited. 

2. I had not seen Abhinit etal 2022, so I looked at it. I do not think it is saying the same thing as stated here. The problem in climate is unlikely to reach a need to wrap more than dozens of tasks (any more and the checkpoint issue dominates), whereas Abhinit et all were looking at wrapping thousands of tasks - in their case the issue is that most SLURM configurations do not have enough memory or resources to deal with the look ahead for queues with thousands of tasks. (Those that do are typically configured for High Throughput Computing, which is a different configuration to those encountered in most HPC sites where climate simulation is undertaken.)  Abhinit et al's discussion is more relevant to Dask workflows than simulation workflows. That said, it is indeed the case that HPC sites often limit the number of jobs users can have in queues, which is why tools like Autosubmit and Cylc exist. The issue of number of jobs is not the same as the issue of the queuing time for those jobs.

3. The decision to use pilot jobs for "wrappers" is not surprising, as pilot jobs have a long history, and a significant literature, none of which is referenced here.

4. 7% is interesting, but they then say this corresponds to 8 days of their CMIP project, which means that they were running for 3-4 months. Saving eight days sounds less impressive in that context, and surely suggests on that timescale background workload would influence things by at least the same factor (that is our experience). The use of a short selected trace means this longer-term variability is not sampled, but the more important issue is the influence of JobSizeWeight and JobSizeFactor.

5. It is a pity that the discussion of horizontal wrappers was not followed through as that is likely to result in better throughput for ensembles where there is any risk of a failure during execution.

6. The linear correlation exposed probably comes directly from the equation used by SLURM - surely they should include that equation and discuss the influence of all the key factors and relate to their results?