An Introduction to Parameterization Options in WRF

This post is the first in a series about parameterization schemes in WRF. We hope they will help demystify the role these schemes play in the model, so that you can make a more informed decision about which schemes to use for your own run. This post provides a very brief overview; future posts will be a more detailed look at specific scheme categories.

To understand parameterizations, we first must discuss what a model does. According to Schwarz et al. (2009), models are representations that explain and predict a natural phenomenon. In the atmospheric sciences, accuracy of the model’s prediction is directly related to how well it represents atmospheric processes, which can be adjusted by choosing the best parameterization schemes for your research question. Every choice made changes the outcome of the model simulation. As a result, parameterization schemes are one of the most important aspects to consider when setting up a computer model.

Unfortunately, choosing the best parameterization schemes is also one of the most difficult steps of the model set up procedure because there is no single “best combination”; it depends entirely on the research question you chose, the location and size of your domain, and the resolution of your domain. Even after considering these options, some choices may still not be clear.

It is not hopeless, though! It is possible to make an informed decision on which parameters to use if you understand how the different schemes influence the model.

What do parameterization schemes do?

In very general terms, here’s how parameterization schemes in WRF work:

From our current understanding of atmospheric processes, atmospheric scientists have derived several equations that describe dynamic and physical processes. In a basic sense, weather is created when there is uneven heating, creating regions of relatively warm and cool temperatures, which causes air to move (or be transported). On a spherical planet with no water or vegetation, this simple model description is probably pretty representative of how the atmosphere behaves. However, on a planet like Earth, more equations are need in order to take into account things like oceans, mountains, ice, plants and animals.

In fact, there are so many different influences and interactions to consider, that many equations are needed. Therefore, parameterization options are generally broken down into categories. In general, parameterizations use mathematical formula (derived from theoretical understanding of atmospheric processes) to calculate values for variables of interest. Stensrud (2007) summarizes most schemes into the categories of: land surface, atmosphere interaction, water-atmosphere interaction, planetary boundary layer and turbulence, convection, microphysics, and radiation. WRF uses similar distinctions, but organizes its parameterization schemes using the following structure:

1. Physics Options

   1. Microphysics (mp_physics)

   2. Longwave Radiation (ra_lw_physics)

   3. Shortwave Radiation (ra_sw_physics)

   4. Cloud fraction option

   5. Surface Layer (sf_sfclay_physics)

   6. Land Surface (sf_surface_physics)

   7. Urban Surface (sf_urban_physics)

   8. Lake Physics (sf_lake_physics)

   9. Planetary Boundary Layer (bl_pbl_physics)

   10. Cumulus Parameterization (cu_physics)

2. Diffusion and Damping Options

3. Advection Options

4. Lateral Boundary Conditions

As you can see, there are many categories with at least 2-3 scheme options per category. The result is literally hundreds of thousands of potential combinations to choose from.

Advantages and disadvantages of parameterization schemes

The equations that make up parameterization schemes in WRF range from very simple to very complex. In general, the more complex options are much more comprehensive and provide more precise and accurate results. Which begs the question: why not use the most complex, in-depth parameterizations every time, if they yield more precise results? There are several reasons, but the best explanation is: computation time is expensive.

In order to get an accurate representation of the region you are modeling, you want to create a domain that is as large as possible with the highest resolution possible. This means, as many grid points as possible. The problem is that the model solves all the equations at every grid point for every time step, therefore if the model runs for a long time period, for a large domain, or for a high resolution, the computer is doing A LOT of calculations. This can take a very long time to do, or requires lots of processors (which are expensive). Therefore, sacrifices have to be made based on the question being researched.

Climate, weather, and regional climate models

Consider, for example, a climate model versus a weather model. Weather models tend to have complex parameterizations that focus on small-scale processes, therefore also have high resolutions. The goal of weather models is to precisely and accurately forecast day to day weather. Since the resolution is high and parameterizations are complex, the models are run over a very small domain in order to be sure the model run-time is reasonably short. After all, what good is a 24 hour forecast if the model takes 48 hours to run?

Climate models, however, have a different goal. The goal is to accurately indicate trends (rather than specific values) over a very long period of time and a very large domain (often the entire planet). Therefore, parameterization schemes focus on large-scale processes and resolution is generally quite low. In the case of climate models, it is OK if the model takes several days to complete a run, since the model is usually looking at several decades into the future.

Regional climate modeling (as is frequently done using WRF) requires some combination of both processes and is why nesting is such an important part of setting up the model domain. The larger, coarser nest calculates the climate influence on the region (using large-scale, less complex processes) and the smaller, high resolution nest calculates the weather as influenced by the climate for that region (using small-scale, more complex processes). Therefore, parameterization schemes must be chosen with both of these ideas in mind.

Figure 2. Visual representation of Earth’s Climate System. Image from UCAR Digital Library.

Choosing parameterizations based on research questions

Next, consider the following hypothetical research question: Does urban development impact the wind over a wind turbine farm in my domain? In order to choose the best parameterizations for the model run, you have to think about the question being asked. First, the dynamic processes that calculate small-scale wind and speed relating to radiative heating are important and complex, in-depth parameters should be chosen. Similarly, small-scale dynamical processes and accurate representation of orography and urban structures require small grid spaces, so a high resolution is also required. However, small-scale microphysical processes that determine different concentrations of various water particles in the atmosphere is not an important component of this question. So, using a less-complex microphysics scheme will save computing power and likely will not impact the answer to your research question.

Final Thoughts

While choosing the most complex and comprehensive parameterization option may seem like the best choice, it is important to consider the resolution and size of your domain as well as the time period of your model run. When you consider your research question, be sure to ask yourself:

• What length of time am I interested in studying: long range or short range time scales?

• What variables am I interested in looking at: are they small-scale or large-scale?

• Based on my variables of interest and the size of my region, do I need to use a fine resolution or is a coarse resolution ok? Is nesting an appropriate option?

• Are my variables of interest the result of primarily dynamic processes or microphysical processes?

• Which parameterization category options are most important? Which are least important?

This is by no means a comprehensive list of questions to consider, but it is a nice place to start. In future posts, we will take a much closer look at several microphysics, cumulus, radiation, and boundary layer options in WRF. At the end of this post series, we hope you will have a much better idea of how these schemes will impact your WRF run.

Until next time,

-Morgan

References

Schwarz, C. V., Reiser, B. J., Davis, E. A., Kenyon, L., Acher, A., Fortus, D., et al. (2009). Developing a learning progression for scientific modeling: Making scientific modeling accessible and meaningful for learners. Journal of Research in Science Teaching , 632-654.

Skamarock WC, Klemp JB, Dudhia J, et al. A description of the advanced research WRF version 2. NCAR/TN-468+STR 2005.

Stensrud D. J. (2007). Parameterization Schemes: Keys to Understanding Numerical Weather Prediction Models. Cambridge University Press, New York.

Data Assimilation in WRF: An Overview

One of the greatest benefits to using atmospheric computer models is the ability to experimentally test the influence of new and unusual forces on weather and climate. Have you ever wanted to include additional data into your WRF run? Perhaps you have sea surface temperature, a specific set of precipitation, or other kinds of data. Maybe your research question requires a special set of data in your simulation. This post provides an overview of data assimilation techniques to help you get started on this process.

 

Sea-Surface Temperature

Although WRF doesn’t require sea-surface temperature (SST) to run, if you are doing longer simulations (like those you would do for regional climate modeling), it can be very beneficial. Therefore, WRF was designed to seamlessly incorporate SST into simulations. They even created a tutorial online with a link to free data to help you get started. This is probably the easiest way to get started with data assimilation, if you are new to WRF.

 

WRFDA

Did you know that WRF has a data assimilation component available? It’s called WRFDA and is described in chapter 6 of the WRF User’s Guide. It provides step-by-step descriptions of how to assimilate a few commonly used types of data, such as radiance, radar, and precipitation. It even provides some free input data you can use in your run, so this is an excellent place to start.

  

Be aware that if you have already installed the full version of WRF, you will still need to download and install the WRFDA component. Don’t worry though, if you managed to get WRF installed, the assimilation component should be pretty straightforward and integrate seamlessly.

 

Modifying the Source Code

This process is the most difficult to do, but it gives you the most flexibility. For example, let’s say you want to see if the heat released from a volcano eruption impacted the weather in your domain. You would want to replace land-surface temperature for that one specific grid cell, which would have to be done by finding the variable in the source code and modifying it. If you are interested, this is exactly what I did for my Masters Thesis, which has been published and is free to access.

 

Heat from a volcano comes from the use of satellite data. Once you have obtained a reasonable dataset, you will have to be sure you have interpolated the data to match the timestep (“time_step” in your namelist file) for the number of days, hours, minutes, etc. You have to be sure the amount of data you have matches the number of iterations WRF will use.

 

You also need to decide how to introduce the data into WRF for the run. This requires thoughtful consideration of the components of WRF as well as the parameterization schemes you decided to use (which you specified in your namelist). Eventually, you will have to explore the WRF source code for the equations and variables you are interested in. However, you risk making accidental changes if you are continually opening and closing files, which may alter how the model works or even prevent it from running altogether. So I suggest using an online source file, such as this one, so you can search the files without fear of risking your WRF code. Additionally, the files are all easily sorted so you don’t have to change directories as you are searching either. Once you know exactly what you want to modify, you can edit the correct file in code on your computer.

 

 

To incorporate heat from the volcano, you are changing the long-wave radiation output from the one grid cell that the volcano is in. Assume you are using the RRTM, you would search through that source code for the variable describing surface temperature. At the beginning of the RRTM subroutine, they list the variables:

SUBROUTINE RRTM (TTEN,GLW,OLR,TSFC,CLDFRA,T,Tw,QV,QC,              & 1,5
                  QR,QI,QS,QG,P,Pw,DZ,                              &
                  EMISS,R,G,                                        &
                  kts,kte                                           )

As you would expect, temperature is identified with a “T”, therefore, we will look to see when T is first used in calculations later on in the code. If you scroll down, you should come across the following: 

CALL MM5ATM (CLDFRA,O3PROF,T,Tw,TSFC,QV,QC,QR,QI,QS,QG,    &
                    P,Pw,DZ,EMISS,R,G,                            &
                    PAVEL,TAVEL,PZ,TZ,CLDFRAC,TAUCLOUD,COLDRY,    &
                    WKL,WX,TBOUND,SEMISS,                         &
                    kts,kte                                       )

 This indicates that the routine that calculates T (temperature) is in the subroutine called MM5ATM. So we can go into that code, search for temperature there again. We actually find where comments in the code say that they are setting the surface temperature, which is done in the equation:

TBOUND = TSFC

where TSFC is the input data from either the startup data or from what was calculated in previous iterations of the run. Therefore, the TSFC variable is the one we need to alter with our dataset.

 

First, call your volcano heat data into the program. Say your dataset file is called “volcano” and the variable is “heat”. Also, assume the volcano is in the grid space described as i=45, j=48, k=0 (this is something you would have to determine based on how you set up your domain location, size, and resolution).  Therefore, you would insert :

IF (i=45 .AND. j=48 .AND. k=0) THEN       ! only insert the new data if the grid space is the volcano

CALL volcano (heat)

TBOUND = heat

ELSE

TBOUND = TSFC     ! otherwise, do what it normally does

END IF

Then, you should be ready to run with your new data!

 

Data assimilation is not an easy thing to do. I suggest running WRF a few times before trying to assimilate any new data, at the very least so that you feel comfortable with WRF and learn to expect reasonable output data, so that you can more easily identify erroneous results.

 

Also, start out with easier assimilations, such as SST which is already built into WRF, or another variable using the WRFDA component. Editing the source code is a more advanced technique that requires a good understanding of FORTRAN and the WRF parameters.

 

Let me know if you try anything interesting. Happy assimilating!

 

-Morgan

How to Design Publication-type Maps Using Google Maps and R

The statistical software R has become a widely used tool in science these days. It is free of charge, it is easy to use and it is very flexible. One of its flexibility features is the ability to create geographical maps using Google Maps (and also plotting/overlaying data on maps).

Here, I would like to illustrate how to create a map showing weather station points in Norway on a Google Map. I will also show you how to save the map in high-resolution, so that you can use it in a publication or report. This is adapted from a plot I created for the HORDAKLIM Project, managed by Dr. Erik Kolstad at Uni Research Climate in Norway.

Installing R

If you do not have R on your machine, it is very easy to install it. You just download it from its main website at www.r-project.org and follow the instructions there. I personally like to work with an R interface called RStudio (Fig. 1), which you can download here: www.rstudio.com

Figure 1 – Screenshot of R studio, showing a map with weather station points, where the size of the points are scaled according to the altitude of the station.

R packages you will need

In order to create the plots in this tutorial, you will need to download and load a few of packages in R. This is straightforward to do. After you open R (or RStudio), type the following there:

install.packages(“RgoogleMaps”)

install.packages(“ggplot2”)

install.packages(“ggmap”)

install.packages(“grid”)

Now that they are installed, you don’t need to install them again. But you will need to load them whenever you use them. So, let’s load these packages to get started:

library(RgoogleMaps)

library(ggplot2)

library(ggmap)

require(grid)

Data for this tutorial

We will create some data for the tutorial. The data contain the names of the stations, the latitude, the longitude and their altitude. If you prefer, you can also read the data from a text file. But here, we will do it directly in R. Note: the hashtag (#) below is used for comments.

# Create data

station<-c("Kaldestad", "Folgefonna", "Nesttun", "Flesland", "Midstova")

lat<-c(60.55,60.22,60.32,60.29,60.66)

lon<-c(6.02,6.43,5.37,5.23,7.28)

altitude<-c(507,1390,62,48,1162)

# Create data frame

stdata<-data.frame(sta=station, lat=lat, lon=lon, alt=altitude)

print(stdata)

Classifying data into categories

We will classify our stations into four different categories. These are needed so that we can plot points with different sizes based on the station altitude. We will classify them as stations that are below 100m, between 100m and 600m, between 600m and 1200m and above 1200m.

# classify altitude into 4 categories

 stdata <- within(stdata, {

 label <- NA

 label[alt > 0 & alt <= 100] <- "A"

 label[alt > 100 & alt <= 600] <- "B"

 label[alt > 600 & alt <= 1200] <- "C"

 label[alt > 1200] <- "D"

})

# check the data with the classification

print(stdata)

Making the first map

Now, we are ready to make our first map (Figure 2). We will create the map based on the latitude and longitude information from our dataset. The option zoom below can be changed, so that you can see closer or further away. So, type the following:

# Making maps

MyMap <- MapBackground(lat=lat,lon=lon,zoom=10)

 

# Plot character size determined by altitude

tmp <- altitude

tmp <- tmp - min(tmp) # remove minimum

tmp <- tmp / max(tmp) # divide by maximum

PlotOnStaticMap(MyMap,lat,lon,cex=tmp+0.8,pch=16,col='black')

Figure 2 – First map showing the five stations. The size of the stations are based on their altitude.

Second plot

Our second plot will be a bit more sophisticated, as we will use the ggplot2 package. Also, we will add a legend to the size of the stations (Figure 3). Here’s how we do that:

# Another way of plotting

basemap <- get_map(location=c(lon=mean(lon),lat=mean(lat)), zoom = 8, maptype='roadmap', source='google',crop=TRUE)

ggmap(basemap)

map1 <- ggmap(basemap, extent='panel', base_layer=ggplot(data=stdata, aes(x=lon, y=lat)))

# map showing point size based on altitude

map.alt <- map1+geom_point(aes(size=stdata$alt),color="darkblue")+scale_size(range=c(2,9),breaks=c(10,100,500,1000))

# add plot labels

map.alt <- map.alt + labs(x ="Longitude", y="Latitude", size = "Altitude")

# add title theme

map.alt <- map.alt + theme(plot.title = element_text(hjust = 0, vjust = 1, face = c("bold")))+theme(legend.position="bottom")

print(map.alt) 

Figure 3 – map using ggplot2, which adds a legend related to the station altitude in meters.

Making a plot for a publication

Finally, if you want to save your plot in high-resolution for a publication (e.g.: 600 dpi), you can do the following:

# Map for a publication

# Plot based on altitude category

tiff("station_map.tif", res=600, compression = "lzw", height=4.8, width=4, units="in")

map.cat <- map1+geom_point(aes(size=stdata$alt,group=stdata$label,

                              color=stdata$label))+scale_size(breaks=c(50,500,1000))

# manual color

map.cat <- map.cat+scale_colour_manual(values=c("#D55E00", "darkmagenta", "#0072B2","#009E73"),

                                      breaks=c("A", "B", "C","D"),

                                      labels=c("Coast", "Hill", "Mountain","High Mountain"))

# add plot labels

map.cat <- map.cat + labs(x ="Longitude", y="Latitude", size = "Altitude", color="Location")

# add title theme

map.cat <- map.cat + theme(legend.text = element_text(hjust = 0, vjust = 1,face = c("plain"),size=5),

                          legend.position="bottom",legend.box="vertical",legend.title=element_text(size=6),

                          legend.key = element_blank(), # remove gray background from legend

                          axis.text=element_text(size=6),axis.title=element_text(size=6))+

 theme(plot.margin = unit(x=c(0.1,0.1,0,0.1),units="in")) # ("left", "right", "bottom", "top") # remove extra margins in fig

print(map.cat)

dev.off()

The result is shown in Figure 4. Note that in this plot, we have added the location type and the altitude as legends in the plot.

Figure 4 – Station plot on Google Map and two types of legend: location type and altitude

I hope you have enjoyed this tutorial. If you have further questions, you are welcome to post them here.

Acknowledgements

We thank the Yarker Consulting, m2lab.org and the HORDAKLIM Project for making this work possible. Also, we are very grateful for Google, R, RStudio, ggplot2 and others for making their software and packages freely available!

-Michel