Processing an urbanized WRF run

Basically, the WRF framework includes 2 main components: a pre-processor (WPS) and a main processor (WRF). WPS aggregates the global ERA-Interim meteorological boundary conditions to the WRF-grid according to the spatial dimensions of the model domains, the vertical resolution, the geographical input data and the modelling period (August 11 – August 17 2003). Three basic programs are needed for data processing in WPS:

 Geogrid.exe generates a 2-dimensional geographical input file with the predefined horizontal dimensions

 Ungrib.exe transfers the ERA-Interim Reanalysis data files to a WRF readable format

6. The WRF model

57

 Metgrid.exe aggregates the vertical information from the meteorological boundary conditions to the horizontal WRF grid for each domain and daily time step.

A two way nesting approach to include three domains is defined with a horizontal resolution of 1 km and 36 vertical levels. The lowest model level accounts for an atmospheric layer of ~11 m depth. Any result of this work, which refers to this level, describes the average value for this column. For higher levels, the layers get thinner and the numbers approximately equal the ‘real’ height. The innermost domain covers an area of 64 x 49 grid cells within the urban area of Stuttgart (200 grid cells) and is located in the centre (Fig. 20). The basic settings of WPS are defined in the file ‘namelist.wps’(Appendix A.4). All times refer to GMT +2, daylight saving time for the Central Europe.

Fig. 20: Model domains 1,2,3 for the WRF run projected to UTM WGS84 Europe Zone 32N

In the following, the previously generated meteorological files are linked to the WRF main processor for real data applications (‘em_real’). It is mandatory at this point that the correct number of land use classes (33) has been set within an index file in the geographical data repository and within the general WRF configuration file ‘Registry.EM’ (num_landcat=33).

Within the main processor WRF, the meteorological boundary conditions are used to drive the mesoscale model. At this stage, the appropriate physical schemes are to be set in the configuration file ‘namelist.input’. The selection and combination of physical schemes defines the way the model solves the equations of motion and the calculation of output variables. Other specifications like modelling time steps, runtime, debugging mode or domain specifications are to be set here as well. The three parameter tables for vegetation, land use and urban characteristics are also introduced at this stage of the modelling. In order to save computing time, the urban canopy model is only applied within the third domain with the 1 km resolution. Next to general settings which are not to be discussed

6. The WRF model

58

into detail here, there are a number of configurations which have to be considered when using an urban canopy model in WRF. In particular, the setting up of the multi-layer canopy model ‘BEP’ requires the selection of specific physical schemes (Martilli 2002). In order to avoid strong oscillations that may arise due to changes in roughness at the border of the city, a 6th order filter is preferred. NOAH-LSM is the only land surface model which operates with the BEP. For calculating the planetary boundary layer, the Mellor-Yamada- Janjic (Hu et al. 2010) parameterisation is used to better represent the vertical structure of the urban atmosphere. Within this scheme, the PBLH is directly related to the turbulent kinetic energy term TKE. By this, it is defined as the height, were the TKE drops below 0.01 m-2s-2. Further specifications of the two urban canopy models can be found in (Martilli et al. 2009) and (Tewari, Chen, Kusaka, & Miao 2007). The urban canopy model in theory runs independently by using the meteorological information of the mesoscale model and urban parameters from the specific tables. Building and street parameters are defined on the urban grid with a horizontal resolution of 5 m and with a maximum of 13 vertical levels in the urban canopy. The terms of sources and sinks are calculated on the urban grid as well. Finally, the modified variables are re-interpolated to the mesoscale grid. Parallel with this, the NOAH land surface model calculates fluxes for natural surfaces. The modelling integration time step is set to 30 seconds with model output generated on an hourly basis. The final version of the WRF configuration file equals to that one of the chemical run (appendix A.6). The basic settings of the WRF run are presented in Tab. 5:

Tab. 5: Modelling setup used for meteorological part according to Skamarock et al. (2005)

The simulations for the meteorological part are performed on the IMK-IFU water and climate 64 bit high performance computing (HPC) cluster KEA, which is specifically designed for parallel applications. For compiling the WRF code and performing the control and the scenario runs, 48 central processing units (CPUs) of an AMB Opteron computer, type Magnycour are used. A regular urbanized WRF-run with three nested domains with a 1 km resolution for simulating a 7 day period is executed in about 8 hours computing time. The ratio between the computational and real-time hours accounts for ₂₁1.

Parameter/Scheme Specification Parameter/Scheme Specification Parameter/Scheme Specification

geographical input data 1km USGS land use lowest model level 10 m shortwave RRTMG dx, dy 15km, 3km, 1km meteorological BC 0.5 Deg ERA-Interim land surface model Noah LSM west-east [km] 750, 228, 61 time frame 8/11 - 8/17/03 urbanization scheme BEP/ SLUCM south-north [km] 600, 168, 49 microphysics Lin et al cumulus scheme Kain-Fritsch

6. The WRF model

59