Articles | Volume 17, issue 9
https://doi.org/10.5194/gmd-17-4077-2024
© Author(s) 2024. This work is distributed under the Creative Commons Attribution 4.0 License.
Accelerating Lagrangian transport simulations on graphics processing units: performance optimizations of Massive-Parallel Trajectory Calculations (MPTRAC) v2.6
Download
- Final revised paper (published on 17 May 2024)
- Preprint (discussion started on 08 Jan 2024)
Interactive discussion
Status: closed
Comment types: AC – author | RC – referee | CC – community | EC – editor | CEC – chief editor
| : Report abuse
- RC1: 'Comment on egusphere-2023-2547', Anonymous Referee #1, 01 Feb 2024
- RC2: 'Comment on egusphere-2023-2547', Anonymous Referee #2, 03 Feb 2024
- RC3: 'Comment on egusphere-2023-2547', Anonymous Referee #3, 04 Feb 2024
- AC1: 'Comment on egusphere-2023-2547', Lars Hoffmann, 02 Apr 2024
Peer review completion
AR – Author's response | RR – Referee report | ED – Editor decision | EF – Editorial file upload
AR by Lars Hoffmann on behalf of the Authors (02 Apr 2024)
Author's response
Author's tracked changes
Manuscript
ED: Publish as is (09 Apr 2024) by Xiaomeng Huang
AR by Lars Hoffmann on behalf of the Authors (09 Apr 2024)
The manuscript is a follow-up to Hoffman et al. (2022) where the adaptation of MPTRAC to GPU processing unsing OPEN-ACC was described and demonstrated. The present work describes two types of optimization producing significant speed-up for both GPU and CPU versions of the code.
The manuscript is well written and clear both in the methods and results and should be published.
I have only a few minor comments and questions to the authors
1) Section 3 : Although the scope of this work is technical, a few more words about the type of tracer / molecule and processes considered here would be useful for the sake of completeness.
2) It is unclear that the ERA 5 needs to be used at its maximal spatial and temporal resolution for all transport applications, in particular for large-scale transport. Using the full vertical resolution is certainly a good choice but the horizontal and temporal resolution might be reduced at least for the horizontal wind with limited impact in many cases.
2) l.176 : What are NVTX markers ? This seems to be a NVIDIA feature for profiling.
3) L192 : The arithmetic intensity, which is perhaps not a common notion, needs to be defined.
4) No indication is given about the overlapping of data transfer and calculations. I do not know how this is applicable to the architecture considered here but it is a source of optimization in computers which cache memory. Perhaps it is done automatically but it derserved to be mentioned.
5) I guess that the code is running under a configuation where the nodes are reserved to a single user and not in time-sharing . This also deserves to be mentioned.
6) Figure 3 is hardly readible. I am not color blind but I see no red and the blue is difficult to distinguish from the green without zooming the figure. It seems that the baseline dots have a green contour and the optimized dots have a blue contour. This figure needs to be improved.
7) Figure 4: Is it possible to remove the 0.00 B/s channels or to indicate that this is an output from NVIDIA tools that cannot be beautified.
8) L 251 : Since two wind fields are required for time interpolation, why not aligning time in a float uvw[EX][EY][EZ][2][3] or float uvw[EX][EY][EZ][3][2] 5-D structure ?
9) Is there any impact of aligning the tracer data ?
10) It is not said whether the sorting is done by copying the tracer arrays or by using a permutation index without moving the data. Certainly the copy has the advantage of avoiding random access to the tracer data for the threads.