Over the past two decades, computer simulation and visualization have significantly influenced and improved the field of biomedicine, as they have other areas of science and engineering. While some images and visualizations facilitate medical diagnosis, others help physicians plan surgical procedures. For example, visualization tools have been critical in planning recent brain surgeries to correct large aneurysms in patients being treated by neurosurgeons at the University of Utah Medical Center. Biomedical computing and visualization techniques are used for medical training. Computer simulation lets biomedical researchers subject increasingly sophisticated quantitative and qualitative conceptual models of biological behavior to rigorous quantitative simulation and analysis. Visualizing the results of these simulations helps scientists explore and understand the simulation behavior and results.
The desire to understand biological systems drives researchers to create increasingly sophisticated computational models. While such sophistication is essential to good research, the resulting complexity of the scientific computing process has become a major hindrance to further use of advanced computing tools in biomedical research and patient treatment. Sources of this complexity include the number of equations and variables required to represent realistic functions, the size of the resulting systems and data sets, and the diversity of the computational resources required to support significant understanding of biomedical phenomena and medical treatment [2]. Biomedical computing researchers collect multichannel and multimodal data from real-time collection instruments, access large distributed databases, and rely on simulation and visualization systems for navigating biomedical systems and models.
Managing large-scale computations requires powerful hardware and efficient, transparent software that frees the user to engage the complexity of the scientific problem, rather than the complexity of the tools themselves.
Managing these large-scale computations requires powerful hardware and efficient, transparent software that frees researchers and clinicians alike to engage the complexity of the scientific problem, rather than the complexity of the tools themselves. Unfortunately, such biomedical computing software does not exist today.
The current selection of computational tools is increasing so quickly that navigating and choosing from among them has become its own challenge (see the article by Homa Javahery et al. in this issue). The need to integrate software is especially great when scientists seek to build models that span spatial or temporal scales or that cross physical systems. No individual researcher has the skills required to master all the computational and biological knowledge needed to create geometric and mathematical models, map them to numerical algorithms, implement them efficiently in modern computers, visualize the results, and then understand them as they pertain to the specific biological system under investigation. Modeling complex systems requires a multidisciplinary team of specialists, each with complementary expertise and supported by a software infrastructure that integrates that expertise into a complete software system.
Problem-solving environments (PSEs) provide a natural platform for integrating and leveraging multidisciplinary expertise to create complete systems for biomedical computing [2, 3, 7, 9]. Such systems solve the challenge of interfacing disparate elements while also providing a level of functional abstraction researchers need in dealing with complex software systems. PSEs also provide infrastructure for integrating computational knowledge. PSEs may incorporate a number of specific elements, including knowledge of the relevant discipline(s); the most useful computational techniques, algorithms, and data structures; the associated programming techniques; the relevant human-computer interface design principles; the applicable visualization and imaging techniques; and methods for mapping the computations to various computer architectures [2].
PSEs can also consolidate knowledge from a range of experts into a system providing end users a powerful set of computational tools. The Scientific Computing and Imaging (SCI) Institute at the University of Utah has a long history (since 1994) of research involving PSEs for scientific computing, including SCIRun, BioPSE, and Uintah [5, 6, 8].
SCIRun and BioPSE
The SCIRun PSE supports the interactive creation, investigation, and steering of large-scale scientific computations. It has been enhanced through the efforts of two large research centers that use it as their core software system: the Center for the Simulation of Accidental Fires and Explosions (C-SAFE), a U.S. Department of Energy Level 1 Center; and the National Institutes of Health’s National Center for Research Resources (www.ncrr.nih.gov) Center for Bioelectric Field Modeling, Simulation, and Visualization. Due largely to these efforts, SCIRun has now evolved into a comprehensive software environment for scientific computing applications.
The SCIRun component model is based on a generalized dataflow paradigm that allows the tight integration of computational components and visualization components. A dataflow model involves three processes in sequence: data is sent to a software component; the component manipulates the data in some manner; and the new data then passes downstream to the next component for further manipulation.
SCIRun can be viewed as a computational workbench in which scientists design and modify simulations interactively via a component-based visual programming model. SCIRun also facilitates interactive debugging and steering of large-scale, typically parallel, scientific simulations by, for example, enabling scientists to modify geometric models and interactively change numerical parameters and boundary conditions. An especially important aspect of SCIRun is that it combines the setting of input parameters, computation, and visualization into one tool that is used in real time, as opposed to the traditional practice of doing these three tasks separately and in batch mode.
While SCIRun provides the framework and software infrastructure needed to support this extensive functionality, the individual components encapsulate the actual science one might wish to carry out. The modules are standalone pieces of software designed by various individuals or groups and contributed to the system. Interesting problems are solved through the combined functionality of a number of such modules.
SCIRun consists of a layered set of libraries. Though it uses an object-oriented design, its developers have carefully avoided overuse of the object-oriented paradigm, which could threaten efficiency. In implementing the SCIRun kernel and modules, we have leveraged a powerful toolbox of C++ classes within SCIRun, tuning them for scientific computing and operation in a multithreaded environment, and have employed an efficient reference-counting scheme with smart pointers to allow different modules to efficiently share common data structures.
The BioPSE package introduced a generic Field data structure to SCIRun that is used to represent any geometric domain and a set of data values defined over that domain. The design challenge for Fields was to create a general and flexible data structure without sacrificing system performance. Since Fields are the predominant primitive in the SCIRun dataflow architecture, they must be designed to meet the various needs of our users. Fields have greatly reduced the complexity of many of the existing modules while simultaneously enhancing their functionality.
The ShowField module in BioPSE/SCIRun, for example, is a generic tool for visualizing a Field. It takes an arbitrary Field and a colormap as input, and as output generates geometric scene-graph primitives for subsequent rendering. For different types of Fields the geometric primitives might have elements in common but might also have elements that are distinct. Before BioPSE/SCIRun was available, for every possible combination of geometry, user-selected rendering parameters, colormap options, and data value types, a specific piece of code would be necessary to handle that particular set of options. Maintaining such code is prohibitively complicated. In contrast, by implementing a consistent interface to all of our Field types, we have abstracted away the details of the different geometry types in the ShowField module. This approach to abstracting geometry greatly reduces the number of lines of code required for ShowField, makes the code much easier to understand for both developers and users, and reduces the likelihood that the code will contain bugs. Moreover, it dramatically simplifies the process of adding a new geometry or data value type to BioPSE/SCIRun; a new type just needs to support the required interface in order to be renderable by the ShowField module.
A common drawback to generalized interfaces is that generalization typically comes at the price of performance. In order to support a general interface, the code cannot know in advance what type of Fields might arrive as input; optimization is therefore difficult to do. Dynamic compilation and loading is used to permit optimization based on the input types. It compiles optimized code for each specific case (as soon as a module knows which specific types of Fields have arrived as input); the system then dynamically loads the resulting new object and executes it. For users, these operations are all transparent, and for developers they are simple to use. The advantage of this technique is that SCIRun generates only specific optimized code for the types of Fields about which a particular user is interested. (For a complete discussion on dynamic compilation, see [4].)
The next generation of SCIRun (tentatively called SCIRun2, possibly available in 2005) is a framework combining the SCIRun infrastructure with common component architecture (CCA) [1] and connections to other commercial and academic research-oriented component models. SCIRun2 [11] will utilize parallel-to-parallel remote method invocation to connect components in a distributed memory environment and be multithreaded to facilitate shared memory programming. It also will have an optional visual-programming interface. Overall, SCIRun2 will provide a broad approach to component-based biomedical simulation to allow scientists to combine a selection of tools for solving problems of interest. The overarching SCIRun2 design goal—giving computational scientists the ability to use the right tool for the right job—is motivated by the diverse needs of biomedical and other scientific users.
While visual programming is natural for computer scientists and for some engineers accustomed to writing software and building algorithmic pipelines, it is overly cumbersome for many application scientists.
EEG simulation and visualization. Figures 1 and 2 illustrate the functionality of SCIRun and BioPSE with an example of electroencephalographic (EEG) source localization. Figure 1 outlines the dataflow network implementing the solution. The input data files loaded at the top of the network include the finite element mesh (FEM) that defines the geometry and conductivity properties of the model and a precomputed lead-field matrix that encodes the relationship between the electric sources in the domain and the resulting potentials that would be measured at the electrodes. Farther down in the network, a set of modules optimizes the dipole location in order to minimize the lack of conformance between the measured potentials from the electrodes and the simulated potentials due to the dipole. Finally, visualization and rendering modules provide interactive feedback to the user.
A major hurdle to SCIRun becoming an everyday tool for scientists and engineers has been its dataflow interface. While visual programming is natural for computer scientists and some engineers accustomed to writing software and building algorithmic pipelines, it is overly cumbersome for many application scientists. Even when a dataflow network implements a specific application (such as the bioelectric field simulation network provided with BioPSE and detailed in the BioPSE Tutorial), the user interface components of the network are presented to the user in separate user-interface windows, without any context for their settings. For example, although SCIRun provides a generic file-browser user interfaces for reading-in data, many such user-interface elements exist in the dataflow network, each with the same generic presentation, and are thus indistinguishable. The user cannot tell which type of file each browser expects.
One approach to improving user-interface support for SCIRun is to create PowerApps, or a customized interface built atop a dataflow application network; see [10] for examples. The dataflow network controls the execution and synchronization of the modules comprising the application, but SCIRun developers have consolidated the generic user interface windows, replacing them with an application-specific interface.
Included with the version 1.22 release of BioPSE (July 2004) is a PowerApp called BioFEM based on a FEM network; Figure 3 shows the striking difference in user interfaces between BioPSE and BioFEM. In the dataflow version of the application, users have separate interface windows for controlling different aspects of the simulation and visualization, but nothing about these windows indicates the context for the associated controls. The PowerApp version of the same functionality, by contrast, has a much more streamlined and context-associated interface and a much simpler appearance. The full flexibility of the more general dataflow interface is hidden but still available should the researcher require functionality not provided by the specialized interface.
The future of biomedical computing depends on an integrated software environment that allows multidisciplinary specialists to contribute specific tools to it without having to be expert in all other fields.
Future Biomedical Software
The future of biomedical computing depends on an integrated software environment that ideally combines software from multiple sources into a computational workbench, and that allows multidisciplinary specialists to contribute specific tools to the workbench without having to be expert in all other fields. Creating a dramatically better computational workbench requires five major advances in software engineering:
- Allowing biomedical software tools to seamlessly interoperate with one another;
- Uniting state-of-the-art tools created by different biomedical researchers to perform state-of-the-art computational experiments;
- Making tools accessible to other researchers through Web-based and/or grid-based mechanisms;
- Making tools more powerful through parallel and distributed implementations and through performance improvements; and
- Making tools easy to use, accurate, and reliable through sophisticated user-interface development and robust software engineering.
Leveraging the lessons we’ve learned creating the SCIRun, BioPSE, and Uintah PSEs, we are now developing a new component-software architecture to create a biomedical software environment that addresses the features required to make advanced PSEs an everyday tool for researchers and clinicians.
Figures
Figure 1. SCIRun/BioPSE modules combined for EEG modeling, simulation, and visualization.
Figure 2. Visualization of results of an EEG simulation localizing a neural source.
Figure 3. User interfaces compared: (a) BioPSE dataflow interface for a bioelectric field application; (b) BioFEM custom interface. Though the BioFEM application is functionality equivalent to the dataflow version for BioPSE, the BioFEM version provides an easier-to-use custom interface.
Figure. Side view of cortical imaging and dipole source localization. Electric scalp potential recordings (color-coded on the disks on the scalp surface) are used to recover the potential distribution on the cortical surface, as well as the equivalent dipole current sources (shown as arrows embedded in the cortex). Potentials are color-coded: red corresponds to positive values; blue to negative values; and green to values near zero. Image generated with the SCIRun/BioPSE software system provided by the Scientific Computing and Imaging Institute.
Figure. Physical model of simulated coral produced using a 3D printing technique (selective laser sintering). Thousands of independent virtual polyps grew this structure themselves in a simulated reef environment over 24 hours on a 16-processor Linux cluster. Simulations: Roeland M.H. Merks, Alfons G. Hoekstra, Jaap A. Kaandorp, and Peter M.A. Sloot, Computational Science, University of Amsterdam, The Netherlands.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment