Weather Research and Forecasting Model Explained (Part 3) - System Architecture and Parallelism

WRF ,as mentioned in part 1 and part2, is a system designed for both operational and research purposes, and to run on systems from conventional laptops to super computers. The design of such a versatile system is a real challenge.
In this post we will explore some of the WRF's Software Framework design and explain the functionality of the different layers of the system. Also we'll discuss how the system handles parallelism in different hardware environments.
Software Framework Architecture[1][2]:
(The following functionalities doesn't include parallelism handling)

 Figure1: Hierarchical WRF Software Design
As it appears in Figure 1, the system design has 3 layers:
The Driver Layer:
It defines and allocates domains and associates them in a nest hierarchy. It also manages the flow of a system run as it's responsible for stepping the time for the loop mentioned in part1. And it's responsible for I/O operations. 
The Mediation Layer:
It interfaces between the two other layers. For example the driver layer uses Fortran 90's derived data-types while the model layer deals with scalar arrays only. The mediation layer is responsible for dereferencing the scalar arrays from the derived data types.
The Model Layer:
It performs the actual weather prediction computations like physics calculations and time integration.

Parallelism (Two Level decomposition):

Due to the versatileness of the system mentioned before, parallel systems including shared memory and distributed memory architectures. Two level decomposition addresses that problem by decomposing domains in patches and decomposing patches into tiles. With patches being "a section of a model domain allocated to a single memory address space" and tiles being "the amount of a patch that is allocated to a one thread of execution and every cell of a patch that requires computation must fall into some tile"[2].
The driver layer is responsible for distributed and shared memory allocation. Also it handles the decomposition of domains into patches and patches into tiles. While the model layer handles only tiles. This part reflects one of the best design features of the WRF Software Framework; Model layer is meant to be programmed by meteorological scientists not computer scientists, so handling parallelism issues (i.e. synchronization, memory allocation, communication, etc) was made part of the driver layer leaving the model layer to have only "meteorological calculators"-tiles callable subroutines.

[1] John G. Michalakes, Michael McAtee and Jerry Wegiel, SOFTWARE INFRASTRUCTURE FOR THE WEATHER RESEARCH AND FORECAST MODEL
[2] Weather Research and Forecast Model 1.2: Software Design and Implementation

Comments

Popular posts from this blog

Integrating Click Router and GNURadio

Attaching a WiFi Dongle to an AR Drone 2.0 (a.k.a. Compiling Drivers for ARM Based Devices)

CUDA compilation on Linux (Makefiles)