Next: 2.3 SCIRun Modules, Networks, Up: 2. Concepts Previous: 2.1 Traditional Problem Solving Contents Index
The goal of integrated problem solving environments, specifically SCIRun, is to integrate the steps described in the previous example as components in a single, unified, extensible problem solving environment. The resulting function includes the ability to manage each step in a sequential computing process, and to create batch processes that execute repeated simulations. The functionality that sets SCIRun apart from most integrated software environments is the ability to intervene and control execution anywhere in the chain at any time during its execution. The ability to control a computer program during execution is termed computational steering.
To provide a non-technical analogy, adding computational steering to a software environment is similar to adding the ability to switch tracks in train travel. A train passenger can get on a train and get to a new destination, leaving all the details of the individual actions to the rail system machinery and staff. The route and the destination are fixed. Steering would permit each passenger, at any time during the trip, to request that the train take a new route, with different stops, and a different destination. In the example of the defibrillation simulation, computational steering allows users to interactively change parameters and settings as the simulation executes, performing his or her work in batch and interactive modes. Steering interventions might include adjusting electrode locations to stay within anatomically reasonable bounds, or refining the geometric model resolution in order to balance accuracy and execution time.
To achieve integration within the elements of SCIRun, data flows directly from one processing step to the next, without being diverted to a disk file or leaving the program. Output from each step is available as input to dependent steps. The underlying paradigm of SCIRun is data flowing between modules that each perform some operation. Integration between modules guarantees, that upon completion of their tasks, upstream modules pass their data to downstream modules, thereby forcing the downstream modules to execute in response. In the computational steering example, the user may alter electrode locations at any time, initiating a sequence of all necessary steps to recompute the simulation with the new configuration. The modification of the geometric model, finite element calculation, and visualization all proceed automatically and in the proper sequence, all managed by SCIRun. The combination of steering and component integration allows the user to spontaneously explore a problem.
While computational steering is a young field in computer science, there are a number of examples of such systems (in addition to SCIRun) described in the literature. Burnett[5], and Vetter and Schwan[6] give overviews of existing computational steering systems. Notable examples include CUMULVS[7,8], Progress[9], and Magellan[10] .
SCIRun is more properly considered a problem solving environment (PSE) framework upon which application specific PSEs are built. Each specific PSE, such as BioPSE, is a package with SCIRun. PSEs use and build upon data types, algorithms, and modules provided by the the SCIRun framework. PSEs provide application specific data types, algorithms, and modules.
It is important to understand the place of the software included in this package within the hierarchy of computational problem solving environments developed at the SCI Institute. From a historical perspective, SCIRun, which began development in 1992, was the original implementation of the computational framework[11,12,13,14,15,16]. Since then, SCIRun and its computational workbench infrastructure has been the basis of many significant application-specific projects. Examples are the DOE sponsored Uintah system [17] and the NIH sponsored BioPSE system. The target applications of the Uintah project are combustion, computational fluid dynamics, and mechanical modeling implemented on large-scale, distributed, shared memory architectures. The goal of the BioPSE project is to create software for geometric modeling, simulation, and visualization for solving bioelectric field problems. A secondary goal of the SCIRun system is to make source code for problem solving environments available to the scientific community.
To support extensibility in SCIRun, its infrastructure has undergone significant enhancement. SCIRun remains the core problem solving environment and the name is used to refer to the entire ensemble of software. A user may now use the core SCIRun software and augment its functionality with one or more packages such as BioPSE (as shown in Figure 2.1). SCI anticipates the collection of packages will grow as the SCIRun infrastructure becomes available to scientists and engineers in varied disciplines.
In addition to major projects that have leveraged and advanced SCIRun, there exist a number of smaller packages that extend SCIRun's utility. Examples include the Teem package for raster data processing, the NetSolve package for linear algebra subroutines (developed by researchers at the University of Tennessee and Knoxville), and a communications interface to the Matlab program. SCI has developed various forms of software wrappers or interfaces that allow SCIRun to leverage the strengths of these third party tools, links referred to as "bridges."
There are instances when a tighter level of integration than a bridge between SCIRun and third-party software is necessary. One example is the addition of MPEG support for capturing animations from the SCIRun Viewer module, for which the Berkeley and Alex Knowles' MPEG encoding tools are used. To indicate whether or not such tools are available, the configure scripts for SCIRun contain optional control flags.
SCI believes the combination of a robust infrastructure and modular extensibility through packages and third-party libraries will allow SCIRun to grow, and adapt to changing needs and opportunities.
