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

Post a Comment

Popular posts from this blog

Sharing the Network: From Circuit Switching to Packet Switching (The Hitchhiker's Guide to Computer Networks)

Prelude ... From Circuit Switching to Packet Switching The simplest approach for two people to communicate over long distances is to connect them through a dedicate physical wire. However, how would we scale that model to a million people that individually want to be able to communicate with everyone else? One approach is to extend wires between all pairs of users, requiring hundreds of billions of wires.  This is definitely not a good way to design a network. So what's wrong with that design? First, it is unlikely that every single person in that network will want to talk to everyone else at the same time. This means that we can use fewer wires. Second, not all connections are created equal. Longer wires cost a lot more money than short ones. Our design should have short wires whenever possible. Also it will be nice if the cost of extending long wires is shared between multiple users at the same time. Let's revisit our connection strategy. Rather than extending wires betwe...
Read more

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

Correction (4/24/2014): for your driver to work the AR Drone 2.0 you have to compile the kernel version provided by Parrot which can be found here https://devzone.parrot.com/projects/show/oss-ardrone2 One of the down sides of "out of the box" AR Drone 2.0 is that you can't control multiple drones from the same machine. Another down side is that you can't attach USB devices except flash memories and some other predefined devices due to the limited nature of the busybox deployed on the drone. To over come the first down side without manipulating the WiFi configurations of the built-in WiFi card (i.e. you don't want to mess up your new drone), you will need to overcome the second problem (i.e. install a WiFi dongle and its driver manually). In this tutorial, I try to walk you through the steps to do just that. I assume that you are working a Linux machine (seriously we are not going to compile drivers on Windows). Ubuntu is preferable ! Because the Drone has a...
Read more

Video on Demand: Part 1 (The Hitchhiker's Guide to Computer Networks)

Image
Data from the 2019 Global Internet Phenomena Report Video is the dominant type of traffic on the Internet. In 2019, video on demand constituted 60% of the total global Internet traffic. The image to the right shows the huge gap between the bandwidth demand of video streaming and the second highest application which is web traffic (think email, blogs, and news). This means that if you are in the computer networks business, you are pretty much in the business of video delivery. So the biggest question here, what is the best way to deliver video?  The "best" in this context can mean a couple of different things. It can mean delivering the best quality video for the user. Video quality does not only refer to whether a video is in HD or UHD but also whether it freezes and hangs or not. The "best" way to deliver video can also mean the most cost efficient way. If we can save 1% of the cost of delivering all videos on the Internet, we can save tens of millions of dollars i...
Read more