MEA 716 WRF Homework, Data Case Spring WRF Real-Data Case Study Simulation

Transcription

1 MEA 716 WRF Homework, Data Case Spring 2016 Assigned: Tuesday 2/2/16 Due: Tuesday, 2/9/16 WRF Real-Data Case Study Simulation This assignment takes students through the process of obtaining initial and lateral boundary condition data, running the WRF Preprocessor System (WPS), then running real and wrf.exe, and post-processing the output using the Unified Postprocessor (UPP) software. A recent highimpact event that affected the US East Coast was the snow and ice event that took place on 22 and 23 January Let s run that case with WRF as an example with which to gain experience setting up and running the model. Finally, we will examine some of the output to evaluate physics sensitivity and test out analysis and plotting routines. Part A: Running the WRF Pre-Processing System (WPS) Step a1: Download grib data You could complete the following set of instructions to run WRF on any case study, using a wide variety of initial and lateral boundary condition data sets; I ve added some links to data sources on the MEA 716 web page. For the winter storm case, I will use the Global Forecast System (GFS) forecast from 00 UTC 21 January as the initial condition, and we will run an 84-hour forecast. Note that this will be a true forecast, and not a simulation, because we will be using forecast lateral boundary conditions in the run. If we were using analyzed lateral boundary conditions, then we would refer to the run as a simulation. A forecast could be run in advance of a weather event, whereas the same could not be said of a simulation. The data I obtained for this case can be found at (or just Google NCDC NOMADS). At the top of the page, click Access (you may wish to look through the inventory information first). I selected the GFS ½-degree dataset, and I went with the HTTP download method rather than others, although for large data sets, the FTP method or FTP4u methods are faster. I could say much more about the different analyses, and their strengths and weaknesses, but for now let s move ahead with our WRF forecast. You don t need to re-download the data, I have placed it in /gpfs_share/mea716/class/data/winterstorm16/gfs_grib.

2 Step a2: Untar and unzip WRF and WPS Make a directory either in your class space, or on one of the /share partitions (/share2/yourid, or /share3/yourid tend to have a lot of space, but you will need to create the directories the first time). In whatever location you choose, create a winterstorm16 directory, and in it, cp, untar, and unzip WRF, and also WPS. Note that WPS uses WRF libraries, so it must be located properly (in the same directory tree) for WPS to work. cp /gpfs_share/mea716/class/model/wrf/wpsv371_c7_compiled.tar.gz. cp /gpfs_share/mea716/class/model/wrf/wrfv371_compiled.tar.gz. then, tar zxvf to extract the codes. Step a3: Run WRF Domain Wizard to set up your grid For this part, use a PC, laptop, Mac, or any other computer that you like, but NOT the HPC system. It is not a good idea to run this type of GUI on the head node of the HPC system. We could perhaps try running it on a VCL node I ll look into this, but for now, just use another computer. I find that my PC works better than Linux computers for this task for some reason. The Domain Wizard is a neat java application that makes setting up grids very easy. However, because it runs applications on the head node of the computer to which it is connected, we won t use it to the full extent, but only as a graphical interface for setting up our model domain and linking our raw data files. Basically, the Domain Wizard is a graphical user interface (GUI) with which we can run the WRF Preprocessing System (WPS) software. The main functions of WPS are to: 1) Set up the horizontal and vertical dimensions of the domain(s); 2) Processes initial condition and lateral boundary condition files in grib format; 3) Interpolate the initial and boundary conditions onto the WRF domain. Launch a web browser, and go to (this is also linked from the MEA 716 web page). Download the application, extract the files, and run the application (instructions will differ on a PC vs Mac vs Linux system). Once you have downloaded and extracted the files for the DomainWizard, open the folder containing the files, and (for a PC), click on run_domainwizard.bat to launch the java application. When this runs, enter login01.hpc.ncsu.edu (or 02, 03, etc.) for computer, and your username and password. Next, click the boxes to specify the path to your WPS and WRF from step a2:

3 Of course, your paths will differ from what I ve shown above except for the geography location. For WPS, enter the path where you located these files on HPC, something like /gpfs_share/mea716/yourid/project/wps, Or wherever you untarred and unzipped WPS. For domains, I always create a subdirectory within the WPS directory, and then point to that. Once you create this directory, use: /gpfs_share/mea716/yourid/project/wps/domains Choose a new domain, and click next. Use the mouse to drag out a reasonable domain, and let s go with a Lambert Conformal map projection (see below right). Then update the map, and select 18 km grid spacing. You will need to adjust the grid dimensions afterwards to keep the domain area consistent. Put some thought into the domain area. We want a relatively coarse resolution run for this first case. To familiarize you with some of the synoptic weather features, note that we need to include the Gulf of Mexico and Western Atlantic, knowing the track of the low-pressure center in question. And, the upper-level shortwave trough that led to the cyclone came from the west. So, our domain is offset slightly west of the location of interest, and features enough upstream space to capture the important meteorological features. If I was doing a research run, I would make the outermost domain even larger, but since all 10 of us will be running this forecast, we want to keep it modest to save system resources. Note that you can spawn inner (higher resolution) nests at a later stage, by clicking on the nests tab. Let s add a 6-km nest just over the region most impacted by the storm, something like what is shown below. Then, click next at the lower right.

4 The next step takes you through the namelist editor, which is a handy way to modify the namelist as needed for a given case. You only need to change the times and dates at this point, because other settings are relevant only to running the WRF model, and can be modified later. I prefer to use the text editor tab for this. Alter run_hours and the start_ and end_ dates and times. For our forecast, we initialize at 00 UTC 21 January, and run out 84 hours to 12 UTC 24 January. We could, at this point, add vertical levels if we wished by clicking on the add or Edit ETA Levels tab, or change the model top pressure level (default is 50 hpa). Feel free to do these things if you want, but it is not necessary. Finally, once you ve set up the namelist to match the dates, times, and run length, the last step that we ll do within the Domain Wizard is to link our grib data files. At the top of this page, select the correct Variable Table (Vtable) so that WPS knows what fields and characteristics accompany the grib files you downloaded earlier. We are using GFS data, so the Vtable.GFS is the right one for this case. Change the Grib interval to 3 hours, and set the Grib start and end dates. Select the directory containing your grib files, and select the files that correspond to your model run. Then add these files. If this step doesn t work, no worries, we can easily run a script back on the HPC system to do this part. At this point, exit the Domain Wizard, and return to the HPC Linux environment. Step a4: Run WPS from batch scripts on HPC system The next steps are computationally intensive, so leave the Domain Wizard, and ssh to the HPC system. CD to the directory where you had WPS located, and cd to the domains subdirectory, then to the subdirectory containing the name you gave to this model run in the Domain Wizard. Magically, you should see some things there, such as symbolically linked GRIBFILE.AAA, etc. Next, symbolically link the WPS executable files into this directory: ln s../../*.exe. Then, you can run the three main programs (or submit batch scripts that will run them): a.) geogrid.exe This program interpolates the geographical data, including terrain, land use, soil characteristics,

5 land-sea mask, albedo, vegetation fraction, etc. onto the grid you defined in the Domain Wizard. In the domains directory, have a look in the GEOGRID.TBL file, and you should recognize some of the parameters we ve been discussing recently in the context of land-surface models (LSMs). You will need to copy the batch scripts from the /gpfs_share/mea716/class/model/wrf directory into the present working directory where your data are located. There are 3 such scripts, as will be evident below. The three scripts are run_geogrid.csh, run_ungrib.csh, and run_metgrid.csh. After copying and modifying if needed: bsub < run_geogrid.csh If it works you should see files such as: geo_em.d01.nc - you can use ncview or ncdump on these files too in order to check. b.) ungrib.exe This program unpacks the grib files, and makes sure that the needed variables are found, and are named according to what WRF expects. The files are put into an intermediate format. This involves the Vtable you had selected earlier from within the Domain Wizard, which should be seen in this same directory. At this point, edit the important file namelist.wps. At the top, change the dates and times to those corresponding to our model run (for some reason, it likes to default to today s date). In this file, locate the variable max_dom, and set it to 1 (to save disk space, let s just run the outer, 18- km domain at this point, even though we have the information needed to run the inner 6-km domain later if we wish). When you ve finished editing the namelist.wps file: bsub < run_ungrib.csh Generally, this program may take a while, depending on the length of your model run. Once it is done, look for files in the intermediate file format: FILE. First, you will see files like PFILE, and later, FILE We can change the names of the ungribbed files according to our tasks, for example, we could merge multiple datasets into a single model initial condition, such as we would do in order to import a different SST dataset, for example. c.) metgrid.exe This is the most important step in WPS, because here the main data interpolation onto your horizontal (Arakawa C) grid takes place. To submit this job, use bsub < run_metgrid.csh If it runs successfully, you will have a series of met_em.d01 files. These files as well are in NetCDF format, and can be viewed using standard software such as ncview. Note that for many applications, there are additional steps in the metgrid process, but for our purposes here, we will keep it simple the first time through. Once complete, we are now ready to use WRF software.

6 Part B: Running real.exe and WRF Step b1: In WRF directory, run real.exe to create input and boundary condition files Before we run WRF itself, we must perform a vertical coordinate interpolation, and a few other adjustments (such as making sure that the initial atmospheric state is in hydrostatic balance). For this step, change directories to your WRFV3/test/em_real directory, where a compiled version of WRF is waiting for your data. Once you re there, symbolically link your met_em.d01 files from WPS into the local directory: ln s /pathtoyourwps/wps/domains/casename/met_em*. Note that handy namelist.wps and namelist.input files have also been created by WPS, but you should not generally use these straight up in WRF. Instead, copy the original namelist.input file into a backup name, and then copy these WPS-created namelists from the same place where the met_em files are, into the WRFV3/test/em_real directory (where you are). You should use the WRF-distribution namelist.input file to set up your model run, but you can get the characteristics you need from the WPS-generated one, including grid spacing, grid dimensions, times, etc. Take the time to carefully examine and edit the namelist.input file in this directory. I estimate that 90% of model run errors are due to careless namelist editing. Here, increase the number of vertical eta levels in the namelist, by adjusting the value of e_vert from 28 to 35, and copying the block for 35 eta levels from the README.namelist file. This block should be pasted into the namelist.input file at the beginning of the &domains section. Once you ve set up the namelist.input file correctly, using the details from the WPS-derived namelists, you are set to run real.exe. bsub < run_real.csh If this works, it should produce wrfinput_d01 and wrfbdy_d01 files, and then you ll be ready to run WRF. Note that the wrfbdy_d01 file contains the information (as its name implies) for the lateral boundary conditions, derived from our GFS forecasts in this case. If we had multiple nests, we would also have wrfinput_d02, etc. files, but lateral boundary conditions (wrfbdy) are only needed for the outermost domain. Note: If you change the number of soil layers when altering the LSM specification, you have to make this change before running real.exe, or else rerun real.exe after changing the LSM. Step b2: Edit namelist.input, run WRF Once you have the needed wrfinput_d01 and wrfbdy_d01, then you can run WRF, but before doing so, you should think carefully about what namelist options you want, concerning physics choices, etc. I usually like to change the frequency of calls to the radiation scheme to 10 minutes, rather than the default 30 minutes. That helps keep sunrise and sunset at the proper time. In order gain more information about the sensitivity of the representation of this storm to LSM and PBL representations, we will run a class ensemble using the designations as follows. Note again that if you are assigned a different LSM and have to change the number of soil layers, you will need to re-run real.exe.

7 Lackmann: Noah LSM, YSU PBL, adaptive time step, Kain-Fritsch convection Blank: RUC LSM, YSU PBL, Kain-Fritsch convection Eghdami: Pleim-Xiu LSM, ACM2 PBL, Kain-Fritsch convection Hawbecker: Noah-MP LSM, MYJ PBL, BMJ convection McGee: CLM4 LSM, MYJ PBL, BMJ convection Russell: Noah LSM, TEMF PBL, Kain-Fritsch convection Sherburn: Noah-MP with T2m < 0 for snow designation, MYJ PBL, BMJ convection Sun: Noah LSM, MYJ PBL, BMJ convection Taylor: Noah LSM, QNSE PBL, Kain-Fritsch convection White: Noah LSM, MYNN 2.5 PBL, Kain-Fritsch convection You will need to reduce the time step to less than the default. You are welcome to set it to 6*dx, or else to use the adaptive time step options I presented in class on 2/2. Another namelist change is to set the history interval (output frequency) to 180 minutes (3 hours should suffice for this run). Remember, a lot of information is found in the README.namelist file in the WRFV3/test/em_real directory be sure to consult that if you are unsure about the settings of a given variable. Several of the namelist choices above require additional variables to be specified (e.g., number of soil layers, Noah-MP options). Finally, to submit the WRF run: bsub < run_wrf.csh Once WRF has started running, you should see wrfout files (or, one wrfout file, if you set frames_per_outfile to 1000). Our final step is post-processing the output to facilitate analysis and display. Data inventory is critical when running models. Edit a file called README_thisrun, and type a few sentences describing this model run. Later, when you move the wrfout file, you should keep this file with it, along with the namelist.input, wrfinput, and wrfbdy files. That way, you can easily reproduce the model run if need be. Part C: Running the WRF Unified Post Processor (UPP) There are several different post-processing and visualization options for WRF, but generally, it is best to run a post-processor so that the output data are de-staggered in the vertical and horizontal, and interpolated to user-friendly vertical coordinates (e.g., isobaric this can actually also be specified in the namelist now). There is the WRFPOST software, and the Unified Post Processor (UPP), which we will use here. This versatile code includes the ability to convert the model output to a variety of formats, including GRIB, GEMPAK, and GrADs. cd /gpfs_share/mea716/yourdir cp /gpfs_share/mea716/class/model/upp/uppv2.2_compiled.tar.gz. tar zxvf UPPV2.2*.tar.gz

8 Step c1: Link WRF output into appropriate UPP directory You should now have a UPPV2.2 directory in your main class directory. CD to this directory, and then to the wrfprd subdirectory. This is the location where the wrfout files from your model run will be located (symbolically linked) for post-processing. It is inefficient to copy the files here, as it would tie up a lot of disk space needlessly. Alternatively, you could move the wrfout files there, but it is important to keep the wrfout files together with the namelist and input/bdy files from which they originated. Use the symbolic link command (ln s ) to link your wrfout file(s) to this location: ln s /pathtoyourwrfrun/wrfv3/test/em_real/wrfout*. Note: The period at the end of the previous line is crucial the command format is link [ path from file to be linked ] [ path to where link is to be located ] and in Linux, the. corresponds to your present working directory in other words, link the file to where you are, in this example. Step c2: Modify and submit batch scripts Now, cd to the /UPPV2.2/scripts subdirectory, and modify the script called run_wrfpostandgempak_1file (it should mostly be set up to work for the blizzard case, but you will notice in the definition of the environmental variable TOP_DIR, you will need to replace YOURID with the appropriate name of your directory. Also, find the variable startdate, lastfhr, domain, and so forth in case you need to modify these in later applications. Finally, examine the run_unipost.csh script. This should submit a batch job to either the MEA 716 queue or the College of Sciences queue (cos). Just submit this with the bsub command as before: bsub < run_unipost.csh If it works properly, the UPPV2.2/scripts directory should began filling up with GRIB and GEMPAK (or whatever other format you specified) files. I ve set up the script to generate a few basic GEMPAK plots, showing simulated radar reflectivity and sea level pressure, just to give an overview. These plots should automatically appear in the /scripts directory as well. Note that if you wish to obtain a format other than GEMPAK, you will need to modify the script that we bsubbed to run a different one of the UPPV2.2/scripts files. There is one set up for GrADs for example. I ve not played with these much, but they should be easy to modify following the GEMPAK example. Step c3: Plotting As mentioned before, you may wish to move the output to a different machine to plot it. Or, if you leave it on the HPC system, you can explore use of the VCL capability to avoid running on a

9 head node. I have provided a simple plotting script that displays sea level pressure and model simulated radar, set up to display output from the blizzard case in GEMPAK format. If you wish to generate GEMPAK plots for the case, copy this file and run it in the directory where your GEMPAK-format files are located: cp /gpfs_share/mea716/class/software/gem_slp_rad.csh. cp /gpfs_share/mea716/class/software/coltbl.xwp. Note that there is much room for modification and improvement for this script! The color table file makes it so that the plot has a white background. Also, you may wish to move the GEMPAK (or other format files) to a PC or mac and run the Integrated Data Viewer (IDV) on these files for 3-d visualization. The IDV is freely available from the Unidata web page, as linked on the class web page: Once you have completed the postprocessing of your model run, place the GEMPAK-format files in a directory called /gpfs_share/mea716/yourid/winterstorm16 Later, we will undertake some additional analysis on these output files, and compute some ensemble-based statistics.