WRF Output Directories

**UPDATE (10/13/15)** I have been working with an older version of WRF (v3.4.1) and noticed that the integration routine would consistently be unable to find the wrfbdy file necessary to get started. After wading through WRF error messages, it appeared as though the bdy_inname namelist option was being ignored. It turns out that, if the routines thought the file was not open for reading, it would revert back to the default namelist option (i.e., thinking it was in the root WRF directory). This occurs in ./share/mediation_integrate.F file. I amended the code to use the construct_filename2a in cases where the file was deemed closed and things began to work again. Even by WRF v3.5.1, this was changed and works correctly out of the box. Just be aware that older/newer versions may need additional modifications.


There is actually a little-known feature in WRF where you can have your input and output files placed in specific directories. This can be really useful, especially if you are dealing with a parallel file system (e.g., Lustre) and want to set up efficient striping for directories that will hold particular files. By setting up directories and setting their striping settings ahead of time, I was able to double my I/O performance for my WRF runs. Here is how it works:

  1. Set the appropriate namelist values, for example:
     history_outname = "./wrfout/wrfout_d<domain>_<date>",
     rst_outname     = "./wrfrst/wrfrst_d<domain>_<date>",
     input_inname    = "./wrfinit/wrfinput_d<domain>",
     input_outname   = "./wrfinit/wrfinput_d<domain>",
     bdy_inname      = "./wrfinit/wrfbdy_d<domain>",
     bdy_outname     = "./wrfinit/wrfbdy_d<domain>",

    Here, I have told WRF to output files into three (wrfout, wrfrst, and wrfinit) directories. These namelist options are some I just stumbled upon are not documented in the manual, to my knowledge. The namelist options were intended to allow for a user to customize the names of the input/output files prior to the model run, but, with the addition of some simple directory structure, you can get WRF to place them anywhere you would like.

  2. Hack at the WRF code to get WRF to actually utilize your options you just gave it. WRF does implement the changes for the history and restart files perfectly find; however, WRF does not do so for input and boundary files. After digging through the WRF code, I noticed that the input and boundary file naming functions were hard-coded to only use wrfinput and wrfbdy, respectively, in their names. What this means is that any added directory structure you gave WRF in the namelist will just disappear into the FORTRAN abyss. To get around this, you need to edit three files: ideal_em.F, real_em.F, and ndown_em.F. What you are looking for are where the variables inpname, bdyname, and outname are passed to a subroutine called construct_filename1. You’ll notice that those subroutines have a hard coded portion, such as this:
    CALL construct_filename1( bdyname , 'wrfbdy' , grid%id , 2 )

    What you want to have is this:

    CALL construct_filename2a ( bdyname , config_flags%bdy_outname , &
                                grid%id , 2, '' )

    The key changes are the subroutine used and use of config_flags%bdy_outname. The ‘wrfbdy’ argument in the first subroutine hard-codes all boundary files to only have that prefix and not allow the user defined names to be used from the namelist. For reference, the subroutines that construct file name are defined in the module_io_domain.F file. You can similarly change the subroutines and input arguments for the other namelist variables listed above. For a full list of these variables just search for inname or outname in the registry files.

  3. Recompile the WRF code and enjoy.