We would like to thank the Reviewer for very insightful comments and suggestions. We have revised the paper according to them. In the following text, we will address individual comments.General comments:

1. The topic is timely and valuable, and the development effort is highly appreciated. However, the manuscript often reads like user documentation, with detailed procedural descriptions that are not essential for a research paper. I suggest streamlining the main text to emphasize scientific motivation, methods, validation, and results, and moving operational instructions (installation, setup, exhaustive configuration options) to supplementary material or the project’s code repository.

We appreciate these insights and we agree that some sections were too technical. As suggested, we have moved some parts to the Appendix and restructured the text to be more focused.

1. The manuscript does not specify how meteorological variables are treated in the near‑surface gap below the first model level in the 3‑D data. Please clarify whether PALM‑meteo uses mesoscale model surface diagnostics (e.g. 2 m temperature) or whether values are extrapolated from the lowest model level to the ground. If a specific filling or blending method is applied (e.g., log‑law/profile fits or use of surface diagnostics), summarize it in the Methods section. If no special treatment is applied, explain and discuss possible implications for PALM simulations.

In most usages, PALM-meteo provides boundary conditions from mesoscale models to microscale PALM simulations. Considering the large gap in resolutions (typically units of kilometres versus units of metres), the microscale simulations need both a temporal spin-up after the initial state as well as a large spatial border at the windward side such that the microscale model can develop realistic flow with appropriate resolved and subgrid-scale turbulence (typically several hundred metres or several kilometres for moderate wind speeds). To save computational resources, this is typically accomplished by having a larger parent domain with coarser resolution into which the fine-scale domain for the area of interest is nested (the nesting may be multi-level). The Synthetic Turbulence Generator in PALM does help with the inflow turbulence, but it does not completely alleviate the need for sufficient border area. Having this in mind, PALM-meteo uses only interpolation and extrapolation of the input vertical levels, it does not perform any surface diagnostics and leaves this development to the inflow border area of the PALM model domain. The relevant text in the paper has been updated accordingly.

1. The manuscript would be strengthened by a dedicated results/validation section showing PALM simulations prepared with PALM‑meteo. Useful additions would include a sensitivity analysis comparing PALM outputs obtained with different meteorological inputs or a demonstration of how the new PALM‑meteo features improve PALM results compared with earlier preprocessing approaches. Where possible, compare model outputs to available observations for validation (e.g. 10 m wind and 2 m temperature). If new simulations are not feasible, please summarize and re‑evaluate the previously published PALM studies that used PALM‑meteo or extend the already provided example cases. These additions (or a clear justification why they are omitted) would make the manuscript’s scientific contribution more convincing.

Although we believe that the referenced studies sufficiently evaluate PALM simulations using PALM-meteo inputs, we agree that they were not sufficiently summarized. We have added a summary of the study in Radovic et al. (2024), which is most focused on driving meteorological conditions, in Section 1.5, and we have extended the explanation about not including another PALM validation simulation in Section 3.Specific comments:

1. Abstract: The abstract describes PALM‑meteo’s capabilities well but would be stronger if it reported at least one concrete result that illustrates the tool’s scientific or practical impact. Please add a brief outcome from the manuscript (for example, a validation metric, an improvement relative to a previous preprocessing approach, or a result from one of the two example case studies) so readers immediately see the tool’s benefit.

The abstract was extended with a list of models supported by PALM-meteo as inputs for the dynamic driver. A short list of studies in which PALM-meteo was used was added to the abstract.

1. Line 83 – The subsubsection heading "1.3.1 PALM dynamic driver" appears unnecessary because it is the only child heading under 1.3.

Thank you for noticing, the sub-section (now part of 1.3) was omitted and the common title was adapted.

1. The material in subsection 2.1 (Previous studies using PALM‑meteo and its predecessors) reads as background and would be better placed in the Introduction and substantially condensed. In particular, operational/disclaimer details about the PAMORE name and the split with DWD are not scientific content and are more appropriate for the code repository, a short footnote, or the Acknowledgements than for the main text. I suggest the authors merge a short, focused summary of prior applications into the Introduction (for example: “PALM‑meteo evolved from the WRF_interface and has been used in urban studies …) and remove subsection 2.1.

We have relocated the entire subsection to the introduction (now Subsec. 1.5) and we tried to condense the content as much as possible. The initial collaboration related to the PAMORE project is still acknowledged, but now only briefly in a single sentence as part of the background context.

1. Line 107 contains a typographical error: “Detsche Wetterdienst” should read “Deutscher Wetterdienst (DWD)”.

We have corrected the error.

1. Line 121 – Please avoid mentioning unpublished studies unless they are directly relevant and publicly accessible.

The sentence was indeed misleading. We have rephrased it so that it only states that there is no such study available currently.

1. Figure 1: This figure would benefit from an expanded caption and clearer labelling. Please add subcaptions (a–c) describing each panel, label key elements in the images (e.g., the rectangle in the left panel or the meaning of the boxes in the middle panel) and explain the meaning of the right panel. Also refer explicitly to the panels in the main text so readers know what to look for.

Thank you for your comment. We have altered the figure to better illustrate the respective processes and expanded the caption.

1. Line 123: Section 2.2 is very implementation‑centered and could be substantially condensed in the main text. For a more detailed description, either supplements, documentation or code repository are better suited.

We agree that this part was too technical. We have moved the Section 2.2 to Appendix and restructured the text so that it is more focused.

1. Line 240: Replace “The simple profiles …” to “The LOD=1 profiles …” or “1D-profiles”, otherwise it is not clear what is meant by “simple profiles”.

Corrected.

1. Page 12: The current version of Figure 4 is hard to interpret: the panels lack (a–c) labels and the font size in the panels is too small. Please add panel labels and increase the font size.

We have rearranged Figure 4 in the revised manuscript.

1. Line 291: The claim that “linear interpolation” is inconsistent across MetPy versions is surprising: a straightforward linear interpolation on identical inputs should be reproducible. If the authors observed differences, this likely indicates version‑specific bugs. Please document the observed behavior in the code repository or user documentation, and remove the statement from the manuscript, since it is not a scientific result on its own.

We have documented cases where the results of the linear interpolation using MetPy were repeatedly significantly inconsistent among MetPy versions and even among different computing environments with identical MetPy versions. However we agree that this is only a technical question and its documentation would clutter the paper unnecessarily, so we decided to remove this statement.

1. Line 300: The wind‑profile power law is generally valid only very near the surface and, even there, provides a rough empirical estimate that is most appropriate under near‑neutral conditions. Please justify the physical validity of applying the power‑law interpolation at the higher levels as discussed here. Did you visualize the resulting profiles to check for discontinuities or abrupt gradients where piecewise functions are joined?

We expect that for most applications, the users will apply the default linear interpolation, which is least prone to unexpected behavior. As was mentioned in reply to General comment 2, this should be sufficient for typical PALM simulations which need to employ long inflow borders anyway. In any case, the general shape of the profile must be provided by the input model with sufficient number of vertical levels; the interpolation is never expected to change the overall shape of the profile.The alternative modified power-law interpolation which is described in the paper was added for special cases, such as fine-resolution small-scale scenarios with rather few input vertical levels very close to the surface. Another reason why we chose the power law over log wind profile was that it was possible to adapt the formula from the original form which extrapolates from single height to the modified form which continuously interpolates between two specified heights and wind speeds. Such a simple adaptation was not possible for the log wind profile. The adapted formula guarantees continuity, but it may indeed lead to abrupt changes in gradient, which is however also the case for linear interpolation. As long as the second derivative of the wind speed with respect to height is negative, this change in gradient will be lower than with linear interpolation. As it is meant for special cases, the outcome needs to be considered by the user.We have adapted the text to better describe the expected use cases, the behavior of the interpolation and expected outcomes.

1. Line 322: Replace “in the PALM” to “in the PALM model”.

Corrected.

1. Pages 23—26: The results shown in Figures 6-9 are not discussed in the manuscript. Please add a concise interpretation pointing out the main findings. Where possible, support the discussion with quantitative metrics (e.g., bias, RMSE).

The main purpose of Section 3 is to illustrate typical scenarios that may be processed with PALM-meteo and describe computational and other requirements. As the only purpose of the PALM-meteo generated dynamic drivers is to provide inputs to the PALM model system, there is no objective measure against which they could be compared; the only available method of validation would be to evaluate the results of the PALM model simulations which used them as inputs. This type of evaluation was already part of the referenced study Radović et al., 2024 and partly also some other referenced studies (see Section 1.5). We acknowledge that this is an important aspect of PALM-meteo and for that reason we extended the overview of Radović et al., 2024 in Section 1.5. We also improved the phrasing in Section 3 to better describe the meaning and limitations of its contents.

We would like to thank the Reviewer for very insightful comments and suggestions. We have revised the paper according to them. In the following text, we will address individual comments.

1. Please extend the analysis of the example cases presented in Section 3. For example, in Figure 8 the lower parts of panels (a), (b), and (c) show significant differences. While the underlying reason is explained in Section 2.3.3, a more detailed analysis and discussion would improve clarity for the reader. Also, why vertical interpolators “prepared” and “metpy” are not included in Table 4 like in Table 2?

We agree that the message from these panels was missing and we have extended the discussion of their contents. Concerning vertical interpolators, we used all three in the Prague–Legerova domain to briefly demonstrate the difference in their performance, however as the Fortran-based interpolator is by far the fastest and it should be preferred wherever available, we used only that in the Guelph domain. We have described this more clearly in the revised text.

1. The Abstract is quite short and doesn’t properly communicate the newest capabilities of the tool. Please consider extending it by briefly describing the latest updates or upgrades and by a short overview of the most important conclusions that can be made based on the example use cases presented in Section 3.

We have updated and extended the Abstract to better communicate the properties and capabilities of PALM-meteo.

1. The abbreviation WRF should be explained in the Abstract. Also, please add the explanation at its first occurrence in the main text. Currently, the abbreviation is defined in Section 2.4.2 but used multiple times earlier in the manuscript.

Corrected.

1. Line 75: Please clarify what the abbreviation TKE stands for.

Corrected.

1. A brief introduction to the PALM model and its core capabilities would be beneficial for readers who are not familiar with the model. Especially, the temporal and spatial scales of the PALM model are important for the reader to assess the capacity of PALM-meteo in the correct context. This added information could be included in the Introduction or presented in a separate section. In case of introducing the PALM model in a separate section, Sections 1.2, 1.3, and 1.3.1 could be migrated under it.

We have added a description as recommended, in the revised manuscript it is Section 1.2 and the mentioned sections have been shifted so that they directly follow it.

1. The manuscript doesn’t mention what version of the PALM model the tool is intended for. Please clarify this point.

This is indeed a very important information which was missing in the manuscript. We have added it to the revised version at the end of Section 1.5.

1. Lines 131-132: Depending on the choice of interpolation methods, the order in which the interpolations are applied can matter (i.e. have different results). Is it possible to run the hinterp and vinterp stages in a different order if the user so desires?

It is indeed true that the order of interpolations (unless they are all linear) can lead to differences in results. In PALM-meteo, performing horizontal interpolation first before vertical was a clear design choice from the beginning for several reasons. The main reason is the fact that the vertical interpolation needs to work with PALM’s terrain which is typically orders of magnitude finer in resolution compared to the mesoscale model terrain, therefore the horizontal structure needs to be fine already when performing the vertical interpolation which has to account for the terrain. Having this order of operations fixed also brought advantages with respect to modularization (i.e. API and guaranteed states for plugins which may handle only one of the processes). We have extended the justification for this choice in the manuscript.

1. Line 142: This is an interesting memory-compute-tradeoff problem. I think that doing the end-to-end processing would likely be significantly faster, if the total data can be fit into memory at the same time. Nowadays HPC clusters can have hundreds of gigabytes of memory, so it would indeed be a possibility. Is the potential gain in compute speed too small that this end-to-end calculation is not desirable, or would you say that in most commonly encountered use cases fitting the whole data into RAM is unfeasible?

It is true that some scenarios could fully fit into memory, although the demands could be even higher than for the PALM model itself – if the data for all timesteps (and variables) were to be present at once due to interdependencies.However, being able to run on non-supercomputer hardware was one of the primary design goals of PALM-meteo. The authors believe that the supercomputer hardware for running the PALM model core has to be considered as expensive and scarcely available; not only due to the required amount of CPUs and memory, but also due to the need for fast interconnect among cluster nodes. Therefore, the time of usage of such complex infrastructure should be minimized (as it is often managed by batch systems with queues, time limits and quotas) and any pre- or post-processing task, which may be performed on simpler hardware, should use that opportunity.During testing, we regularly keep track of the time needed to save and load the temporary files and in most cases it is insignificant with respect to the full duration. We agree that a more detailed analysis of this aspect could demonstrate interesting results, however we also think that such analysis could lie outside of the scope of this paper.

1. Line 334: Boussinesq approximation assumes constant air density through the whole simulated domain. Since this is currently the only method implemented, it causes limitations on the vertical scale of the computation domain which PALM-meteo can support. Please elaborate on the errors caused by this approximation and the resulting limitations on the compute domain dimensions compared to the anelastic approximation.

In PALM-meteo, the approximation scheme is only relevant to the mass balancing routine, in which the air density profile must exactly match the profile used in the PALM simulation for which the dynamic driver is being prepared. So far all the PALM simulations for which the IBC were prepared using PALM-meteo employed PALM’s default Bousinesq approximation, therefore there was no need to support the anelastic approximation’s density profile in PALM-meteo. We would like to thank the reviewer for bringing attention to this limitation. Upon further consideration, we decided to implement the support for anelastic approximation, which is now available in the current version of PALM-meteo. The text in the manuscript was updated accordingly.

1. Line 585: The wind damping factor in each grid cell is computed from the horizontal distance to vertical walls. However, as described in Section 2.4.1, one can define buildings with holes or overhangs using the buildings_3d variable. Could the authors clarify whether such cases with horizontal walls, as well as building roofs, are sufficiently rare compared to vertical walls that they are not explicitly treated here, with PALM instead resolving the resulting velocity divergence?

The fully 3-D buildings defined using the buildings_3d variable (such as those with holes or overhangs) are fully represented in the wind damping plugin, just as the ordinary 2.5-D buildings. Indeed, the plugin only treats vertical walls and horizontal distances to them. It is true that also the horizontal building surfaces (both the regular upward oriented roofs and the downward oriented walls of the overhanging structures) can contribute to divergence due to non-zero vertical velocity adjacent to them (i.e. by representing the impossible flow into them or from them). However, as the near-surface vertical wind component in mesoscale models is typically 1-3 orders of magnitude smaller than horizontal wind speed and adequately smaller is also its potential contribution to the initial divergence in the presence of added obstacles, the horizontal walls were omitted for simplicity.