1.5      WRF software and tools update

 

Gill, David, B. Bonnlander, J. Liu, K. Manning, W. Huang, National Center for Atmospheric Research, and J. Michalakes, National Renewable Energy Laboratory

 

Within the last couple of years some software inside the WRF model and tools specifically for the WRF model have been introduced that provide support for code contributors and assistance for those running operational systems.  The WRF group has been increasingly requesting additional work on the part of contributors, such as guidelines to follow and tests to conduct.  A new automated scripting system is available for use, and will be required for the next release cycle starting this fall.  Another group that is typically hit with WRF difficulties are those involved in real-time forecasting.  With support from an external contributor, the previously existing capability for distributing model output is now attractive since "stitching" the pieces together is quite simple.  This can now be combined with the HDF compression available in NETCDF4.  For most users, the most tedious portion of the WRF system is the build mechanism.  This necessarily has users insure that the various libraries for WRF (or worse, for WPS) are all compatible.  A new tool is available to assist users  in this regard. 

 

Code Contributors 

Information for code contributors may be found in http://wrf-model.org/users/testing.php.  This contains useful dates (such as when code needs to be sent to the WRF Developers' Committee), tests that need to be conducted, available contacts, and some minimal coding standards.  While most of these have been available for several years, there is a new addition that will become mandatory this fall.  The WRF Testing Framework (WTF) is a scripted set of very short WRF builds and forecasts that developers run.  The purposes of the tests are to verify that the code does no harm to other physical parameterizations, that the code is able to maintain parallel-identical results, and that the proposed changes are neutral to the selection of the major WRF build choices:  ARW, NMM, Chemistry, idealized tests, and various nesting options.  This new system is able to test approximately 150 short forecasts via a user-definable series of namelists and METGRID input files.

 

WRF and WPS Build Tool 

To assist new users, or even experienced users porting the WRF system to a new compiler, the WRF users now have access to a tool that will interactively build the necessary libraries.  The code is a combination of scripts, library tar files, and the latest released WRF system source code.  The tool is available at http://www2.mmm.ucar.edu/wrf/users/FAQ.html.  The user downloads the tool, and after uncompressing and untarring the files, runs the script.  The user needs to have valid compilers (both Fortran and C), and the usual set of script and Unix-y tools (make, etc.).  The tool has been used on both Linux and Darwin systems, and has been used with Intel, PGI, and GNU compilers.  The NetCDF and MPI libraries are built for WRF, and the jasper, jpeg, zlib, and png libraries are built for WPS. 

 

Reduced Output Time 

With the increasing computer power available, users are being drawn towards larger and larger domains.  On many systems, the time to write the model output dominates the total time to solution.  A number of advances have been made in the previous years with parallel NetCDF, and the use of the quilting option.  However, for nested forecasts or forecasts with multiple output streams, quilting is difficult to tune.  Using the existing option to split the output files so that each distributed memory processor outputs its own file has been used frequently for restart files, but has been usually ignored when the traditional model output is considered.  Primarily this was due to a convenient way to aggregate the collection of files together again.  A combination of external contribution and internal development has produced a tool that is able to reconnect large numbers of files quickly and is able to run in parallel.    To reduce output file size, and the reasonable assumption would be to then reduce the amount of time spent on output, the WRF users may now select the NetCDF4 compression (from the HDF package). With more expensive microphysics packages being selected, these "near zero" values compress well.  It is typical to see files sizes that are approximately half the size of standard NetCDF classic files.  The last way to assist in the reduction of file size is to restrict fields that are selected for each stream.  Several years ago this became a run-time option, no longer requiring users to modify the Registry file as a compile-time option.  With a simple text file, users can remove unnecessary fields or variables that they tend to never consider.