The EDSS/Models-3 I/O API is a library of routines which provide
machine-independent, network-transparent, selective direct access to
modeling data in modeler-oriented terms. This paradigm of operation
greatly reduces modeling complexity (as compared to models built around sequential files), since a model does not need to know the detailed structure of a file it reads (e.g., the exact list of variables in the file, their order, nor even the precise time step structure). What it does need to know is the names, types, and dimensionality of the variables it wants to read. Notice that this kind of selective direct access I/O makes for models that are more robust, and less "brittle" as well: if a new variable is added to a file, only those modules which write or read the new variable need to change; all others are unaffected. EPA'a Models-3 and NCSC's MAQSIP air quality models take advantage of this flexibility in order to construct "plug-compatible interchangeable-part" modules implementing the various relevant atmospheric processes.
Just as a model's access to disk files should not demand intimately detailed internal knowledge of the structure of the file or of its writer, coupled models composed of cooperating concurrent processes should not require that receivers of data possess intimately detailed internal knowledge of senders (and vice versa). Ideally, a model should use the same programming interface for disk I/O and for virtual files used for model coupling, and should not "need" to know whether its inputs are coming from disk files or from other models coupled to it. Synchronization and scheduling should be done on the basis of data availability (i.e., READ operations for data not yet produced should put the reading process to sleep until the data becomes available, and then wake it up). Notice that this kind of data interface allows the researcher to "snoop" on the output of models even while they are running, without having to make any kind of special provisions in the code.
We have implemented an extension to the EDSS/Models-3 I/O API that has these properties, using "mailboxes" in PVM version 3.4 as a lower layer. In our implementation, the programming interface is completely
unchanged (so that the modeling code is unchanged as well): the decision is made at program launch-time as to whether a particular
data set is a "real file" resident on disk or a "virtual file" resident in a PVM mailbox. We have written I/O API input and output modules for the MM5v2 meteorology model and for a new high-performance version of the very-high-resolution TOPLATS hydrology model, and are beta-testing the coupling mode of the I/O API used by these modules in two projects, and using the MM5 I/O API module in another:
- Two-way coupling between MM5 and TOPLATS, in which TOPLATS provides surface fluxes to MM5, and MM5 provides ambient surface atmospheric parameters to TOPLATS.
- Coupling of MM5 with the SMOKE emissions model and the MAQSIP air quality model at the advective time scale of MM5, to achieve an integrated meteorology-air quality modeling system. For this project, the combined executable size of a monolithic executable would be on the order of 250 megawords, far exceeding the memory capacity of our Cray T90 vector supercomputer. Allowing the combined system to run as cooperating concurrent processes on a variety of machines allows us to get around this memory-size problem.
- A joint project between Penn State and NCSC to perform real-time nested mesoscale forecasts of tropospheric ozone using MM5, SMOKE, and MAQSIP (using files instead of PVM mailboxes for coupling).
Scientific aspects of these projects are being described by a number of other papers in the 14th Conference on Hydrology, the Symposium on Interdisciplinary Issues in Atmospheric Chemistry, and the 13th Symposium on Boundary Layers and Turbulence here at the 79th AMS meetings here in Dallas. We will report here on both the formance
and the software engineering aspects of the coupling mode of the I/O API, as applied to these projects