============================= 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. .. |softwareStack| image:: SoftwareStack.png :scale: 90% |softwareStack| 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 :doc:`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 :doc:`Functional Testing `. .. toctree:: FunctionalTesting