Articles | Volume 18, issue 20
https://doi.org/10.5194/gmd-18-7417-2025
© Author(s) 2025. This work is distributed under the Creative Commons Attribution 4.0 License.
Smoothing and spatial verification of global fields
Download
- Final revised paper (published on 20 Oct 2025)
- Preprint (discussion started on 26 May 2025)
Interactive discussion
Status: closed
Comment types: AC – author | RC – referee | CC – community | EC – editor | CEC – chief editor
| : Report abuse
- RC1: 'Comment on egusphere-2025-1525', Anonymous Referee #1, 19 Jun 2025
- RC2: 'Comment on egusphere-2025-1525', Anonymous Referee #2, 03 Jul 2025
- AC1: 'Responses to reviwers comments', Gregor Skok, 29 Aug 2025
Peer review completion
AR: Author's response | RR: Referee report | ED: Editor decision | EF: Editorial file upload
AR by Gregor Skok on behalf of the Authors (29 Aug 2025)
Author's response
Author's tracked changes
EF by Mario Ebel (29 Aug 2025)
Manuscript
ED: Publish as is (05 Sep 2025) by Paul Ullrich
AR by Gregor Skok on behalf of the Authors (08 Sep 2025)
Manuscript
The manuscript presents two strategies for neighborhood-based smoothing. A kd tree range-search and an "advanced-front" style overlap-detection with reused intermediate steps on high-resolution grids on the spherical surface. While the topic is important and the ideas are promising, several gaps need to be closed before publication.
1. Clarify grid and geometry assumptions: When discussing the grid used in the model, please include detailed definitions, such as the grid data format used in the paper. Does it require connectivity or not? An example way to say this is: We only use a grid point for each face, without connectivity information. For each grid face, we just assume the face area is known. And when talking about a spherical surface, indicate if the sphere is a unit sphere or the sphere with the Earth's radius. And also, how did you handle the spherical geometry problem while you already assumed the grid area is provided?
2. Consider re-using the kd-tree during overlap pre-processing:
The manuscript treats the two algorithms as mutually exclusive: k‑d tree for “small/medium” radii and overlap‑detection for “large” radii. But the overlap method already needs to enumerate every neighbourhood during its one‑time table build, and it's in O(n) time complexity. So, intuitively, building the O(nlogn) k-d tree for this overlap step is beneficial, and it can reduce the neighbour search as well. Since it keeps the cap-membership logic identical in both schemes, it can also reuse the previous structure. So, a discussion point for such a hybrid method will be helpful. Even if you decide not to proceed with the hybrid method, some sentences explaining what the limits are will help to comprehensively discuss this problem. Finally, giving some benchmark experiments showing when it's a good time for the k-d tree algorithms and when it's a good time for the overlap detection will be beneficial as well.
3. More general numerical-error analysis is required for a broader audience. The statement that overlaps deviates by “< 0.01 mm / 6 h” lacks context. Some readers do not work with precipitation. Add a paragraph that (i) defines the brute‑force/k‑d result as the reference and (ii) explains why that is the correct ground truth for round‑off studies. Provide information on absolute error/relative error/ maximum error across representative radii instead of using the term “< 0.01 mm / 6 h”. An error-growth plot versus traversal depth (0,2000,400,..., 20000 hops) will also be helpful.
4. Providing fuller details for the experiment setup will be helpful: What kind of grids of the experiments, and why can they represent the common grid types? How do these grids reveal the nature of the spherical surface? And when carrying out experiments, are you consistently using float64? A clear definition of the experiment setup will greatly help.
Technical corrections:
p. 8, Fig. 5 caption: add CPU model and numeric precision.
Throughout, when stating runtimes (“single core”, “ten cores”), clarify whether these refer to physical cores or hardware threads, and whether hyper‑threading was enabled. This will help readers reproduce the scaling results.