Input Data FAQs



WRF Mandatory Input Fields

See Required Input for Running WRF for a complete list of mandatory fields.




Obtain Input Data


3D and Surface Meteorological Fields

See WRF Input Meteorological Data for a list of atmospheric fields managed by NSF NCAR’s Research Data Archive (RDA). For questions related to these data, see the RDA site for contact information.



Static Geographic Fields

See Geographic Static Data for the WPS for descriptions and links to download the static fields required to run the WPS geogrid program.



High-res Terrain/Landuse for Moving Nests

See Using high-resolution terrain and landuse with vortex-following for links to obtain these data, and descriptions for building and running WRF with this option.




Using Non-GRIB Meteorological Input


Writing Non-GRIB Data to WPS Intermediate Format

See Writing Meteorological Data to the Intermediate Format for instructions to convert non-GRIB-formatted data to the WPS-expected intermediate format.



Converting ERA5 Data from netCDF to Intermediate Format

NSF NCAR’s RDA previously supplied ERA5 data in GRIB format, which could be converted to intermediate format (expected by the metgrid program) during the ungrib process. These data are no longer available in GRIB format from RDA. WRF and MPAS users who previously relied on ERA5 in GRIB format for model initialization should transition to using netCDF-based initialization scripts developed by MMM.


Note

The above scripts are written specifically for ERA5 data, but they could be used as a template to convert other sources of netCDF formated data to intermediate format.





Processing ERA5 Input

ERA5 data is formatted with each variable and each time per file. To process these data,

  • Use the link_grib.csh script to link all upper air and surface files to the WPS directory.

  • Vtable.ECMWF is the corresponding Vtable for these data.

  • An additional invariant data file must be obtained and placed in the WPS directory. This can be downloaded from the ERA5 site or obtain the ERA5_INVARIANT file using the following command:

    wget https://www2.mmm.ucar.edu/wrf/wrf_tutorial_linked_files/ERA5_INVARIANT

    Note

    NCAR HPC users can obtain the file from /glade/work/wrfhelp/era5


  • Add the following in the &metgrid namelist.wps record prior to running metgrid:

    constants_name = 'ERA5_INVARIANT'




Using 2024+ ECMWF Input

Beginning in the second half of 2024, EC GRIB2 data requires an additional step to convert from EC GRIB2 format to WPS-supported GRIB2 format. This is done by using the convert command from the ecCodes ECMWF Library, following this syntax:

grib_set -r -w packingType=grid_ccsds -s packingType=grid_simple input.grib2 output.grib2

Vtable.ECMWF from WPSv4.6+ is compatible with the converted GRIB2 data.





Using Your Own Input


Using Masked Fields

When including an alternative data source field in WPS that is a masked field (e.g., soil moisture), a corresponding landmask field must also be included.

Alternatively, define missing values (or negative values) with some large value (for e.g., -1.E30). Then add the following in WPS/metgrid/METGRID.TBL to instruct metgrid to not use it when interpolating. This is an example for the field SM000010:

name=SM000010
interp_option=sixteen_pt+four_pt+average_4pt+search
masked=water
interp_mask=LANDSEA(0)
missing_value=-1e30
fill_missing=1.
flag_in_output=FLAG_SM000010


Adding a Geogrid Static Dataset

Due to limited resources, WRF support staff are not able to assist with implementation of individual user static datasets; however, see Writing Static Data to the Geogrid Binary Format for details on doing this.



Adding a New Hydrometer Field

If using your own analysis data that includes rain, snow, cloud water, etc., they can be processed in WPS. If the data are not in GRIB format, see Using Non-GRIB Meteorological Input. If they are in GRIB format, process them with ungrib.exe, and then run metgrid.exe using this data, plus whatever other data you used for initial and boundary conditions (see Using Multiple Meteorological Data Sources for instructions on doing this). This alerts metgrid.exe to use the appropriate flags (e.g., FLAG_QC, FLAG_QR, etc.) that instruct real.exe to process these variables, and write them to the wrfinput* file(s). Then wrf.exe reads these variables’ intial values.





Landmask Differences

When the LANDMASK differs between the input meteorological data and the geogrid-generated data, masked interpolation must be considered. Obtain a landmask field that defines the input data’s landmask (e.g., LANDSEA). If no landmask field exists for the data type, one will need to be created and named “LANDSEA” and stored in the WPS directory. This field can be used as a constant input to metgrid by adding the following tothe &metgrid namelist.wps record:

constants_name = 'LANDSEA'

Then use the following SST example to modify WPS/metgrid/METGRID.TBL:

name=SST
interp_option=nearest_neighbor
masked=land
#masked=both
#interp_land_mask=LANDMASK(1)
interp_mask = LANDSEA(1)
fill_missing=273.
flag_in_output=FLAG_SST

If SST is masked by some unique value over land (e.g., e-30), then having a landmask field is important. Having a matching landmask field for the SST is properly interpolated along water/land boundaries.





Using Multiple Input Data Sources

See Using Multiple Meteorological Data Sources for instructions on running the ungrib program with more than one meteorological data type.





Missing Data Values


Missing Relative Humidity (RH) Values

When RH data are missing for an entire level, ungrib fills in a value of 5% for missing RH from 300 to 70 mb levels, and 0% above 70 mb. Modifications to this process can be made in WPS/ungrib/src/rrpr.F.



Missing Surface Input

If unable to find surface fields or the input meteorological data being used (e.g., 2m T, 10m U, V, etc.), an alternative is to modify WPS/metgrid/METGRID.TBL by adding a line as follows for TT (do this for QV, UU, and VV, as well):

fill_lev = 200100:TT(X)

where X is the number representing the data’s lowest model level. For e.g., the following specifies that 1000 mb temperature is filled-in for the surface temperature value:

fill_lev = 200100:TT(100000)

Before running real.exe, set use_surface = .false. in the &domains namelist.input record.





Modifying Input

Modifying Initial SST

If your met_em* files contain an SST field, and your netCDF file global attribute contains FLAG_SST=1, the initial SST can be modified in the dyn_em/module_initialize_real.F file. Look for the following loop and make the changes there:

DO j = jts, MIN(jde-1,jte)
 DO i = its, MIN(ide-1,ite)
    IF ( skip_middle_points_t ( ids , ide , jds , jde , i , j , em_width , hold_ups ) ) CYCLE
    IF ( ( grid%landmask(i,j) .LT. 0.5 ) .AND. ( flag_sst .EQ. 1 ) .AND. &
         ( grid%sst(i,j) .GT. 170. ) .AND. ( grid%sst(i,j) .LT. 400. ) ) THEN
       grid%tsk(i,j) = grid%sst(i,j)
    ENDIF
 END DO
END DO

Save the file and then recompile WRF. Because there are no changes to any registry files, there is no need to clean the code or to reconfigure. Simply recompile, which should be much faster than a full compile.



Modifying Landuse


Modify Landuse for a Water-only Domain

To remove all land, for a water-only domain, modify subroutine landuse_init in wrf/phys/module_physics_init.F. Find the following code:

!Set arrays according to lu_index
     itf = min0(ite,ide-1)
     jtf = min0(jte,jde-1)
     IF(usemonalb)CALL wrf_message('Climatological albedo is used instead of table values')
     DO j = jts,jtf
       DO i = its,itf
         IS=nint(lu_index(i,j))

And add a line, similar to the “lu_index” line below:

!Set arrays according to lu_index
     itf = min0(ite,ide-1)
     jtf = min0(jte,jde-1)
     IF(usemonalb)CALL wrf_message('Climatological albedo is used instead of table values')
     DO j = jts,jtf
       DO i = its,itf
         lu_index = 16
         IS=nint(lu_index(i,j))

Save the file and recompile WRF to incorporate the change (no need to do a ‘clean -a’ or to reconfigure since the registry files are not changed). After running wrf, check the LU_INDEX field in the wrfout files for the resulting changes.



Modify Landuse for a Specific Area within the Domain

Various methods can be used to modify landuse in a specific location within a domain. For e.g.,

  • To convert all desert categories to agriculture land, modify the LANDUSE.TBL and/or VEGPARM.TBL to change the physics properties from desert to the desired land category.

  • To only change the desert area in a portion of the domain, use the NCL script read_wrf_nc.f, which reads and writes out the modified data. See NCAR Command Language (NCL) for details. This NCL presentation from the WRF Tutorial may also be useful.


Note

If data are modified prior to running real.exe, set surface_input_source=3 in namelist.input to avoid recalculation of dominant land categories (LU_INDEX).



Modify Landuse Type Codes

To modify codes representing landuse types, find the following section in wrf/dyn_em/module_initialize_real.F:

! Land use assignment

DO j = jts, MIN(jde-1,jte)
   DO i = its, MIN(ide-1,ite)
   IF ( skip_middle_points_t ( ids , ide , jds , jde , i , j , em_width , hold_ups ) ) CYCLE
   grid%lu_index(i,j) = grid%ivgtyp(i,j)

Modify the line beginning with “grid%” to:

grid%ivgtyp(i,j) = grid%lu_index(i,j)

Save the file and then recompile WRF to incorporate the changes (no need to do a ‘clean -a’ or reconfigure, since registry files are not changed). After running real.exe, see wrfinput_d01 for resulting changes. This should not affect other fields in the input file.





Modify Albedo

To use a different source of albedo (other than that found in the geographic static files), it can be treated like other atmospheric input. Since albedo is typically available at a coarser temporal interval, it will need to be manipulated so that it matches the boundary times of the other input meteorological data (e.g., if input meteorological data is available every 6 hours, albedo files should be available every 6 hours). It is probably simplest to use the same value for every 6 hour period, over the course of time at which the albedo files are available (e.g., if albedo values are available every 24 hours, there will be four files, every 6 hours within each 24 hour period, with the same value). If albedo is not in GRIB format, it must be converted to intermediate format.

Because ALBEDO is a variable name already used by WRF, the new input albedo needs a different variable name. Whatever name is chosen during WPS should be used throughout the WRF code, as well. For the sake of this example, we will call it ALBEDO_NEW.

Once ALBEDO_NEW is in intermediate format, modify the wps/metgrid/METGRID.TBL so it will look for the ALBEDO_NEW data - use any of the other similar field as a template to copy and modify for the ALBEDO_NEW variable. Masked interpolation should not be necessary. Then run metgrid to include both the surface/atmopsheric input and ALBEDO_NEW input. See Using Multiple Meteorological Data Sources for instructions on doing this. Following metgrid, ALBEDO_NEW should be in the met_em* files, along with the albedo calculated by geogrid, but as they are different names, it shouldn’t be a problem yet.

Modify WRF/Registry/Registry.EM_COMMON to add ALBEDO_NEW. Have it output to stream 4 (see the variable ALBBCK for guidance) so that it will be included in the wrflowinp_d* file after running real.exe - this allows it to update every time period. Set the following in namelist.input to ensure ALBEDO_NEW is read from the wrflowinp file(s):

&physics
 sst_update = 1

If using the Noah LSM, additionally set the following in the &physics namelist record so that the Noah LSM will not use albedo values from its table:

usemonalb = .true.

To ensure that ALBEDO_NEW is used from the wrflowinp file, instead of albedo created by geogrid, use one of the two following methods:

  1. Use NCO commands to read/write the wrflowinp file to remove geogrid’s albedo (which is actually ALBBCK), and make the ALBEDO_NEW information is included in the file.

  2. Add a line in wrf/phys/module_surface_driver.F) inside a loop for when sst_update is turned on, to state that ALBBCK = ALBEDO_NEW (see the variable SST/TSK as an example, keeping in mind that SST/TSK use special modifications to determine land/water points - which is not needed for albedo).


It is recommended to take these modification slowly - for e.g., prep the data for only a couple of days at first, then go through each step, checking that everything looks correct after running. Once you feel confident it is correct, do this for the entire time period.