This page describes the parts of the HWRF system that describe or run the fortran and C programs who prepare, produce or deliver the HWRF output.
Modules hwrf.wrfbase and hwrf.wrf: Describing WRF Simulations
These modules implement a way to describe and monitor WRF simulations. Although these are two modules, they should be thought of as one. They are separated to avoid cyclic dependencies in modules that hwrf.wrf requires, but that must import hwrf.wrfbase. The hwrf.wrf describes an hwrf.wrf.WRFSimulation as an array of hwrf.wrf.WRFDomain objects, one per WRF domain. It keeps track of active output streams, and can produce an hwrf.wrfbase.WRFOutput object for any output time of any stream.
The WRFSimulation object does not run the actual simulation, nor the wrfanl, wrfghost or real jobs. That is done by the hwrf.fcsttask and hwrf.mpipomtc modules. However, the hwrf.wrf.ExternalWRFTask is able to keep track of a running WRF simulation, given the directory in which it is running. That class underlies the implementations in hwrf.fcsttask and hwrf.mpipomtc. It sets up the namelist, and after WRF starts, it keeps track of output files as they appear and monitors the rsl.out.0000 file to detect successful completion or failure of the WRF simulation.
See the Python docstring documentation for detailed information about all of these classes.
Module hwrf.wps: Running the WRF Preprocessing System
This module contains the Ungrib, Metgrid, and Geogrid classes, which run those three components of the WRF Preprocessing System (WPS). This produces input to the real_nmm program, run by the hwrf.fcsttask module. Unlike most of the HWRFTask subclasses, these three are not built to run in their own directory, and deliver to intercom. Instead, each WPS initialization should run all three of these steps in one directory. The Geogrid and Metgrid will deliver the final output of the combined three object initialization to the intercom directory, and then the temporary work area can be deleted.
The Ungrib, Geogrid and Metgrid are all subclasses of hwrf.wps.WPSTask, which implements functions common to all three. In particular, it is able to read an hwrf.wrf.WRFSimulation class's data, getting domain sizes, boundary input times, and the like. That prevents having to place detailed information available in the conf file. Also, the WPSTask is able to get input data from the parent task through the hwrf.input module classes.
Module hwrf.fcsttask: Preparing and Running WRF Simulations
This module contains classes that can run the wrf.exe and real_nmm.exe programs. Everything that runs these programs is in this module, except for the POM-WRF coupled simulation. The hwrf.mpipomtc module handles coupled simulations. These are the notable classes in the hwrf.fcsttask and their meanings:
class FcstTask – the abstract base class of all other classes in this module, and of the hwrf.mpipomtc.WRFcoupledPOM. This implements add_input and link_input routines to automate supplying of input sources for given types of inputs. For example, one can supply a list of possible sources for wrfanl files via add_input: first the GSI, then relocate, then the original wrfanl from GFS. If the first cannot be found, the link_input will take the second, and failing that, the third.
class WRFTaskBase – Implements more specific cases than "add_input:" add_geogrid, add_metgrid, add_prep_hybrid, etc. The class implements functions for all inputs required by the wrf.exe and real_nmm, as run by HWRF.
class RealNMM – runs the real_nmm.exe
class WRFAnl – runs the wrf.exe to produce wrfanl files
class WRFGhost – runs the wrf.exe to produce ghost files. These are very large wrfanl files. This is a subclass of WRFAnl that just disables output and renames the wrfanl files to ghost_d<domain>
class WRFAnl4Trak – subclass of WRFAnl that outputs the 1 minute forecast file for the outer domain, and rewrites its output time metadata to read the analysis time instead. This is intended to be used with a post and tracker, to get the parent vortex information. The initial time cannot be used since the winds are invalid until after the first physics timestep.class WRFAtmos – runs an atmosphere-only WRF simulation. Contains an hwrf.wrf.ExternalWRFTask object as a private member variable. That object keeps track of the output files, and monitors the rsl.out.0000 file. The WRFAtmos handles initializing the inputs and starting the actual wrf.exe.
Module hwrf.mpipomtc: The WRF-POM Coupled System
This module does two things: runs the POM initialization, and starts the WRF-POM coupled system. Note that the pom package implements the actual initialization, and creation of the namelist. The pom package has absolutely no configuration options whatsoever. All configuration must be done by manually modifying the ush/pom/*.py files.
class POMInit – this is a wrapper around the pom package, which runs the initialization of POM.
class WRFCoupledPOM – a subclass of hwrf.fcsttask.WRFAtmos that runs the coupled model. It adds code to copy the POM input from a POMInit object, and coupler (hwrf_wm3c) input as well. It adds the ability to configure the number of coupler, POM and WRF MPI ranks. Note that you must specify the number of WRF ranks. That is done via the wrf_ranks conf variable: set it to the integer number of ranks.