PALM-meteo 2.6: Processor of PALM meteorological input data

Krč, Pavel; Belda, Michal; Bureš, Martin; Eben, Kryštof; Geletič, Jan; Radović, Jelena; Řezníček, Hynek; Resler, Jaroslav

doi:10.5194/egusphere-2025-4120

Preprints

https://doi.org/10.5194/egusphere-2025-4120

Preprints

11 Sep 2025

| 11 Sep 2025

PALM-meteo 2.6: Processor of PALM meteorological input data

Pavel Krč, Michal Belda, Martin Bureš, Kryštof Eben, Jan Geletič, Jelena Radović, Hynek Řezníček, and Jaroslav Resler

Abstract. PALM is a versatile and modular microscale atmospheric modelling system. It supports offline nesting using pre-processed initial and boundary conditions, which are provided via the dynamic driver file, along with other time-dependent input data, such as radiative forcing. PALM-meteo is a new modular tool for preparing the PALM dynamic drivers using data from various mesoscale or global meteorological models as well as other sources, such as measurements. It is derived from an older tool, the WRF_interface, which provided dynamic drivers from the WRF model data. PALM-meteo significantly expands the scope of usable meteorological inputs for PALM, and it is ready to be easily extended with more data sources in the future.

Received: 22 Aug 2025 – Discussion started: 11 Sep 2025

Publisher's note: Copernicus Publications remains neutral with regard to jurisdictional claims made in the text, published maps, institutional affiliations, or any other geographical representation in this paper. While Copernicus Publications makes every effort to include appropriate place names, the final responsibility lies with the authors. Views expressed in the text are those of the authors and do not necessarily reflect the views of the publisher.

Download & links

Pavel Krč, Michal Belda, Martin Bureš, Kryštof Eben, Jan Geletič, Jelena Radović, Hynek Řezníček, and Jaroslav Resler

Status: final response (author comments only)

RC1:
'Comment on egusphere-2025-4120', Anonymous Referee #1, 20 Oct 2025
Overview:
PALM-meteo 2.6 is a modular Python-based preprocessor that prepares PALM dynamic drivers from a variety of mesoscale/global models and other sources. Key capabilities include flexible plugin-based import (WRF, ICON, Aladin, CAMx, CAMS, synthetic), horizontal regridding, vertical adaptation (terrain matching with hybrid/sigma/universal methods), several vertical interpolators (NumPy, MetPy, Fortran), mass-balancing across boundaries, chemistry and radiation handling, and wind damping near walls. The manuscript documents architecture, configuration, workflows, gives 2 example applications (Prague and Guelph), and provides code and example data archives.
General comments:
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.

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.

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.

Specific comments:
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.

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

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.

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

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

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.

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.

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”.

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.

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.

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?

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

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).
Citation: https://doi.org/10.5194/egusphere-2025-4120-RC1
RC2:
'Comment on egusphere-2025-4120', Anonymous Referee #2, 29 Jan 2026
The authors present version 2.6 of the PALM-meteo tool, which is designed to prepare PALM dynamic drivers using data from different mesoscale and global meteorological models as well as some other data sources. The manuscript describes the tool, its key features, and presents two example case studies. The tool itself is impressive and the manuscript is suitable for the scope of GMD provided that several points are addressed. I have read the comments provided by Referee 1 (RC1) and fully agree with them. Therefore, I refrain from repeating the issues already raised by RC1 in my own comments.

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?

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.

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.

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

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.

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

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?

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?

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.

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?
Citation: https://doi.org/10.5194/egusphere-2025-4120-RC2

Pavel Krč, Michal Belda, Martin Bureš, Kryštof Eben, Jan Geletič, Jelena Radović, Hynek Řezníček, and Jaroslav Resler

Data sets

Dataset for paper PALM-meteo 2.6: Processor of PALM meteorological input data Pavel Krč, Martin Bureš, Jaroslav Resler, Michal Belda, German Meteorological Service, European Centre for Medium-Range Weather Forecasts https://doi.org/10.5281/zenodo.16925022

Model code and software

PALM-meteo: processor of meteorological input data for the PALM model system Pavel Krč, Martin Bureš, Jaroslav Resler, Michal Belda https://doi.org/10.5281/zenodo.16924719

Pavel Krč, Michal Belda, Martin Bureš, Kryštof Eben, Jan Geletič, Jelena Radović, Hynek Řezníček, and Jaroslav Resler

Viewed

Total article views: 1,575 (including HTML, PDF, and XML)

HTML	PDF	XML	Total	BibTeX	EndNote
1,283	264	28	1,575	24	27

HTML: 1,283
PDF: 264
XML: 28
Total: 1,575
BibTeX: 24
EndNote: 27

Views and downloads (calculated since 11 Sep 2025)

Month	HTML	PDF	XML	Total
Sep 2025	995	15	6	1,016
Oct 2025	117	24	6	147
Nov 2025	39	24	5	68
Dec 2025	39	52	5	96
Jan 2026	49	55	4	108
Feb 2026	43	83	2	128
Mar 2026	1	11	0	12

Cumulative views and downloads (calculated since 11 Sep 2025)

Month	HTML	PDF	XML	Total
Sep 2025	995	15	6	1,016
Oct 2025	117	24	6	147
Nov 2025	39	24	5	68
Dec 2025	39	52	5	96
Jan 2026	49	55	4	108
Feb 2026	43	83	2	128
Mar 2026	1	11	0	12

Viewed (geographical distribution)

Total article views: 1,638 (including HTML, PDF, and XML) Thereof 1,638 with geography defined and 0 with unknown origin.

Country	#	Views	%

Latest update: 02 Mar 2026

Short summary

PALM is a highly versatile open-source microscale atmospheric modelling system. One of its most useful applications is modelling detailed street-level urban climate, e.g. for evaluation of climate change adaptation and mitigation measures in cities. However, to produce real-case microscale simulations, they need to be forced by real or realistic weather conditions. The presented tool enables PALM to use meteorological inputs from a large selection of meteorological models and other sources.


Total:	0
HTML:	0
PDF:	0
XML:	0