`` Mediated Model Coupling''
Prof. Judith B. Cushing
The Evergreen State College
Olympia, WA 98505
E-mail: judyc@evergreen.edu
URL: http://192.211.16.13/individuals/judyc/home.htm

Advances in computer science have revolutionized research in the natural sciences. The scientific community now routinely relies on simulations involving complex computations on huge, multi-dimensional data. Many of these simulations have become valuable research tools in understanding isolated phenomena and, thus, constitute the important but small, first steps towards an ultimate goal of understanding complex interactions among physical processes.

To achieve this ultimate goal, existing models must be coupled into larger simulations. The support needed for this coupling goes significantly beyond traditional mechanisms for interface specification, input/output format conversions, and interprocess communication. The scientists, concerned about the scientific viability of the coupled models, must be given the tools to dynamically explore model correlations and relationships at a very high, domain-specific level, shielding them from the details of high-performance computing while supporting the translation of their hypotheses into real, working systems for evaluation.

Computational infrastructure to support this class of activity will involve considerable new research. Jan Cuny, Al Malony and Doug Toomey at the University of Oregon, Lawrence Snyder at the University of Washington and myself are working towards developing such support, which we call ``mediated'' model coupling.

My own role in this work will be for database support for domain specific computational environments. I think of this as being a persistent store, not only of empirical data that can be used as inputs to the programs, and the program inputs and outputs, but also the application profiles themselves. An application profile includes:

• Application semantics (signature) - inputs/outputs/parameters,
• Application function - such that one familiar with the domain can understand what the program does,
• Methods (transformations) between domain specific data types (defined below) and the application inputs (and parameters, if any of those require calculation from other data).
• Installation-specific information (optional) - which provides a place for the environment to look to determine where the program resides.
• Process information - which could be used to store inputs, parameters, and outputs of specific invocations of an application (i.e., a computation), as well as current status and restart information.

There are many interesting CS (DBMS) questions that are more widely applicable than to this domain, or even just to computational science:

• How to characterize programs (and maybe processes) as data (objects), so that the DB can hold information about them.
• Semi-structured queries (parsing) of somewhat formatted text, e.g., program output for input to the DB (so that one can do queries and other operations on this data). The data is not necessarily well behaved, and the query or parsing may have to be mediated by a real person. One would also like a domain specific query language for the database, so that it can generate inputs to programs in the right format.
• Initially, we assume that the applications are black boxes, but eventually might want to define the domain specific database interface as a pattern to which application programmers (domain scientists) can write, such that newly interfaced computational applications could take inputs from the database and write outputs to the database, without the programmer of the application being a database programmer.
• More easily extensible schema languages would be critical for such an infrastructure, so that specializations to existing data types can be added to the schema, or one data type can be replicated across different applications.