*[Organization of the source code](#organization-of-the-source-code)
*[Organization of the source code](#organization-of-the-source-code)
*[Compiling the model](#compiling-the-model)
*[Compiling the model](#compiling-the-model)
...
@@ -27,7 +27,7 @@
...
@@ -27,7 +27,7 @@
*[Before running the model](#)
*[Before running the model](#)
*[Defining the vertical grid](#)
*[Defining the vertical grid](#)
*[Defining a new geographical database](#)
*[Defining a new geographical database](#)
*[Using ECMWF data as IC/BC](#)
*[Using ECMWF data as IC/BC](#)
*[Spinning up soil fields](#)
*[Spinning up soil fields](#)
*[After running the model](#)
*[After running the model](#)
*[Interpolating model output to a new grid](#)
*[Interpolating model output to a new grid](#)
...
@@ -64,9 +64,60 @@ tar xzvf v4.4.2.tar.gz
...
@@ -64,9 +64,60 @@ tar xzvf v4.4.2.tar.gz
unzip v4.4.2.zip
unzip v4.4.2.zip
```
```
# For the impatient
# Quick start
(quick overview of the compilation/simulation process, without details)
Compiling WRF for an idealized simulation (LES):
```
./configure
./compile em_les > compile.log 2>&1 &
```
Running WRF for an idealized simulation (LES):
```
cd ./test/em_les
./ideal.exe
./wrf.exe
```
For other test cases, compilation might create a `run_me_first.csh` script in the same directory as the executables. If there is one, run it only once, before any other program. It will link any necessary lookup tables needed for the simulation (land-use, parameterizations, etc.).
Compiling WRF for an idealized simulation (LES):
```
./configure
./compile em_real > compile.log 2>&1 &
```
Running WRF for a real_case simulation:
```
cd test/em_real
ln -s $WPS_PATH/met_em* .
./real.exe
./wrf.exe
```
To do the WRF pre-processing for a real-case simulation getting initial and boundary conditions from ECMWF-IFS data on model levels, you could use a script such as the following. However, it depends on namelists, variable tables and other settings files being correctly specified. See below for details.
@@ -155,6 +206,32 @@ However, we describe the typical workflow of the compilation, for anyone that wi
...
@@ -155,6 +206,32 @@ However, we describe the typical workflow of the compilation, for anyone that wi
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.
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.
After loading modules, it is also recommended to set the `NETCDF` environment variable to the root variable of the netcdf installation. Use `module show` to see which directory is correct. For instance:
module-whatis {NetCDF (network Common Data Form) is a set of software libraries and machine-independent data formats that support the creation, access, and sharing of array-oriented scientific data. This is the Fortran distribution.}
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.
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.
**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.
...
@@ -282,18 +359,109 @@ We cover this separately. See DART-WRF.
...
@@ -282,18 +359,109 @@ We cover this separately. See DART-WRF.
### Using ECMWF data as IC/BC
### Using ECMWF data as IC/BC
The long story made short is: you should link grib1 files and process them with `ungrib.exe` using `Vtable.ECMWF_sigma`.
More in detail, since a few years ECMWF has been distributing a mixture of grib2 and grib1 files. Namely:
* grib1 files for surface and soil model levels.
* grib2 files for atmospheric model levels.
The WPS has a predefined Vtable for grib1 files from ECMWF, so the easiest way to process ECMWF data is to:
1. convert model-level grib2 files to grib1
2. if necessary, for every time stamp, concatenate the model-level and surface grib1 files into a single file. This is only necessary if the grib1 and grib2 data were downloaded as separate sets of GRIB files.
3. process the resulting files with ungrib after linking `ungrib/Variable_Tables/Vtable.ECMWF_sigma` as `Vtable`
In detail:
1. Conversion to grib1 (needs the grib_set utility from eccodes):
for i in det.CROSSINN.mlv.20190913.0000.f*.grib2; do j=`basename $i .grib2`; grib_set -s deletePV=1,edition=1 ${i} ${j}; done
2. Concatenation of grib files (two sets of files, `*mlv*` and `*sfc*`, with names ending with "grib1" yield a new set of files with names ending with "grib"; everything is grib1):
for i in det.CROSSINN.mlv.20190913.0000.f*.grib1; do j=`echo $i|sed 's/.mlv./.sfc./'`; k=`echo $i|sed 's/.mlv././'|sed 's/.grib1/.grib/'`; cat $i $j > $k; done
An alternative procedure would be to convert everything to grib2 instead of grib1. Then, one has to use a Vtable with grib2 information for the surface fields, for instance the one included here at the bottom. But: Data from the bottom soil level will not be read correctly with this Vtable, because the Level2 value for the bottom level is actually MISSING in grib2 files (at the moment of writing, 6 May 2022; this may be fixed in the future).
GRIB1| Level| From | To | metgrid | metgrid | metgrid |GRIB2|GRIB2|GRIB2|GRIB2|
Param| Type |Level1|Level2| Name | Units | Description |Discp|Catgy|Param|Level|
1. In the code snippet above, -remapnn specifies the interpolation engine, in this case nearest-neighbour. See alternatives here: <https://code.mpimet.mpg.de/projects/cdo/wiki/Tutorial#Horizontal-fields>
1. File gridfile.lonlat.txt contans the grid specifications, e.g.:
gridtype = lonlat
gridsize = 721801
xsize = 1201
ysize = 601
xname = lon
xlongname = "longitude"
xunits = "degrees_east"
yname = lat
ylongname = "latitude"
yunits = "degrees_north"
xfirst = 5.00
xinc = 0.01
yfirst = 43.00
yinc = 0.01
### Subsetting model output
### Subsetting model output
### Further compression of model output (data packing)
### Further compression of model output (data packing)
### Converting model output to CF-compliant NetCDF
