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.