For most PALM-meteo plugins, the input data comes from either a forecast model or a (re)analysis. In either case, the input data may come from one or more forecast/data assimilation cycles. In the case of a forecast, the data are labelled by their cycle (typically the time of their last analysis) and the time of validity; the forecast horizon is the distance between the cycle and the validity time. For analyses divided into cycles spanning multiple times of validity, we use an equally defined horizon as a purely technical label.

The user's data archive may contain overlapping forecast/assimilation cycles (i.e., where the horizons are longer than the interval between the cycles). In that case, PALM-meteo allows a versatile selection of input data such that they form a continuous (equidistant) time series. Typical global or mesoscale numerical weather models use either four or eight cycles every day, starting at midnight UTC; the user may select all or a subset of cycles by specifying a regular cycle interval. In addition to that, the earliest usable horizon may be specified in case the early horizons should be disregarded as a model spin-up or stabilisation period.

If the input data contains temporal averages or accumulations that need to be temporally disaggregated for the use in PALM, the disaggregation is only valid between subsequent timesteps of the same cycle. In that case, one further (overlapping) horizon needs to be selected from each cycle to be used as the right-hand side of the disaggregation interval. See Fig.  as an example. Additionally, since the disaggregated values represent the centres of the intervals between timesteps, it is possible to either use one extra timestep before and after the simulation period for the disaggregated values, or to extrapolate these ends if the respective input files are not available.

Combining data from multiple forecast cycles is favourable for longer simulations, as it uses earlier forecast horizons that have lower forecast errors than later horizons. On the other hand, it may lead to unnatural jumps in the data at the seams between the cycles. For that reason, it may be preferred to use a single forecast cycle for shorter simulations if the available forecast horizons cover the full duration of the PALM simulation. The configuration allows to select a single cycle as an alternative to the cycle interval.

As a third option, the user may choose to ignore the forecast/assimilation cycle information and use all provided input files, assuming they already form a continuous time series.

By default, the initial conditions are provided as a full 3-D field, specified in the dynamic driver by assigning the value 2 to the lod (level of detail) attribute. PALM also supports 1-D vertical profiles, which are specified as lod=1. The 1-D profiles may be used for debugging PALM, or if lod=2 leads to unexpected errors. PALM-meteo supports creating these profiles as horizontal averages over the model domain using the pt (potential temperature), qv (humidity), and uvw (wind field) options in the output:lod configuration section.

An important issue when preparing all 3-D fields for IBC is the matching of vertical coordinates. Because the resolution of the PALM model and the resolution of input data (e.g., from a mesoscale model) differ greatly (typically by 3+ orders of magnitude), the representation of terrain height differs as well. Apart from different resolutions, other reasons for the difference in terrain height are different data sources and/or processing methods. Therefore, PALM-meteo needs to match vertical coordinates with a potentially different terrain height. This is done as part of vertical interpolation. In general, there are three possible solutions to match vertical coordinates:

Maintain level height (either as hydrostatic pressure or as height above mean sea level – a.m.s.l.), disregarding differences in terrain. This leads to major problems: when the target (PALM) terrain at a specific horizontal point is lower than the terrain in the input data, the values between the two terrain heights need to be extrapolated; in the opposite case, the data between the two terrains are discarded. Any surface-related effects, such as wind drag or strong vertical gradients in temperature and humidity, will be positioned improperly.

The vertical adaptation method in PALM-meteo was initially inspired by the hybrid vertical levels in the WRF model. WRF uses either the sigma levels, where each level is defined by a constant ratio between the model top pressure and the surface hydrostatic pressure at each grid point, or the hybrid levels, which are isobaric above a certain level and gradually transition to terrain-following below that level. For the WRF model, PALM-meteo allows the user to use an analogous method for the vertical adaptation (such as if the terrain in WRF was changed internally to match the PALM terrain). By selecting the adequate choice sigma or hybrid for the configuration option wrf:vertical_adaptation, depending on the WRF setup, PALM-meteo loads the corresponding level metadata from the WRFOUT files and shifts the levels accordingly as part of the vinterp stage.

However, these two methods are only applicable to WRF data. In addition to that, both the sigma and hybrid methods typically leave too strong horizontal gradients for PALM configurations with resolutions in the order of metres and with coarse terrain. To counter that, a third method called universal has been implemented. This method uses user-specified transition level (configured as vinterp:transition_level)

In the next step, the vertical interpolation of the 3-D fields together with terrain matching and vertical adaptation is performed for each PALM grid column linearly on the pressure coordinates, where the shifted pressure p̃lnW of WRF level n is calculated as 2p̃lnW=plnW-ptpsP-ptpsW-pt+pt,if  plnW>ptplnW,if  plnW≤pt where plnW is the original WRF level n pressure, psW is the WRF surface pressure, psP is the pressure corresponding to the PALM terrain and pt is the transition level pressure (the upper stretching limit), which is taken from the average pressure at the configured height above the highest obstacles (terrain, buildings or plant canopy) in the domain. The corresponding option transition_level has a default value of 300 m, but if the user can assess the height at which the effect of surface friction is no longer apparent in the context of relevant weather and surface roughness, it is recommended to specify this. An example of the universal vertical adaptation method is presented in Fig. . In this setup for Prague, the transition level was set to 2179 m a.m.s.l., so the WRF layers above that are unchanged and the layers below shift progressively to match the more detailed terrain.

For large simulations, the vertical interpolation is typically the longest stage of PALM-meteo processing due to the simple fact that it processes the largest amount of data (full 3-D fields on the fine PALM grid). PALM-meteo currently offers three different implementations of the actual vertical interpolation routine, and the user may select the preferred implementation using the configuration option vinterp:interpolator.

The metpy interpolator is the legacy option which uses the interpolate_1d function from the MetPy library, which is an optional dependency. In most cases, this is the slowest implementation.

The prepared interpolator is the default option. It is fully implemented in Python (NumPy) within PALM-meteo, and it works in two stages: first, it calculates and stores the interpolation weights based on source and target vertical coordinates, and then it uses these weights to perform the linear interpolation, which is done repeatedly for all fields to which those vertical coordinates apply. This interpolator is typically much faster than metpy.

The fortran interpolator uses a Fortran routine that needs to be compiled into native code using the f2py tool, which is shipped with NumPy (a dependency of PALM-meteo). This interpolator is by far the fastest of the three and should be preferred for large scenarios, if possible.

For vertical interpolation of the wind components u, v, and w, the vertical interpolation is linear by default, which should be sufficient for most scenarios. It is also possible to interpolate between the source model levels using the wind profile power law. This law is normally used for estimating horizontal wind speed at height z from the wind speed ur at the reference height above ground zr using the formula 3u=urzzrα.

This method may be generalised for interpolation at height zm between levels zb and zt with wind speeds ub and ut respectively: 4um=ub+ut-ubzmα-zbαztα-zbα which is equivalent to the original formula () in the case where the bottom level is the ground (ub=zb=0).

This method is intended for special cases, such as fine-resolution small-scale scenarios where there are insufficient near-surface vertical levels in the input data. In that case, the user needs to estimate the appropriate value of α (e.g., α=0.143), set the configuration of vinterp:wind_power_law to that value and check the results for inconsistencies.

When the dynamic driver is created, the cumulative inflow of air mass may not always equal the cumulative outflow for several reasons:

The input data (e.g., from the mesoscale model or manually prescribed profiles) need not be mass-balanced at the selected PALM boundaries, either due to the elasticity of the mesoscale model or due to the nature of the manually prescribed data.

There are two available approximation systems for the flow equations in the PALM model. Both of them are incompressible; they do not consider the dynamic change of air density. The Boussinesq approximation, which is the default, assumes constant background air density across the whole simulated domain (only the influence mediated by potential temperature is considered). The other option, the anelastic approximation, assumes a fixed, horizontally constant air density profile.

PALM needs to ensure mass balance at all times. When offline nesting is enabled in PALM, this is performed at each timestep after applying the temporally interpolated boundary conditions by adding or subtracting the residual mass flux in the form of a constant vertical speed difference at the top boundary. This approach is simple, but limiting it to the top boundary means that the applied speed difference may be relatively high if the residual flux is high or if the aspect ratio of the domain is very high.

In order to remove most of the residual flux (points 1–3) in advance, PALM-meteo performs mass balancing by default as part of the last step when the dynamic driver file is written. Unlike the balancing method in PALM, this method distributes the residual flux evenly to all five borders. Thanks to the larger total border area, this method leads to smaller added speed differences.

The user needs to specify the planned approximation method for the PALM simulation using the configuration option simulation:approximation. For each of the five boundaries, PALM-meteo calculates the grid cell border area (taking into account the vertical stretching, if configured). At the lateral boundaries, PALM-meteo uses the terrain and building data provided by the static driver setup plugin (see Sect. ) to identify the atmospheric (unblocked) border grid cells where the adjustment can be performed.

The residual mass flux (positive for inflow, negative for outflow) is calculated as 5ΔMI=∑B∑ijQB,i,jIρi,j with the volumetric inflows for the individual grid cell boundaries defined as 6QB,i,jI=-Vi,NY,jAn,i,jBif  B=n (north)Vi,0,jAs,ijBif  B=s (south)-UNX,i,jAe,i,jBif  B=e (east)U0,i,jAw,ijBif  B=w (west)-Wi,j,NZAt,i,jBif  B=t (top), where B∈{n,s,e,w,t} identifies the respective lateral or top boundary, i and j index the individual grid cells adjacent to that boundary, and AB,i,jB is the area of the boundary represented by that grid cell. Ui,j,k, Vi,j,k, and Wi,j,k are the wind components, and the NX, NY, and NZ are the grid sizes in the respective dimensions. The air density ρi,j is used only in the case of the anelastic approximation.

Finally, the wind speed adjustment (positive for inflow), which is added to or subtracted from the corresponding boundary wind speed components as in Eq. (), is calculated as ΔMIABρ where AB=∑B∑i,jAB,i,jB is the total area of all five boundaries.

PALM-meteo has the option of verifying the mass balancing by recalculating ΔMI after its application; this prints a negligible non-zero value, which is the result of floating-point rounding errors.

Upon loading the chemical input data, PALM-meteo performs automatic parsing and conversions of the decimal factors of the most commonly used units: ppmV, ppbV and µg m⁻³, g m⁻³, kg m⁻³.

However, this system is not well-suited for converting between molar fractions or volume concentrations (which PALM's chemistry module expects for gas-phase species) and mass concentrations (which PALM expects for non-gas-phase species, i.e., aerosols). The reason is that upon loading the chemistry input data, the precise air temperature and pressure are not yet known (they may already be loaded, but if they come from a separate meteorological model, they may be on a different grid).

This information is available on the PALM grid later in the last workflow stage, after the horizontal and vertical interpolation; therefore, the final unit conversion for chemistry is performed by the standard write plugin. Each time a quantity is marked as gas-phase (the attribute non_gasphase is false or missing) and it is provided as a mass concentration, its configured molar mass is used for conversion at the last stage.

Finally, in the very special case where the nitrogen oxide sum (NO_x) is requested to be calculated as a sum of nitric oxide (NO) and nitrogen dioxide (NO₂) and those quantities are provided as mass concentrations, they need to be converted to volume concentrations using their respective molar masses before the summation. In order to achieve that, there is a special option postproc:nox_post_sum which performs the summation of listed variables after their respective unit conversions.

This is currently the only way that PALM-meteo can perform the setup stage. This module loads a valid PALM static driver (by default taken from its standard PALM input file path) and sets up the following domain properties:

horizontal domain structure (placement, geographic projection, and resolution),

The specification of buildings in the PALM static driver provides several options, which makes it nontrivial to interpret the building data identically to how the PALM model does that. There are three main NetCDF variables which specify building data: building_id

is an integer variable which, for each i,j coordinate, specifies the ID of the building on that point, thus separating the individual buildings horizontally.

All buildings in the scenario are described as either 2.5-D or 3-D; if both variables are present, then only buildings_3d is used.

The vertical placement of the buildings is complicated by the fact that both variables specify the building shape with respect to the underlying terrain. The terrain is described as 2.5-D in the real-valued variable zt, which for each i,j specifies the terrain height in metres relative to origin_z, therefore PALM needs to discretise the terrain according to the vertical grid spacing dz. PALM-meteo, as well as any tool which needs to interpret terrain and/or buildings from the static driver, needs to perform identical discretisation to avoid mismatches. The same discretisation applies to the building heights in buildings_2d, while the heights of the terrain and the building are combined after the discretisation, not before. Finally, it is defined that if not all i,j points in the same building ID have identical terrain height, then the highest of such points determines the vertical placement of the respective building.

PALM-meteo carefully replicates the described building placement mechanism from the PALM model in order to identify buildings as obstacles for mass balancing (Sect. ) and for the wind damping mechanism (Sect. ). If there is a large number of individual buildings, this may slow down processing, as the horizontal grid mask needs to be processed for each building separately.

The WRF model is a state-of-the-art mesoscale numerical weather prediction system designed for both atmospheric research and operational forecasting applications. It features two dynamical cores, a data assimilation system, and a software architecture supporting parallel computation and system extensibility. The model serves a wide range of meteorological applications across scales from tens of meters to thousands of kilometres. The WRF development began in the latter 1990s as a collaborative partnership of the National Center for Atmospheric Research (NCAR), the National Oceanic and Atmospheric Administration (represented by the National Centers for Environmental Prediction (NCEP) and the Earth System Research Laboratory), the U.S. Air Force, the Naval Research Laboratory, the University of Oklahoma, and the Federal Aviation Administration (FAA). Nowadays, the WRF model is probably the most used model among scientists worldwide.

This was the first input module for PALM-meteo, created as a rewrite of the older WRF_interface tool, providing a full-featured replacement for the now-deprecated tool.

The recommended grid projection for using the WRF-ARW model in mid-latitudes is the Lambert conformal conic (LCC) projection. However, for the LCC projection, WRF does not use the standard WGS84 ellipsoid with a≈6378.1 km and b≈6356.8 km, but rather a computationally simpler sphere with r=6370 km . In addition, when the WRF inputs are prepared using the built-in WRF Preprocessing System (WPS), any WGS-84 georeferenced input data are used directly as if they were referenced in the spherical coordinates, bypassing the conversion of geodetic latitude.

This approach is acceptable as long as the WRF outputs are treated in the same way – the XLAT and XLONG fields in the WRFOUT files do match the placement of the model grid. However, if somebody uses the LCC projection parameters from WRF to define the projection and then transforms the coordinates using a library that performs geodetic latitude conversion, such as the PROJ.4 library , this leads to errors in latitude in the order of tens of kilometres. To avoid these errors, the conversion must not be done between the WRF LCC projection and the WGS84 (EPSG:4326) coordinates, but rather between the WRF LCC projection and the corresponding spherical coordinates. PALM-meteo uses this method to avoid the errors in latitudes. In addition, it allows to verify the projection parameters using the hinterp:validate option, available for all PALM-meteo input plugins.

The WRF radiation plugin imports radiation data from the specified WRF output files. These may or may not be the same WRFOUT files used for atmospheric variables. If the main output file interval is 1 h, it is recommended to configure WRF to produce the AUXHIST files with radiation variables in a finer temporal resolution (e.g., 10 min).

There are multiple optional radiation modules in WRF, and some of these produce radiation outputs in different variables, so the variable names in PALM-meteo are configurable. The WRF files need to contain shortwave and longwave horizontal irradiance (marked in WRF as downward radiation) and, optionally, the diffuse component of the shortwave horizontal irradiance. If this component is not present, it is skipped from the dynamic driver, and the PALM radiation module uses its internal estimation of the direct/diffuse ratio.

The ICON (ICOsahedral Nonhydrostatic) modelling framework is a joint project of Deutscher Wetterdienst (DWD), Max-Planck-Institute for Meteorology (MPI-M), the German Climate Computing Center (DKRZ), the Karlsruhe Institute of Technology (KIT) and the Center for Climate Systems Modeling (C2SM) for developing a unified next-generation global numerical weather prediction and climate modelling system. ICON represents a flexible, scalable, high-performance modelling framework for weather, climate and environmental prediction. Its results provide actionable information for experts and wider society, and advance understanding of the Earth's climate system.

The ICON modelling framework offers a wide range of applications across all temporal and spatial scales. ICON can be used for global and regional numerical weather prediction as well as for global and regional climate simulations.

The ICON model utilises an icosahedral-triangular grid for its geographical projection rather than a traditional latitude-longitude grid. This grid is constructed by successively dividing the faces of an icosahedron, resulting in a mesh of triangular elements. The grid generation starts with an icosahedron inscribed in the sphere. Connecting the 12 vertices of the icosahedron with geodesic lines yields 20 equilateral spherical triangles with an edge length of about 7054 km. Iterative subdivision (e.g., bisection or trisection) of the triangle edges then yields a model grid with the desired spatial resolution. The effective mesh size of the model grid is defined as the square root of the mean area of the spherical triangles. In the current operational version, the global ICON grid has 2 949 120 triangles, corresponding to an average area of 173 km² and thus to an effective mesh size of about 13 km. All scalar prognostic model variables (e.g., temperature, density, moisture quantities) are located in the circumcenter of the triangles, whereas the edge-normal wind components are located in the edge midpoints.

The most important ICON prognostic variables are air density and virtual potential temperature (which allows diagnosing the pressure), horizontal and vertical wind speed, humidity, cloud water, cloud ice, rain, and snow. These variables are calculated for all grid cells at 90 terrain-following model levels extending from the surface to a height of 75 km, yielding a total of about 265 million grid points. Over land, additional prognostic equations are solved for soil temperature and soil water content for 7 soil levels.

PALM-meteo uses NetCDF files for the ICON input data. These can be provided directly by the PAMORE (PArallel MOdel data REtrieve from Oracle databases) service, or they can be obtained by converting the ICON GRIB files to NetCDF using Climate Data Operators CDO;.

For horizontal interpolation, PALM-meteo first performs Delaunay triangulation of the ICON grid points using the SciPy library , which itself uses the implementation from the QHull library . Then it calculates the barycentric coordinates of the PALM grid points within each triangle and uses them as interpolation weights, as demonstrated in Fig. . This method is part of the PALM-meteo plugin library and is usable with any input grid described solely by the geographical coordinates of each grid point, including unstructured grids.

The DWD maintains an archive of ICON model data with multiple datasets from the ICON model analyses and forecasts. These datasets vary in the model variables they include and the duration for which they are kept in the archive. PALM-meteo can be used with both analysis and forecast data, but some DWD datasets do not contain all the variables required for PALM, such as the vertical velocity component.

The ICON variables, which remain constant for the duration of one forecast (one assimilation cycle), such as the vertical structure of the model levels, are included only in the first file for each forecast. PALM-meteo can be configured to generate a dynamic driver which spans multiple ICON forecasts as described in Sect. ; in that case, it always loads the model level heights from the first (zero-horizon) file of each cycle, even if the specified earliest horizon is higher (i.e., the file is disregarded for other data).

Generating radiation inputs for PALM requires at least the shortwave and longwave horizontal irradiance, with an optional direct component for the shortwave irradiance. Unfortunately, most ICON outputs available from the DWD archive using PAMORE lack the downward longwave radiation, with only the net radiation available. Because the net radiation Φd=Ee-Je, where Ee is the received (downward) radiant flux and Je is the leaving (upward) flux, PALM-meteo uses the Stefan–Boltzmann law to calculate the downward flux: 7Φd=Ee-Je=(Ea+Er)-(Me+Er)=Ea-MeΦd=εEe-εσT4Ee=Φd+εσT4ε where Ea is the absorbed flux, Er is the reflected flux, Me is the emitted flux, ε is the surface emissivity, T is the surface temperature and σ is the Stefan–Boltzmann constant. All fluxes refer to the longwave band. The surface emissivity for each grid point in the ICON model is constant in time unless that area has snow cover (which is currently unsupported by PALM-meteo). It needs to be loaded from a separate file containing the static model fields.

The Aladin (Aire Limitée Adaptation dynamique Développement InterNational) model was proposed by Météo-France in 1990 to build a mutually beneficial collaboration with the National Meteorological Services of Central and Eastern Europe. This collaboration results in Aladin running in operational mode in the Czech Hydrometeorological Institute (CHMI) and providing 3 d forecasts for a large part of Europe. The model assumes that the important meteorological events at those fine scales (local winds, breezes, thunderstorm lines, …) are mainly the result of a so-called “dynamical” adaptation to the characteristics of the Earth's surface. The model running at CHMI has a spatial resolution of 2.3 km in 87 vertical layers, coupling global models ARPEGE (Météo-France) and European Centre for Medium-Range Weather Forecasts' (ECMWF) Integrated Forecasting System (IFS). Since 2025, its results have been publicly available on the server https://opendata.chmi.cz (last access: 28 April 2026) with the metadata integrated within the National Open Data Catalogue NKOD; and the geospatial data in the Czech National Geoportal INSPIRE (https://geoportal.gov.cz, last access: 28 April 2026).

The ALADIN plugin supports input files in the GRIB and GRIB2 formats. It was implemented with an extra data import step at the beginning, which converts the data into a temporary NetCDF file, which can save time when multiple datasets are prepared from the same inputs. In the future, this extra step will be eliminated.

The Aladin data from CHMI are provided on a regular grid in the LCC projection. PALM-meteo uses bilinear horizontal interpolation and supports also radiation inputs, including the direct component of the shortwave radiation. However, as these inputs are provided only at 1 h temporal resolution, the PALM simulations need to be monitored for artefacts related to the direct radiation near the horizon around sunrise and sunset.

The CAMx plugin provides chemistry inputs from the CAMx chemical transport model. CAMx (Comprehensive Air Quality Model with Extensions) is a widely used Eulerian photochemical modelling system for gas and particulate air pollution. It allows for an integrated assessment of gaseous and particulate air pollution across many scales, from urban to regional. It has been developed since 1996 by Environ (currently part of the Ramboll company) under an open-source licence and has been employed extensively by government agencies, academic and research institutions, and private consultants for regulatory assessments and scientific research.

The CAMx model takes meteorological data from a meteorological model (e.g., WRF) and emission inputs provided by an emission modelling system (e.g., SMOKE or FUME) and provides fields of pollutant concentrations.

When the CAMx data is used in PALM-meteo, no assumptions are made about the relation between the meteorological and chemical inputs for PALM-meteo; therefore, PALM-meteo also supports the case where the CAMx model simulation was based on different meteorological inputs, and consequently on a different model grid. Still, if the configuration option camx:uses_wrf_lambert_grid is enabled, PALM-meteo assumes that the CAMx data are placed on a grid using the LCC projection from WRF (see Sect.  and interprets the projection metadata accordingly. In that case, it uses bilinear horizontal interpolation. If the option is disabled, PALM-meteo cannot make any assumptions about the model grid and the projection on which it is based, so it uses the latitude and longitude NetCDF variables for georeferencing input data, and it performs the barycentric interpolation on a triangulated grid as in ICON (Sect. ).

The PALM chemistry module takes advantage of the Kinetic PreProcessor KPP; see, which offers multiple chemistry mechanisms with flexible configuration. As a result of that, the potential sets of IBC variables with chemistry species concentrations may be very different depending on the PALM KPP configuration, starting from simple passive tracer simulations with, e.g., aerosols (PM₁₀, PM_2.5) and/or typical pollutants (NO_x, SO₂) through mechanisms with simplified basic chemistry to very complex chemical mechanisms with tens of species, such as Carbon Bond 4 CB4; see.

The global or mesoscale chemical transport models may not always provide the exact set of concentration variables needed for PALM; often, it may be necessary to perform simple calculations such as unit conversions, summing up of species (e.g., NO_x from NO₂ + NO₃) or splitting by a ratio. PALM-meteo offers a flexible configuration system to specify chemical IBC species and to perform these calculations when required.

The main configuration for this purpose is the list of output chemical variables (empty by default when chemistry is disabled). Each output variable needs to have a definition with the list of input variables, the formula for calculating the output value from the input values, the output unit of the calculated value, and an optional list of assertions to be checked with the input variables. If the formulae for multiple variables contain an identical term, it is possible to configure it as a preprocessed value to avoid its repeated computation. Such definitions are provided for some commonly used chemical mechanisms (36 commonly used chemical species), but these can be easily extended and/or overwritten by the user. In addition to that, simple unit conversions are handled automatically as described in Sect. .

This configuration mechanism, which utilises different lists of predefined variables, is employed in all chemical plugins within PALM-meteo.

Copernicus Atmosphere Monitoring Service (CAMS), and its implementation in the ECMWF's IFS, provides operational daily analysis and forecast of aerosol optical depth (AOD) for five aerosol species using an online integrated module for aerosol and chemistry coupled to IFS (C-IFS). A fully prognostic aerosol model has a significant impact on weather forecasts in cases of large aerosol concentrations, as observed during dust storms or intense pollution events.

The CAMS reanalysis datasets include: (i) the CAMS global reanalysis (EAC4), which currently covers the period from January 2003 to December 2024; (ii) and CAMS global greenhouse gas reanalysis (EGG4), which currently covers the period 2003–2020.

The CAMS reanalysis is the latest global reanalysis data set of atmospheric composition (AC) produced by the Copernicus Atmosphere Monitoring Service, consisting of 3-dimensional time-consistent AC fields, including aerosols, chemical species and greenhouse gases, through the separate CAMS global greenhouse gas reanalysis (EGG4). The data set builds on the experience gained during the production of the earlier MACC reanalysis and CAMS interim reanalysis.

The CAMS reanalysis was produced using 4DVar data assimilation in CY42R1 of ECMWF's IFS, with 60 hybrid sigma/pressure (model) levels in the vertical, with the top level at 0.1 hPa. Atmospheric data are available on these levels, and they are also interpolated to 25 pressure, 10 potential temperature and 1 potential vorticity level(s). “Surface or single-level” data are also available. Generally, the data are available at a sub-daily and monthly frequency and consist of analyses and 48 h forecasts, initialised daily from analyses at 00:00 UTC.

PALM-meteo supports CAMS outputs in the NetCDF format with the regular latitude–longitude grid (equirectangular projection). The mechanism for species calculations and unit conversions, as described in Sect. , is also used. The configuration is available for NO, NO₂, O₃, PM₁₀ and PM_2.5 and the postprocessing sum may be used to calculate NO_x.

The synthetic input PALM-meteo plugin differs significantly from the other input plugins as it does not use meteorological data from any specific (mesoscale) model. Its goal is to enable simple and flexible creation of synthetic IBC by specifying vertical profiles and/or timeseries within the PALM-meteo configuration file, taking advantage of other PALM-meteo features, such as the vertical adaptation method (Sect. ).

Vertical profiles of time-dependent variables can be set in the configuration section synthetic:prof_vars. A list of vertical profiles for velocity (u, v, w), potential temperature (θ), water vapour mixing ratio (q), soil temperature (tsoil) and moisture (qsoil) together with a list of heights for the profiles in meters above origin_z (or below for soil variables) can be prescribed.

Each vertical profile may be listed as constant or as a sequence of profiles with assigned times. In addition, the profiles in the sequence may be repeated and/or permuted by specifying their timeseries section, which simplifies creation of, e.g., multiple daily cycles.

This approach offers a more generic and flexible alternative to prescribing profiles via the PALM's PARIN (_p3d) namelist file. It enables time-dependent Dirichlet boundary conditions for all of u, v, w, θ, q and for the soil variables. Unlike PALM's built-in options set_constant_profiles and set_1d-model_profiles, this method offers more precise meteorological inputs, such as prescribing the full potential temperature profile rather than just setting a vertical gradient.

As the dynamic driver inputs are hydrostatic, pressure is prescribed as a single value; either for the surface pressure or the sea-level pressure, which is then converted to origin_z.

There is no verification whether the provided input data are physically consistent. Prescribing unrealistic values, such as large negative vertical gradients of θ, may lead to unrealistic or even crashed PALM simulations.

Because the terrain matching and vertical adaptation method (Sect. ) purposely ignores buildings and the mesoscale models in general cannot resolve such fine-scale details, the interpolated wind field for the initial conditions generated by PALM-meteo may contain a wind field that seems to enter and leave solid obstacles, thus creating velocity divergence. This is expected, and PALM solves this in its first timestep; however, it may negatively affect the convergence of the pressure solver, especially when the buildings contain narrow gaps which may not be (entirely) removed by PALM's terrain filtering.

PALM-meteo contains a plugin for damping the initial-condition wind near walls in a post-processing step. Depending on the configuration, it zeroes the U, V and W fluxes in one or more grid cells adjacent to the vertical walls and then linearly increases the wind damping factor from zero to one at a configured horizontal distance from the wall, from where onward the wind field remains unchanged. This process does not remove the velocity divergence of the initial wind field, but it has been tested to make the PALM's multigrid pressure solver converge faster.

The plotting plugin generates graphical plots of any output variables (by default the wind speed + direction, potential temperature, and humidity). These plots are generated as heat maps with the y-axis representing height (above the origin height) for a selected location (centre of domain by default), the x-axis representing time and the colour representing the magnitude of the specific variable. They are useful for quick analysis of the meteorological inputs and their suitability for the intended PALM simulation, e.g. the wind speeds at all heights or the diurnal cycle of the convective boundary layer. The plots are generated at the write stage, utilising the full 3-D data for all times from the previous vertical interpolation stage. An example of wind speed and direction is available in Fig. .