Dear Authors,

Thank you for an interesting read and use of the SOLWEIG-model. A full workflow using GPU-enabled technology for Tmrt calculation is proven to be very efficient for this type a 2.5D-model. Many of you know me as the creator and maintainer of the SOLWEIG-model and based on that, I would like to add some comments regarding the setup and results produced. I must confess that I have only done one read-through, so some of my comments might be explained in the text already. Sorry for that.

1. Please improve the description on the settings using the model as this have large implications on your results and the interpretation of your findings. You state that you are using v2022a and this includes anisotrophic schemes for the long- as well as the diffuse shortwave sky. Did you implement these settings? Also, did you use the Reindl et al method to partition diffuse and direct shortwave radiation from global or did you get that from ERA5? More details are needed! Especially since the settings could be an explanation to your bias in Tmrt shown in e.g. fig 7, especially in dense urban areas because of the anisotrophic skies (Wallenberg et al. 2020; 2023)

2. Using this version of the model requires the correct referencing which should include Wallenberg et al. 2020 and 2023.

3. You are using black globe temperature sensors to derive Tmrt which needs to be discussed further. Did you calibrate these against more accurate observations and if not, do you think the bias in e.g. fig 7 could be explained based on this rather that my points in bulletpoint 1?

best wishes,

Fredrik Lindberg

Wallenberg, Nils, Lindberg F, Holmer B, and Thorsson S. (2020) "The Influence of Anisotropic Diffuse Shortwave Radiation on Mean Radiant Temperature in Outdoor Urban Environments." Urban Climate 31 (2020). https://doi.org/10.1016/j.uclim.2020.100589.

Wallenberg, N., Lindberg, F., Holmer, B., and Rayner, D. (2023) An anisotropic parameterization scheme for longwave irradiance and its impact on radiant load in urban outdoor settings. International journal of biometeorology. https://doi.org/10.1007/s00484-023-02441-3.

The article describes a GPU based model which is inspired from state-of-the art model. The article aim, literature review, method and results are clearly presented. It is simple to read and useful to the community. The model outputs is rather well examplified with a very interesting dataset.

In my opinion, only three minor issues raise:

1. Several informations are missing to justify choices made by the authors (shortly listed here but more detailed below)

• number of wind directions used
• using 10-cells padding
• modulation terms for UHI
• lapse rate calculated via ERA5 multi-level data
• new values or schemes for URock are used

If these choices have been made arbitrarily, a specific paragraph with current limitations should be added. This paragraph could be seen as a set of investigations that could be performed in the future and thus adressed to the research community). If the choice can be clearly justify, please explicitly write it at the corresponding location in the manuscript.

2. More specifically concerning the wind model, I think that a short paragraph (or / and table) dedicated to summarizing (and justifying) the differences with other existing Röckle models would make sense (eg. only along-x wind modification, no mass-balance algo, upwind and wake models for trees, no street-canyon scheme, no backward zones, etc.).

3. There is no need to have a forge such as a gitlab or a github to publish in gmd but I wonder the objective of the authors if they do not have a platform where they can interact with a user community if there are any bug to solve ?

Other (and more detailed) comments:

1. « Tolan et al., 2024 » (“egusphere-2026-776”, p. 3) There is no corresponding reference
2. « the three-dimensional distribution of urban and peri-urban vegetation » (“egusphere-2026-776”, p. 3) The previous paragraph definitely deals with urban since buildings are treated. This paragraph deals with vegetation (which is mainly located outside urban areas). Vegetation is known to be more difficult to identify in cities due to shadow and from what I have read, Tolan et al. (2024) do not evaluate the potential difference of results obtained inside or outside cities. I suppose a warning sentence here could be welcome.
3. « Platforms such as Google Earth Engine enable planetary-scale access and processing of these datasets in a reproducible, scriptable manner (Gorelick et al., 2017) » (“egusphere-2026-776”, p. 3) I suppose this sentence located one sentence before would make more sense ?
4. « igure 1. » (“egusphere-2026-776”, p. 5) Processes : clip, merge AND reclassify
5. « 12 directional wind-sheltering rasters » (“egusphere-2026-776”, p. 7) Any motivation for using 12 ? Have you tested (or read something) about using more or less splitting to evaluate the differences in terms of accuracy and computation time ?
6. « Sudharsan » (“egusphere-2026-776”, p. 7) I suppose the reference is only the github ?
7. « While GLIDE-SOL re-architects the surrounding workflow (global input generation, coordinated tiling, and post-processing), this prior work provided a valuable reference point for GPU-oriented refactoring of the SOLWEIG radiative geometry and time-stepping » (“egusphere-2026-776”, p. 7) I would have started with the second part of the sentence
8. « 10-cell padding is added » (“egusphere-2026-776”, p. 7) Same as wind directional, if you have any results to share about the choice of this value, it would be interesting to mention. Or mentionning that it has not be done since it could be something to investigate in the future
9. « d,a » (“egusphere-2026-776”, p. 8) space missing
10. « ready file to LERC+ZSTD (variable-specific MAX_Z_ERROR budgets of 0.15 ◦C for UTCI, 0.10 ◦C for Tmrt, 0.005 m s−1 for Va10m, and a 2 W m−2 default for radiative terms) » (“egusphere-2026-776”, p. 8) Not clear
11. « Rather than using fixed clock times » (“egusphere-2026-776”, p. 9) it is not only that you do not use fix clock times, it is also that you define the night according to a specific definition. It would be easier to read if you clearly state it.
12. « SVF(x, y) is the sky-view factor, fveg(x, y) » (“egusphere-2026-776”, p. 9) SVF can be a ponctual information, vegetation fraction cannot. Did I miss the information about the zone considered for the calculation of these geographical indicators ? I suppose you do not use the 2 m resolution used for the other calculation, it would lead to far too much heterogeneity for air temperature...
13. « The modulation term (2 − SVF − fveg) attenuates the applied UHI in open or highly vegetated areas, where nocturnal cooling is more effective. » (“egusphere-2026-776”, p. 9) Is this a proposed Equation based on observed UHI behavior or the result of any fitting with observation ? I suppose the first (if 2nd, please specify the reference), it might be highlight as a limitation.
    
    
    
    Instead of using SVF and fveg which are proxy of radiative and convective processes, what about using directly the wind and radiation calculated by the model for each time step ?
14. « moist-adiabatic lapse rate Γm(T, p) » (“egusphere-2026-776”, p. 9) Formula used ?
15. « at every time step » (“egusphere-2026-776”, p. 9) Same formula for day and for night-time ? What about using the ERA5 multi-level data to derive a lapse rate ?
16. « Reference wind » (“egusphere-2026-776”, p. 9) How do you deal with domains intersecting several ERA5 tiles ? You may end with two (or more) different reference wind over your domain, do you smooth the reference wind values over the domain area ?
    
    If I understand well, when your domain is entirely included within a single ERA5 cell, the reference wind is the same for the whole domain, you do not recalculate the reference wind for each of your subdomain (tile) ?
    
    
    
    Would it make sense to interpolate wind over the whole domain cells based on wind value in ERA5 cells located around the concerned ERA5 ?
17. « with a simplified version » (“egusphere-2026-776”, p. 10) Specify that it is a one step approach, the wind flow resulting is not balanced.
18. « wake » (“egusphere-2026-776”, p. 10) using wake here is confusing because in the next section you differentiate upwind and wake regions. Maybe removing wake here make it simple ?
19. « effective obstacle width W , depth D (along-wind), and height H » (“egusphere-2026-776”, p. 10) what is the definition of these effective length ? The shape of the building may play a role on the way you calculate these parameters. The methods differ between QUIC-URB and URock for example.
20. « reduction coefficient is vertically uniform » (“egusphere-2026-776”, p. 10) It seems it is although uniform along y right ? This is definitely a difference with the Röckle approach using ellipsoid shapes (and reduction) both along y and z. This difference should be specified.
21. « In other words, within the upwind and wake regions, the wind speed is assumed to be reduced by the same factor at all heights below the obstacle top, » (“egusphere-2026-776”, p. 10) My feeling: make it simple, the first sentence was clear, you can directly say that it works differently in the canopy-flow parameterization
22. « 2W » (“egusphere-2026-776”, p. 10) Any motivation for setting 2W instead of the 1.5W used in Kaplan and Dinar (1996) or Bernard and al (2023) ?
23. « 4 » (“egusphere-2026-776”, p. 11) Same as previous section, why 4 instead of 3 used by Kaplan and Dinar (1996) or Bernard et al. (2023) ?
24. « while ensuring that overlapping wakes combine conservatively » (“egusphere-2026-776”, p. 11) Not clear, wake coefficient multiply each over when they overlap ?
25. « The model depends on an effective leaf area index » (“egusphere-2026-776”, p. 11) This is not the case in Bernard et al. (2023). If I understand well, the bigger a vegetation patch, the bigger the attenuation ? I think it is rather relevant and could lead to improved results, it should be noted that it differ from Bernard et al. (2023).
26. « Given Ct,base at the obstacle location, we apply the same wake geometry as for buildings, with an upwind deceleration over » (“egusphere-2026-776”, p. 12) There is no such zones in URock or Röckle, please specify it. How these choices were made ? Arbitrarily, did you have tests and validations on a limited subset, etc. ?
27. « interiors » (“egusphere-2026-776”, p. 12) what do you mean by building interiors ? Courtyards ? If so why ?
    
    If it really makes reference to the building interior, I do not think it makes sense to keep it since obviously you do not consider building interior...
28. « effective kernel of about 40 m » (“egusphere-2026-776”, p. 12) A reason for 40 m ?
29. « to blend overlapping wakes and suppress blocky artifacts » (“egusphere-2026-776”, p. 12) I do not clearly see what do you mean
30. « Decentlab DL-SHT35 sensor » (“egusphere-2026-776”, p. 13) Could you please specify the shield used since it might be more important than the sensor itself ?
31. « Figure 2. » (“egusphere-2026-776”, p. 14) You specify that stations were selected based on LCZ. It might be interesting to show either the LCZ map to appreciate the surrounding of each station, either coloring each circle with the LCZ color scheme.
32. « Figure 3 » (“egusphere-2026-776”, p. 15) I am quite surprised by the shape of the acceleration zones. It does not look like the first step of a Röckle based model but rather after the second step (mass-conservation).
    
    More specifically, how do you explain the quite low wind reduction downwind the large parking building (5 storey in OSM) at coordinate 51.5069409°N, 7.4598144°E ?
    
    Same near a large (but probably not that high) "industrial" building at coordinate 51.5208217°N ,7.4848979E,
    
    etc.
33. « Its effect is therefore » (“egusphere-2026-776”, p. 15) Not sure that I understand the reason for not having the map. A map is calculated for each time step, right ?
34. « air temperature » (“egusphere-2026-776”, p. 16) I may have already had asked but how do you deal with the discontinuity of ERA5 variables between 2 cells if they intersect your domain ? Do you interpolate some of the ERA5 variables over the whole domain ?
35. « wind speed » (“egusphere-2026-776”, p. 16) It is surprising that none of the station is located in a high wind speed area. None of them are located in a low vegetation, bare soil or impervious LCZ type ? This question is consistent with my previous concern about the missing LCZ map (at least station)
36. « OHS 0.23 0.64 » (“egusphere-2026-776”, p. 18) same as next comment
37. « HAP 0.38 0.86 » (“egusphere-2026-776”, p. 18) what is the reason for the sometimes large differences between SVF obs and mod ?
38. « Figure 5. » (“egusphere-2026-776”, p. 19) On Figure 5 and following, it might be difficult to see the SOL_STD points due to the high density of points. Any chance to replace the scatter by curves showing the mean line + confidence interval (might be 0.25 and 0.75 percentiles) ?
39. « incorporating flow-dependent predictors is a promising avenue for future development. » (“egusphere-2026-776”, p. 24) excellent !
40. « the use of a simplified urban wind-reduction model that cannot fully capture local channeling or sheltering » (“egusphere-2026-776”, p. 25) I suppose terrain elevation might also something missing and which could be improved for example using approaches such as proposed in Robinson et al (2022)
    
    Robinson, David, Sara Brambilla, Michael J. Brown, Patrick Conry, Bryan Quaife, et Rod R. Linn. « QUIC-URB and QUIC-Fire Extension to Complex Terrain: Development of a Terrain-Following Coordinate System ». Environmental Modelling & Software 159 (janvier 2023): 105579. https://doi.org/10.1016/j.envsoft.2022.105579.
41. « Code and data availability » (“egusphere-2026-776”, p. 26) There is no need to have a forge such as a gitlab or a github to publish in gmd but I wonder the objective of the authors if they do not have a platform where they can interact with a user community ?

Dear authors,

I think this work is a meaningful and well-directed step towards making high-resolution thermal comfort modelling accessible on a large scale.

The manuscript introduces GLIDE-SOL: a fully scripted, globally deployable Python workflow that utilizes SOLWEIG to enable the rapid and repeatable mapping of thermal comfort across diverse urban environments. By integrating harmonized global inputs with physics-based diagnostics, GPU acceleration and scalable tiling, GLIDE-SOL addresses a significant gap in current practice by providing fast, globally applicable prediction tools for urban heat stress. I strongly support this approach and recommend publication of the manuscript after minor revisions.

Main comments:

1. UHI correction
   1. Potential double-accounting (vegetation)
      
      The current formulation, which combines SVF and vegetation fraction (fveg), raises the question of whether the effect of vegetation on the urban heat island (UHI) signal is accounted for twice. It would be helpful to explicitly justify why these two terms appear together in the formula and to clarify the radius used to compute fveg. It should also be clarified whether fveg refers to trees only or includes low-lying vegetation too (or only), and whether SVF accounts for buildings and vegetation simultaneously.
   2. Spatial resolution of adjusted air temperature (Ta)
      
      While Figure 6 provides some indication, the spatial resolution of the adjusted Ta field is not clearly stated in the Methods section (2m?). Could a slightly coarser spatial resolution in fact be more appropriate for the UHI correction, given that micro-scale Ta variability can introduce noise rather than a meaningful signal at very fine resolutions?
   3. Day vs. nighttime diagnostics
      
      The decision to adjust Ta only for night-time conditions is well-founded, given that Ta is the dominant driver of heat stress during the night. However, a separate evaluation of day versus night Ta performance would be a valuable addition, as it would enable readers to better isolate the effect of the diagnostic correction.
   4. Nighttime cooling in open areas (Fig. 4)
      
      Figure 4 appears to show higher Ta values in open areas than in forested areas (e.g. the north-west). Since the UHI adjustment is only applied at night, open vegetated areas where [2 − SVF − fveg] approaches zero would be expected to cool more rapidly, showing a reduced or negligible UHI effect. It would be worth discussing whether this behavior is correctly captured by the current formulation. Where does the [2 − SVF − fveg] term come from?

1. Stratified evaluation by urban context
   
   Presenting the model–observation comparison stratified by land use or urban structure type would be particularly insightful. A breakdown along an urban–rural gradient or by functional zone (e.g. dense urban, suburban, park, peri-urban or canopy over and SVF) would reveal the areas in which the model performs well and where the diagnostic corrections have the greatest impact.

1. Wind speed comparison
   
   It is noted that 3.3 m wind observations are being compared with 10 m model output. For the sake of completeness, please clarify what the expected outcome would be if observations and model output were compared at the same height (e.g. 3 m). Reporting the R² value for wind speed would also be useful.

Additional comments:

• The observed shift in UTCI heat stress classes > 26°C appears to be driven primarily by the elevation-based Ta correction and wind attenuation. Is it possible to quantify the relative contributions of each component?
• The 10-cell padding corresponds to approximately 20 m at the stated grid spacing. Why was this threshold chsoen and are 20 m sufficient to avoid boundary artifacts in both SVF calculations and wind field estimations?
• In several figures, green and red color ramps are used in close proximity, which can make the plots difficult to interpret. Please revise the color scales to improve visual clarity and accessibility.