CIBC:Documentation:SCIRun:UserGuide:Concepts
Contents
Traditional Problem Solving Methods
Traditional methods for solving bioelectric field problems use multiple, non-integrated computer programs. For example, using a computer simulation to examine the effect of electrode patch placement on transcardiac current density in the design of a cardiac implant-able defibrillator[1] requires geometric modeling, numerical simulation, and scientific visualization tools to complete the task. The user might need one program to define the thoracic surfaces from medical images and another to create a discrete mesh of the volume contained within the surfaces[2]. An application such as Matlab computes a finite element simulation of the electric current distribution from the defibrillation electrodes through the thoracic volume[3]. Another approach is to write a Fortran program using a public domain numerical library such as LAPACK . Viewing output requires a scientific visualization package (such as those described in[4]). Between each of these steps, it is necessary to save the output of one program in a format that the next in the sequence can read. This process usually necessitates separate file format conversion utilities. To find the optimal location, shape, and size parameters for the defibrillating electrode, the user has to go back to the geometric modeling package, change the necessary parameters, manually re-run all subsequent steps to see how the new electrode configuration affects the current density distribution, then manually iterate. The manual intervention required to drive this process is tedious and time consuming.
More efficient is a scenario in which the user can define an appropriate set of parameters for a given simulation, then set up a sequence of runs to examine each of them and save the results for subsequent examinations. The complete execution of the sequence might require hours or even days, but the user is free during that time to perform other tasks. This process is similar to the ``what if analysis modern spreadsheet programs offer for far simpler problems.
In the example of the defibrillation simulation, the user can select various locations and orientations for the defibrillation electrodes, choose values for other parameters of the simulation (e.g., the number of nodes in the finite element model, the boundary conditions, the error tolerance for convergence, and the evaluation criteria), and leave the simulations to run as long as necessary. Viewing the results can be as simple as watching the animation produced by the simulation, or scanning other defibrillation quality indices such as maximum and minimum current density magnitude or current density histograms from the heart. This automated execution process, whereby the user selects all parameters in advance and does not control the intra- or inter-package execution, is called batch processing. A benefit of batch processing is that it allows the user to utilize computational resources without intervention. However, most scientific computer software requires some user intervention in order to produce meaningful results . This constraint makes it difficult or impossible to run multiple computational jobs automatically, leaving the user with the task of manually initiating and controlling each step of the process.
Integrated Problem Solving and Computational Steering
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 and its Packages
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 the above figure). 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.
SCIRun Modules, Networks, and Sub-Networks
The functional unit of a data-flow environment is the module . The figure below contains a generic SCIRun module, with a User Interface (UI) button for graphically accessing the module's user interface, and input and output ports for receiving and sending data, respectively. On the right is a simple example of a data-flow network. Data passes through the output port of the top module, through the data pipe, and into the input port of the bottom module. The User Interface enables the selection of a desired isochrone surface.
Modules may contain other elements, but all have at least one input or one output port. Most modules have input and output ports connected to other modules. Data readers are modules with only an output port. Their ``input is read from a file. The Viewer module provides input ports only; scene data arrives on its input ports and a screen visualization is its ``output.
A subnet is a collection of modules that behave as one. Sub-Networks can be created, edited, and saved just like networks. Sub-Networks can be reused in other networks, including other sub-networks. Sub-networks simplify the construction of complex networks. SCIRun ships with a set of subnets. See Creating a Sub-Network for details.
It is important to understand the concepts of modules, connections, networks and data-flow. See Working With Networks for more information on modules, subnets, ports, connections, and networks.
SCIRun's Use of Third Party Software
Overview
SCIRun works with software from third party sources in several ways. The use of third party software is largely invisible to the user of SCIRun or BioPSE.
For example, SCIRun's user interface is written in Tcl language using the Tk library. In general, SCIRun modules use Tcl for their user interface elements and C++ for their computations. However, a module may also interact with code written in other languages such as FORTRAN or Matlab.
One goal of the BioPSE project is to provide support for such external code, including FORTRAN, C, Matlab, and IDL.
Matlab Interface
The Matlab interface package allows SCIRun to execute Matlab scripts and to read and write Matlab matrix data files.
A sockets interface allows SCIRun to exchange a matlab script and matrix data with a Matlab process. Matlab executes the script with input data from SCIRun and returns matrix data to SCIRun.
The Matlab process can run on the same computer as does SCIRun or it can run on a separate computer, helping to distribute the load and resolving potential licensing conflicts with Matlab.
Via the Matlab package, SCIRun can read Matlab matrix files, converting them to a SCIRun matrix type or a NRRD type.
Insight Toolkit
SCIRun provides modules for solving problems in a wide range of areas such as performance analysis, geometric modeling, numerical analysis, and scientific visualization. SCIRun, however, lacks image processing tools. This deficiency is most prominent in the area of medical imaging.
The Insight Toolkit (ITK) is open source software that complements SCIRun by providing image-processing capabilities, ranging from fundamental algorithms to advanced segmentation and registration tools. The Insight Toolkit provides these capabilities as filters. SCI has developed a method of encapsulating ITK filters in SCIRun modules.
If ITK is present (and SCIRun is appropriately configured) SCIRun will build a default set of ITK filter-based modules.
PETSc
The Portable, Extensible, Toolkit for Scientific Computation (PETSc) is a library of data structures and functions for the parallel solution of partial differential equations.
When PETSc is installed, and SCIRun is configured to use it, SCIRun's SolveMatrix module enables the use of PETSc solvers.
Installation of PETSc is optional. SolveMatrix provides built-in solvers if PETSc is not installed.
Genesis (via SQL)
GENESIS (short for GEneral NEural SImulation System) is a general purpose simulation platform that was developed to support the simulation of neural systems ranging from complex models of single neurons, to simulations of large networks made up of more abstract neuronal components. GENESIS has provided the basis for laboratory courses in neural simulation at Caltech and the Marine Biological Laboratory in Woods Hole, MA, and many other institutions.
SCI has made it possible to use the output of a GENESIS simulation as the input for a visualization, or a subsequent simulation within BioPSE. The mechanism for this bridge is a database accessible via SQL queries. SCI created code for GENESIS that writes the output of the simulation into the database, then the corresponding functions for SCIRun read this information from the same database. Contact Chris Butson butson@sci.utah.edu for details about the implementation of the GENESIS module.
Extensibility
SCIRun can be extended by creating new packages, modules, and subnets. Modules can be coded from scratch, or with the assistance of the SCIRun's Module Maker component.
SCI encourages users to contribute modules to the BioPSE web site CIBC web site where they will be reviewed, and useful modules will be included in subsequent releases of SCIRun.
To leverage investment in legacy code, future releases of SCIRun will include additional tools for wrapping existing code within SCIRun modules.
Power Apps
SCI is developing problem specific applications called Power Apps. Power Apps use SCIRun's data flow engine for computation and application specific data flow networks for problem solving. However, Power Apps hide the complexity of the data flow environment behind a simplified application specific graphical user interface.
The following Power Apps are available:
An application for computing and visualizing diffusion tensor data. See the BioTensor tutorial for more information.
A finite element simulation application. It is used, for example, to compute electric and potential fields from a discretized volume conductor and a current source.
An application for exploring 3D volume data. See the BioImage tutorial for more information.
Commands BioTensor, BioFem and BioImage invoke these applications. If SCIRun is installed from source code, commands BioTensor, BioFem and BioImage are located in SCIRun's build directory (alongside the scirun command). If SCIRun is installed from RPMs these commands are located in /usr/local/SCIRun/bin.
SCIRun Objects
Overview
SCIRun's Field, Mesh, Matrix, and ColorMap objects are used frequently in networks. These objects are described in the following sections.
Field
A SCIRun Field consists of a geometric Mesh and a set of data values. Data values can be located at the nodes, edges, faces, or cells of a mesh. A Field can consist of a Mesh component only (no associated data).
Field Data
The following C++/SCI data types can be associated with a Field:
* double, float * int, short, unsigned, unsigned short * char, unsigned char * 2nd order Tensor * Vector of doubles
C++ data types are double, float, int, short, unsigned, unsigned short, char, and unsigned char. SCIRun data types are Tensor and Vector.
Meshes
SCIRun meshes are classified as unstructured, structured, or regular. A mesh consists of nodes and implicit or explicit node connectivity information.
Node locations and connectivities for unstructured meshes are specified explicitly. The unstructured mesh types are: PointCloudMesh, CurveMesh, TriSurfMesh, QuadSurfMesh, TetVolMesh, and HexVolMesh.
Node locations are specified explicitly, and connectivities are known implicitly for structured meshes. The structured meshes are StructCurveMesh, StructQuadSurfMesh, and StructHexVolMesh.
Node locations and connectivities are known implicitly for regular meshes. The regular mesh types are ScanlineMesh, ImageMesh, LatVolMesh.
A regular mesh is more constrained than structured and unstructured meshes. Likewise, a structured mesh is more constrained that a unstructured mesh. A more constrained mesh can be trivially converted to a less constrained mesh by explicitly enumerating implicit properties. For instance, a LatVol mesh is converted to a StructHexVol by enumerating a LatVol mesh's node coordinates (connectivities are still implied). Also, a LatVol mesh is converted to a HexVol mesh by enumerating a LatVol's node locations and connectivities. Module ToStructured performs this type of conversion.
It is not meaningful to convert a less constrained mesh to a more constrained mesh. It is possible, however, to sample an unstructured field at regular intervals to create a regular field. For example, a HexVolField is interpolated onto a LatVol mesh using modules SampleLattice and DirectInterpolate.
Bioelectric Field Quantities and Units
The quantities of interest in bioelectric field problems are conductivity, potentials, electric field, dipole source, current density, and current source density. These quantities and their associated units are listed in the table below.
| Quantity | Unit |
| Conductivity | amps/volts/meter (siemens/meter) |
| Potential | volts |
| Electric Field | volts/meter |
| Dipole Source | amps/meter |
| Current Density | amps/meter^2 |
| Current Source Density | amps/meter^3 |
SCIRun doesn't keep track of unit scale factors (e.g. centi-, milli-, etc). SCIRun assumes a dipole source is in units of amps/meter, conductivities are in siemens/meter, model geometry is in meters; results are therefore in units of volts. If this isn't true (e.g. you know that the model is in mm), then you have to carry those scale factors through your computation (e.g. know that the results you get out are in kv).
The rule of thumb is that if we increase the conductivity, then we decrease the potentials by that same scale factor. Conversely, if we increase the dipole source moment, then we increase the potentials by that same scale factor. i.e. V = I/sigma. Similarly, if we hold everything else constant, but increase the size of the domain, then we decrease the potentials by that same scale factor.
For example, the SCIRun Utah Torso model has a length scale of centimeters ( 10^-2 meters) and conductivity units of siemens/meter, so our output potentials are in hectovolts ( 10^2 volts).
