Technical Notes
The ehratmworkflow package is where everything comes together to generate custom workflows of WPS, WRF, Flexpart WRF, and utilities. As the following graphic illustrates, ehratmworkflow occupies the top (or application layer) of a software stack, interacting with underlying “service” components solely through calls to functions in the well-defined API for the ehratm package components.
The philosophy behind this common software design approach (The TCP/IP networking protocol stack is a classic inspiration) is that the details of the ehratm components implementation should be of no interest to applications in the ehratmworkflow level. All they should need to know is that there is a set of functions with well-defined APIs that present consistent behaviour when invoked. With this design paradigm, as long as maintainers of the ehratm layer respect the consistency of the API (i.e. they don’t change it to the detriment of software that has been using it) presented to users, software such as the ehratmworkflow level will continue to behave as originally designed.
The ehratmworkflow layer is but one of an infinite number of applications that could be built, and it reflects the perceived goals of the planners and the developers in the context of supporting a flexible collection of NWP components for the primary goal of running WRF simulations to produce custom meteorological fields inputs for subsequent Flexpart WRF ATM simulations.
The primary design goal of this component has been to support custom workflows solely through workflow namelist (wfnamelist) definitions. The wfnamelist is the sole input for the ehratmwf.py program, which uses its specifications to run the workflow.
By virtue of the fact that the ehratmworkflow layer relies on a properly functioning ehratm layer, and the ehratm layer relies on a properly functioning nwpservice layer, and the nwpservice layer relies on a correctly implemented nwpinstall component (which installs the WPS, WRF and Flexpart WRF distributions in a standard way that’s compatible with the way the nwpservice layer works), the tests described in this document tend to be tests of the overall system. If the tests pass, then it’s likely that the entire system is installed correctly and, if not, it’s possible that the developer will need to look into one of the constituent underlying components, all of which have their own testing environments.
A robust overview of usage of the ehratmwf.py workflow driver was presented in the User Perspective document, and this is a good place for the general user to start. Those with more technical interests may want to be able to run through a small or large set of automated tests of the system, especially if changes have been made, and this is facilitated with the clibatchtest.py program discussed next in Functional Testing.