Now we need to download some data to process.
One thing that tripped me up initially (being relatively naive about how weather models worked) was the simple fact the WRF system requires the output of other models to run a prediction. Why? WRF is what they call a mesoscale or local forecasting model, meaning it doesn’t try to understand what the whole world is doing, it simply focuses on one little area (such as a state or region). Therefore it requires other global models (such as the GFS) telling it what’s going on outside its focused area (what weather patterns are going into the forecast area, for example). So… WRF takes as input a global model and does a far more detailed analysis on the local level to give a forecast better than what the GFS alone could do (in theory).*
So let’s download GFS data for our model run. What I do is simply head on over to NOAA and find a range of GFS products (products = output) I’d like to process here. A ton of data is stored here, and you’ll see there are multiple folders with the same date. It’s really kind of a dumping grounds of output data and can be quite daunting to get your bearings. So let’s slowly walk through it.
At first you’ll see a range of folders, these are the output of GFS runs done at different times during the day, so in theory the latest one is going to be the most accurate. For me — doing this on August 22nd of 2014, the following folders appear waaaay at the bottom of the page:
You see there’s a GFS model run for the 22nd of August at 00-hours, 06-hours and at 12-hours and 18-hours. Let’s jump into the gfs.2014082218 folder (18-hours) since that’d be the best available forecast we have. Doing so puts me at this URL:
Now, there’s a TON of data in here. It’s all various output from global model runs, but what we’re looking for is data packaged into a particular data format (grib2). All of the files have a special name format (so you can do regular expression matches to get the exact data you need), but for our purposes let’s simply do a search for files containing the character sequence “pgrbf“.
Doing this search results in files being highlighted as such:
We’re interested in the 16 megabyte files ending in *.grib2. So let’s go ahead and download the files from time 00 to time 09 (the ones we see in the snippet above).
To do so on Linux, I typically move into the directory containing all my other directories (such as WPS and WRFV3) and create a new one called Data. From within this directory I then execute wget to download everything, so something like this:
... wget http://www.ftp.ncep.noaa.gov/data/nccf/com/gfs/prod/gfs.2014081712/gfs.t12z.pgrbf00.grib2 ...
…and so on until all the files I’m interested in are downloaded (typically I write a script to do this, but that’s up to you). When done, the directory should look like this:
And now the magic begins.
- Move into the WPS directory and execute the ./link_grib.csh script. What this will do is generate symbolic links to the grib2 data files within the WPS directory. So we execute ./link_grib.csh ../DATA/
- Listing the directory contents now reveals a sequence of files named GRIBFILE.*** where *** is a unique moniker suffix. These files are symbolic links to your recently downloaded GRIB2 data files.
- Now we’re going to unpackage (or “ungrib”) these datafiles. To do so, we’re going to use a tool called ungrib.exe. Ungrib.exe uses a configuration file to know the fields to unpack from the GFS GRIB2 files, so we’ll create a link to that configuration file by typing ln -s ungrib/Variable_Tables/Vtable.GFS Vtable.
- One last step before running ungrib.exe: we need to now update the namelist.wps configuration file so ungrib knows what range of data to unpack. Unfortunately it’s not immediately obvious as to what dates are encoded within the GFS files, so you’ll need to use a utility to inspect the files and return the dates they harbor called wgrib2. Instructions for compilation is here. For me this was painless (I also copied the binary to /usr/local/bin).To find the start time, execute this command against the GFS forecast file at 00 and 09 hours:…then take the output dates and update the namelist.wps file within the WPS directory. The contents of the file should look like this (given the output we get above):
&share max_dom = 1, start_date = '2014-08-22_18:00:00', end_date = '2014-08-23_03:00:00', interval_seconds = 10800 /
- Now launch ./ungrib.exe. When all is done you should have a series of output files beginning with “FILE:”. These are the unpackaged GRIB2 files in an intermediate format for use by WPS.
- We now need to launch geogrid.exe, which is used to generate an understanding of the local terrain for the weather model run. To do so we need to, again, update our namelist.wps configuration file with the geospatial coordinates of the region by placing the following immediately after the share section from the previous step (be sure to update geog_data_path to point to the directory within which you unpacked the geog data from the previous post). NOTE: For Lincoln, NE (my hometown), you can simply copy/paste what I put here, otherwise update with your own coordinates (the lat/lon values should be the only ones you need to change).
&geogrid e_we = 75, e_sn = 70, dx = 30000, dy = 30000, map_proj = 'lambert', ref_lat = 40.8106, ref_lon = -96.6803, truelat1 = 40.8106, truelat2 = 40.8106, stand_lon = -96.6803, geog_data_path = '/home/brush/Downloads/weather/geog/' /
- Now run geogrid.exe. As it’s executing you’ll see it process a number of geographical datapoints in preparation of the full run.
- metgrid.exe is then ran. This bridges the gap between the GFS data and geographical data by horizontally interpolating the former over the later, so basically it connects the two together. This requires another addition to namelist.wps, albeit a shorter and simpler one:
&metgrid fg_name = 'FILE' io_form_metgrid = 2, /
Now execute metgrid.exe.
- We are now done with the WPS directory, meaning we have prepped all of the data and are now ready for the actual model run. To do this we will update one more configuration file and execute two applications located within the WRFV3/test/em_real directory. So change into that directory and open up namelist.input. Within this file you’ll immediately see a bunch of variables, but luckily we only have to change a few. Update the following fields under the “&time_control” section:
run_days = 0, run_hours = 9, run_minutes = 0, run_seconds = 0, start_year = 2014, start_month = 08, start_day = 22, start_hour = 18, start_minute = 00, start_second = 00, end_year = 2014, end_month = 08, end_day = 23, end_hour = 03, end_minute = 00, end_second = 00,
Now update the following fields under the “&domains” section…
time_step = 180, time_step_fract_num = 0, time_step_fract_den = 1, max_dom = 1, e_we = 75, e_sn = 70, e_vert = 35, p_top_requested = 5000, dx = 30000, 10000, 3333.33, dy = 30000, 10000, 3333.33,
- To launch the two apps responsible for actually generating the model we need to install mpirun (this is part of MPI, a system that enables distributed computing), and you can do so with your favorite package manager (I installed openmpi).
- Copy all of the files generated by metgrid (starting with “met_em”) into your current directory.
- Run mpirun -np 1 real.exe
- Then run mpirun -np 8 wrf.exe ..sit back and wait….
- When done you should have a file starting with “wrfout”; this is the model output! You’re done! You can then work with this file using any number of WRF post processing utilities and languages.
* It’s worth noting WRF is capable of doing a global analysis by way of “nesting forecasts”, but it’s not very well supported and not recommended for accurate forecasts (most people I’ve talked to consume GFS or other global model output).