*[Further compression of model output (data packing)](#)
*[Converting model output to CF-compliant NetCDF](#)
1.[Other useful tools](#)
# What is WRF
WRF is a community-driven numerical weather prediction model, originally developed in the US in a collaboration between the research community (National Center for Atmospheric Research, [NCAR](https://ncar.ucar.edu), part of the University Corporation for atmospheric Research, [UCAR](https://www.ucar.edu]) and the National Weather Service (National Centers for Environmental Prediction, [NCEP](https://www.weather.gov/ncep/) at the National Oceanic and Atmospheric Administration, [NOAA](https://www.noaa.gov/)).
Over the years, WRF evolved into two distinct models. [ARW-WRF](https://www.mmm.ucar.edu/models/wrf)(Advanced Research WRF) is maintained by NCAR and is used by the research community. [WRF-NMM](https://nomads.ncep.noaa.gov/txt_descriptions/WRF_NMM_doc.shtml) is used operationally by the National Weather Service. We use ARW-WRF.
Most of the information about the ARW-WRF is accessible from the [WRF users page](https://www2.mmm.ucar.edu/wrf/users/). The formulation of the model (background theory, numerical aspects, dynamical core, parameterizations) is described in depth in a [Technical description](https://opensky.ucar.edu/islandora/object/opensky:2898), which is periodically updated. The practical use of the model is described in a [User guide](https://www2.mmm.ucar.edu/wrf/users/docs/user_guide_v4/v4.4/contents.html).
Most of the information about the ARW-WRF is accessible from the [WRF users page](https://www2.mmm.ucar.edu/wrf/users/). The formulation of the model (background theory, numerical aspects, dynamical core, parameterizations) is described in depth in a [Technical description](https://opensky.ucar.edu/islandora/object/opensky:2898), which is periodically updated. The practical use of the model is described in a [User guide](https://www2.mmm.ucar.edu/wrf/users/docs/user_guide_v4/v4.4/contents.html). If you want to acknowledge use of WRF in a manuscript or thesis, and do not like to refer to grey literature, you can use the article by [Skamarock and Klemp (2008)](https://doi.org/10.1016/j.jcp.2007.01.037) as a reference.
NCAR periodically organizes WRF tutorials (one-week workshops for beginners). The [teaching material from the WRF tutorials](https://www2.mmm.ucar.edu/wrf/users/workshops/lecture_series/dynamics_lectures_workshop.html) is available online and is a great source of information. There is also an [online tutorial](https://www2.mmm.ucar.edu/wrf/OnLineTutorial/index.php) that covers the basics of installing and running WRF.
NCAR periodically organizes WRF tutorials (one-week workshops for beginners). The [teaching material from the WRF tutorials](https://www2.mmm.ucar.edu/wrf/users/tutorial/tutorial_presentations_2021.htm) is available online and is a great source of information. There is also an [online tutorial](https://www2.mmm.ucar.edu/wrf/OnLineTutorial/index.php) that covers the basics of installing and running WRF.
There is also a [users's forum](https://forum.mmm.ucar.edu/), which can be a source of information on solutions to common problems. However most of the forum posts are about problems, and very few offer useful solution. Navigating the forum in search of solutions is useless, but landing in the forum from a web source might be useful.
There is also a [users's forum](https://forum.mmm.ucar.edu/), which can be a source of information on solutions to common problems. However most of the forum posts are about problems, and very few offer useful solutions. Navigating the forum in search of solutions is useless, but landing in the forum from a web source might be useful.
WRF and related programs run as executables on linux machines and clusters. Running WRF requires access to a linux terminal. If you work on Linux or Mac, this is trivial: just open a terminal window. If you work on windows, consider using a linux terminal emulator that supports X11 forwarding (a protocol that enables running interactive graphical applications on a remote server via ssh). There are several alternatives, one option that proved to work well is [MobaXterm](https://mobaxterm.mobatek.net/).
# Organization of the source code
The WRF source code is available on [Github](https://github.com/wrf-model/WRF). It is possible to checkout the repository, but the recommended way of getting the code is to download one of the [official releases](https://github.com/wrf-model/WRF/releases): scroll down to the "Assets" section and choose one of the v*.tar.gz or v*zip files (not the "Source code" ones; these are incomplete).
To download while working on the terminal on a remote server, use wget or curl:
Knowing in detail the structure of the source code is not necessary for the average user. However, the directories where most of the practical work is done are:
*`run`: this is where the compiled executables and lookup tables will reside after compilation.
*`test`: this contains several subdirectories, each of which refers to a specific compilation mode. For instance, compiling WRF for large-eddy simulation will link some executables in `em_les`, while compiling WRF for real-case simulations will link some other executables and lookup tables in `em_real`. Most of the test subdirectories refer to simple idealized simulations, some of which are two-dimensional. These test cases are used to valide the model's dynamical core (e.g., check if it correctly reproduces analytical solution of the Euler or Navier-Stokes equations).
In some cases, editing the model source code is necessary. This mostly happens in these directories:
*`dyn_em`: this contains the source code of the dynamical core of the model ("model dynamics") and of part of the initialization programmes.
*`phys`: this contains the source code of parameterizion schemes ("model physics").
*`Registry`: large chunks of the WRF source code are generated automatically at compile time, based on the information contained in a text file called `Registry`. This file specifies for instance what model variables are saved in the output, and how.
## Compiling the model
WRF is written in compiled languages (mostly Fortran and C++), so it needs to be compiled before execution. It relies on external software libraries at compilation and runtime, so these libraries have to be available on the system where WRF runs.
In general, compiled WRF versions are already available on all of our servers (SRVX1, JET, VSC4, VSC5) from the expert users. So, the easiest way of getting started is to copy a compiled version of the code from them (see below).
However, we describe the typical workflow of the compilation, for anyone that wishes to try it out:
**Make the prerequisite libraries available*. In most cases, precompiled libraries can be made available to the operating system using environment modules. Environment modules modify the Linux shell environment so that the operating system is aware of where to find specific executable files, include files, software libraries, documentation files. Each server has its own set of available modules. As of 1.3.2023, WRF is known to compile and run with the following module collections.
Load modules with `module load LIST-OF-MODULE-NAMES`, unload them one by one with `module unload LIST-OF-MODULE-NAMES`, unload all of them at the same time with `module purge`, get information about a specific module with `module show MODULE_NAME`. Modules may depend on each other. If the system is set up properly, a request to load one module will automatically load any other prerequisite ones.
The environment must be consistent between compilation and runtime. If you compile WRF with a set of modules loaded, you must run it with the same set of modules.
**Configure WRF for compilation.* This will test the system to check that all libraries can be properly linked. Type `./configure`, pick a generic dmpar INTEL (ifort/icc) configuration (usually 15), answer 1 when asked if you want to compile for nesting, then hit enter. "dmpar" means "distributed memory parallelization" and enables running WRF in parallel computing mode. For test compilations or for a toy setup, you might also choose a "serial" configuration.
If all goes well, the configuration will end will a message like this:
This is actually a misleading error message. The problem has nothing to do with NETCDF4 not being available, but with the operating system not knowing where the NETCDF libraries are. **NOTE: explain solution.**
The configure script stores the model configuration to a file called `configure.wrf`. This is specific to the source code version, to the server where the source code is compiled, and to the software environment. If you a have a working `configure.wrf` file for a given source code/server/environment, back it up.
**Compile WRF.* You always compile WRF for a specific model configuration. The ones we use most commonly are `em_les` (for large-eddy simulation), `em_quarter_ss` (for idealized mesoscale simulations), `em_real` (for real-case forecasts). So type either of the following, depending on what you want to get:
```
./compile em_les > compile.log 2>&1 &
./compile em_quarter_ss > compile.log 2>&1 &
./compile em_real > compile.log 2>&1 &
```
The `> compile.log` tells the operating system to redirect the output stream from the terminal to a file called `compile.log`. The `2>&1` tells the operating system to merge the standard and error output streams, so `compile.log` will contain both regular output and error messages. The final `&` tells the operating system to run the job in the background, and returns to the terminal prompt.
# Overview of common tasks
The compiled code will be created in the `run` directory, and some of the compiled programs will be linked in either of the `test/em_les`, `test/em_quarter_ss` or `test/em_real` directories. Executable WRF files typically have names ending with `.exe` (this just conventional; it is actually not necessary for them to run).
# Compiling the model
Compilation may take half an hour or so. A successful compilation ends with:
