Q1	What is WRFDA?
A1	WRFDA is a Data Assimilation system for the Weather Research and Forecasting model. You can learn more about the WRF model here. Data assimilation is the process of combining observations with computer model information to come up with a "best guess" of the state of the system: in this case, the atmosphere. Ultimately, the goal of atmospheric data assimilation is usually to improve a subsequent weather model forecast.
Q2	What does WRFDA do?
A2	WRFDA takes a "first guess" of the atmospheric state (either a WRF input file or WRF forecast output file), observations, and information about the uncertainty/error statistics of both, and produces a "best guess" based on all the input information. This output file can then either be analyzed on its own, or used to initiate a new WRF forecast.
Q3	What are the system requirements for running WRFDA?
A3	WRFDA is designed to be highly scalable and versatile, so depending on your case the system requirements will vary greatly. There are some known minimum requirements, which are listed at the system requirements page.

Q1	When I try to run WRFDA I get an error: "ERRORS while reading one or more namelists from namelist.input". How can I fix this?
A1	This error indicates that WRFDA had a problem reading one or more sections of your namelist.input file. Typically this is because an invalid namelist option was specified, or the option name was misspelled. Usually the error message will also state which namelist section had a problem (for example, "ERROR while reading namelist wrfvar4"), so check every namelist option in that section to make sure it is valid. See the User's Guide specific to your version; there is a section at the end listing valid namelist options. The second most common reason for this error is a missing "/" at the end of a namelist section. Namelist sections must begin with a line specifying the section name (for example, "&wrfvar1"), and end with a line containing the "/" character, indicating the end of the namelist section. A short example can be found below:  &wrfvar1    var4d = .false.,    print_detail_grad = .true.,  / See the Users Guide for more details. An example namelist can also be found in the source code, under WRFDA/var/test/tutorial/namelist.input
Q2	When I try to run WRFDA I get an error: "Missing or invalid AS1 ~ AS5 value for IT = 2". How can I fix this?
A2	This error is encountered when you attempt to use multiple outer loops in your minimization with the CV3 background error option. By default, WRFDA only has CV3 length and variance scaling parameters set for a single outer loop; for multiple outer loops you need to set these parameters manually in the namelist. See the section in the user's guide on "Modifying CV3 length scales and variance" for information on how to do this.
Q3	My WRFDA-4DVAR runs fail with a segmentation fault, "signal 9" error, or no error at all. What is the problem?
A3	The most common cause of failure for 4DVAR runs is running out of memory. This is because WRFDA must store the entire run of the nonlinear WRF model in memory (the first step of the minimization). The solution is to either add more nodes (if on a cluster), or if that is not possible, to reduce your memory footprint in one or more of the following ways: Use a smaller domain Use the same domain but a lower resolution (which would allow for less gridpoints and a larger time step) Use a smaller assimilation window Use a simple microphysics option for your WRFNL run, set by the namelist option "mp_physics". You can use a different microphysics option than you plan to use with WRF
Q4	I see one or more warning messages like this in my output, should I be worried? --------------------------- WARNING --------------------------- WARNING FROM FILE: da_scan_obs_ascii.inc LINE: 61 Error 29 opening gts obs file ob01.ascii
A4	WRFDA will always look for a conventional observation file, either "ob.ascii" (if ob_format=2 in your namelist) or "ob.bufr" (ob_format=1). For 4DVAR, there will be multiple files: one for each timeslot for ob_format=2 (ob01.ascii, ob02.ascii, ob03.ascii, etc.) or as many consecutive 6-hour-spanning files as are needed for ob_format=1 PREPBUFR files (ob01.bufr, ob02.bufr, etc.). All of these files are optional, so if you are aware that these files are missing, you can ignore the above-mentioned warning.

Q1	When running GEN_BE, it fails with the message "Stage gen_be_diags failed with error". How can I fix this?
A1	While this error message states that the failure was in "Stage gen_be_diags", this is almost always due to an error at an earlier stage. Look in the log files for stages 0–4 for more information. The most common errors are as follows: error 2 usually indicates incorrect specification of "NUM_LEVELS" (should be equal to e_vert - 1) error 24 usually indicates incorrect setup of your WRF forecast directories. See the entry below for help on setting up your GEN_BE forecasts properly.
Q2	How do I set up my WRF forecasts as input for GEN_BE?
A2	NOTE: This section now has its own stand-alone help page, go there to find even more information! In the WRFDA package, there is a script var/scripts/gen_be/gen_be_wrapper.ksh, which is used to run the GEN_BE utility as described in the user's guide. In that script, you are instructed to set a variable "FC_DIR", which is labelled as "where wrf forecasts are": an admittedly unhelpful label. GEN_BE uses the so-called "NMC method", where forecasts that are valid for the same date/time but initialized at different times are compared, to find an approximation of the background error (Parrish and Derber, 1992). GEN_BE compares a number of sequential forecasts using this method. The default setup in gen_be_wrapper.ksh is a "24-12" NMC comparison, which compares a 24-hour forecast with a 12-hour forecast (FCST_RANGE1=24, FCST_RANGE2=12). Let's say that we use /user/home/genbe/forecasts/ as our FC_DIR. If we are running from START_DATE=2012091200 to END_DATE=2012091900, we will need to have the following subdirectories within that directory:   $ ls /user/home/genbe/forecasts/   2012091100 2012091300 2012091500 2012091700 2012091900   2012091112 2012091312 2012091512 2012091712 2012091912   2012091200 2012091400 2012091600 2012091800   2012091212 2012091412 2012091612 2012091812 Within each of those directories should be the WRF output files from a forecast initialized at that time. In other words, each directory should have the output from a different forecast: you can not use one single, long forecast split into different directories. So the directory /user/home/genbe/forecasts/2012091200/ should have the 12-hour and 24-hour forecast files like this: $ ls /user/home/genbe/forecasts/2012091200 wrfout_d01_2012-09-12_12:00:00 wrfout_d01_2012-09-13_00:00:00 and the directory /user/home/genbe/forecasts/2012091212/should have the 12-hour and 24-hour forecast files like this: $ ls /user/home/genbe/forecasts/2012091212 wrfout_d01_2012-09-13_00:00:00 wrfout_d01_2012-09-13_12:00:00 and so on. GEN_BE will be comparing 2012091200/wrfout_d01_2012-09-13_00:00:00 to 2012091212/wrfout_d01_2012-09-13_00:00:00, 2012091212/wrfout_d01_2012-09-13_12:00:00 to 2012091300/wrfout_d01_2012-09-13_12:00:00, 2012091200/wrfout_d01_2012-09-13_00:00:00 to 2012091212/wrfout_d01_2012-09-13_00:00:00, and so on. The one-week period above is just an example: for guidance on how many forecasts you will need, see the next entry below.
Q3	How many forecasts are necessary for getting good background error statistics from GEN_BE? Do I need to continuously update by background error?
A3	The number of forecasts necessary to "train" your background error properly will vary depending on your application, but a two-week period of forecasts at 12-hour intervals (25 forecasts in total) should be considered a bare minimum for scientific purposes. Additionally, since the calculated background error can depend strongly on the exact weather regime found in those forecasts, you should use forecasts from a similar season that you plan on running WRFDA. For example, if you are running a data assimilation experiment on a July case using a be.dat background error file calculated from January forecasts, you may get poor results! As a real-world example: The Antarctic Mesoscale Prediction System (AMPS), which uses WRFDA, recalculates their background error each month, using the previous month of forecasts from their system as the input to GEN_BE.

Q1

Can my observations be assimilated in WRFDA?

A2

WRFDA is able to assimilate many different types of data, which are listed at this page. WRFDA can assimilate conventional observations in several formats: LITTLE_R (text-based format) through the OBSPROC utility NCEP PREPBUFR (binary format) MADIS (netCDF format), through the MADIS2LITTLER converter Other types of observations are assimilated in their own formats: Radiance data (AMSU, HIRS, IASI, etc.) are assimilated in BUFR format. Precipitation data is assimilated in a text format similar to LITTLE_R. A converter is provided for converting NCEP Stage IV data into this text format. Radar data is assimilated in yet another text format. If your observations are not in one of the formats listed above, you must convert them into one of the supported formats. LITTLE_R is likely the easiest. See the User's Guide for more detailed information.

Q1

I didn't get a wrfvar_output file. What went wrong?

A1

WRFDA prints out a lot of log information while it runs, including error messages if something went wrong. If you ran the program with MPI (dmpar–distributed memory parallelism), these log messages can be found in two sets of files: rsl.out.0000,rsl.out.0001, etc. (one log file for each processor you used) and rsl.error.0000, rsl.error.0001, etc. (one error file for each processor you used). If you did not get a wrfvar_output file, you should look in the rsl.out.* and rsl.error.* files for any error messages. Often the error message will be descriptive (missing input file, bad namelist setting, etc.) and you should be able to resolve the problem. Sometimes the program just quits with a segmentation fault or something similar; see this Q&A entry for more info.

Q1	What is "cycling" exactly? How do I set up cycling for WRF and WRFDA?
A1	"Cycling" is the process by which the output of a previous WRF forecast is used to initialize a new WRF forecast, rather than taking the initial conditions from some other analysis/forecast through WPS/real. This is usually done in the context of real-time forecast You can find detailed instructions on cycling with WRF/WRFDA in the relevant section of the Users Guide
Q2	What is the difference between "warm-start" and "cold-start" forecasts?
A2	These terms are widely used in the field of atmospheric modeling and data assimilation, however, to quote this site from the Naval Postgraduate School, "The terms cold start and warm start may mean slightly different things to different people." In the context of WRF and WRFDA, a "cold-start" forecast is when the first guess (fg) file provided to WRFDA is a wrfinput file from WPS/real, while a "warm-start" forecast is one where the first guess is a WRF forecast file (wrfout). Because of the ambiguity in what constitutes a cold-start or warm-start, we try to avoid using these terms in the official documentation.