CIBC:Collab:Henriquez
From NCRR Biomedical Software Development, Engineering, and Dissemination Wiki
Contents |
Project Description
This project aims at simulating the effectiveness of DNA transport into a cell by means of eletrophoresus. A key issue in gene therapy is to be able to transport DNA molecules into the cell. One way to accomplish this is by application of a strong electric field and force holes in the cell membrane. These holes form when membranes are subjected to large electric field. As the electric field strength is not homogeneous in tissue, the first step of the project aims at computing the electric field in a tissue. Moreover as holes form in the membrane the electric field changes and hence this is a dynamic simulation.
Project Status
Exploring what components are needed for this project.
Project Progress/Development
The first milestone in this project will to be able to simulate the strength of the electrical field in tissue. This part of the project will coincide with the other project currently going on in collaboration with Craig Henriquez. In the latter project we are developing a model at tissue level for studying propagation in various types of cardiac tissue. Hence the current effort is at building tissue models and software for doing this.
What has been done:
(1) Adapted and rewrote the CardioWave software from Duke to be able to simulate tissue at a cellular level, modified the way volumes and areas are accounted for, adapted the matrix solving process, added a whole new layer in the software to do these calculations in parallel on a cluster.
(2) Tested the CardioWave software on the NCRR cluster. CardioWave runs here, but runs far less efficient then on the SGI machines. There is a big performance gap until we go to the real big models. Currently a simple simulation of about 20 cells takes about 16 hours on 10 processors on Muse.
(3) Created software to generate FEM models based on tissue structure. CardioWave needs a lot different model components and these are currently generated by the software.
(4) Tested the software for simple cell models and simulated a series of ischemia cases, which surprisingly showed that a lot of the conduction slowing observed in ischemia can be attributed to tissue structure changes, which goes against current theory. (writing a paper about it now)
--Jeroen
Software development
Technical Requirements for PSE
Program Infrastructure
- Resource (Memory/CPU) management
- Working interactively with large datasets requires that data can be stored in memory and/or disk.
- Dividing algorithms into small reusable components will require a lot of memory if data is stored in memory to keep interactivity alive.
- Optimization between using a lot of memory and being fast or more memory and being slow. For example for a small data set you want to store eigenvalues of a tensor, for bigger datasets keeping intermediate results will cause a lot of swapping memory and could lead to running out of addressable memory space.
- Optimize dataflow, what is execute and in which order to minimize computation time and memory needs.
- Component model: Algorithms should be fairly general and exchangable. The data quality of input varies and the goals of the simulations vary as well: hence a component model would be required, with a user interface in which components can be interchanged/omitted/added.
- Automation: Automation should be available from the interface.
- Often reoccuring scenarios are doing parameter sweeps in different domains, trying different segmenation parameters, using different membrane parameters.
- Most software uses a simple list of parameters to guide the process. A similar concept would make it easier to interact with other software. For instance CardioWave uses a textfile with parameters, most Matlab oriented software in this project uses similar parameter lists.
- Parameters to controlling application: filenames, scalar values (vector and tensor value (e.g. conductivities)) and strings (e.g. membrane models)
- External Application Interface: A mechanism to run simulations at in a different process at a different computer.
- To setup a simulation the model should be able to be export in the fileformat of the simulator
- Simulation software often requires MPI, stability and hence should run as a separate program. Since simulations in the project take time interaction is not stricly needed.
- The mechanism supported should be reliable and should support to run a simulation without crashing (simulations can take days to complete)
- Monitoring simulations: Simulations results should be written as files in a directory (that way we keep a clear record of results). When the simulation directory is mounted SCIRun should have access to it and use it to dynamically update its display.
- Annotation: We should have the ability to gather parameters in a simple text document (or something similar) to annotate simulations. Being able to figure out what kind of parameters were used in a simulation is valuable.
- Annotation should be preferably be generated automatically or should be scriptable, this will ease the task of the scientist.
- Keeping a log of operations performed.
- Algorithmic separation:
- Store algorithms in libraries which have standard options for error reporting and informing the user (abstract methods that can be separated from actual GUI, giving feedback e.g. warnings etc to the user is important)
- When we have figured out a way of image to model that works for a lot of cases, one wants to be able to quickly rewrite the component GUI program to a full stand-alone program.
- When having a combination of mesh generation tools that work, one may consider a program that can be called under Matlab/Mathematica without GUI for certain basic tasks.
Algorithms
- Segmentation filter: A simple filter that requires that segmented areas are fully linked volumes (islands need to be removed) and one volume should remain.
- Segmentation algorithms: flood fill, watershed, etc....
- Interpolation algorithms:
- Based on a segementation/selection mask and a trustworthyness index one often wants to interpolate over bad data. E.g. I have a segmentation of anatomy of the heart and diffusion tensor which are not to be trusted next to a pool of blood, an air/tissue interface etc, then one wants to interpolate the data based on the reliable data.
- Laplacian interpolation (Are there better algorithms for doing interpolation of diffusion tensors?)
- Surface Extraction Algorithms: A common notion is to go from a pixel segmented image to a triangulated surface. One requirement would be able to control the density of the grid of the surface, as one often wants a grid less dense then the pixelated surface. And one wants a smoother outer surface.
- Meshing Algorithms: After having created a surface mesh one wants to fill the spaces with tetrahedra. Methods like advancing fronts are probably best for bioelectric problems, where a precise representation of the surface is not necessary. It would be nice to have our own algorithms or an open source development. This is currently a big gap in the pipeline. It would be great to have basic algorithms within SCIRun and bridges to other software packages for more advanced need.
- Surface smoothing algorithms: It would be great if we could smooth extracted surfaces before use in the models.
- Mesh separation code: For the membrane modeling, a mesh needs to be decoupled into discrete domains. This requires adding nodes and building internal interfaces in the mesh, which represent the membrane barriers. The idea is to have a segmented image in intra and extracellular space. When the segmentation is different an interface needs to be created.
- Surface extraction methods: based on a segmented image one wants the surface that surrounds region 1, or that is in between region 1 and 2, etc.
- Book keeping algorithms when merging geometries: Bidomain regions of a model require regular spacing, whereas other regions require only smooth transititions between element size. Hence geometries are constructed seperately and need to be merged, keeping track of which node is which node is essential.
- Extracting node numbers in mesh. Often node numbers are needed to indicate where a model stimulated, where a reference electrode is located etc.
- Bandwidth reduction/bookkeeping algorithms: To optimize the matrix computation for MPI, a smaller bandwidth often means less communication. Algorithms to explore: CutHill-McKee, sorting by node location etc. When rearranging nodes, indices and other entities need to be remapped to new node numbers as well.
- Bounding curve selection tools: Based on a segmented image, one wants to extract a curve surrounding the segmented area to use in the meshing procedure
- Algorithm for creating a triangular mesh out of a series of segmented curves
- Resampling algorithms: e.g. if one has a curve one wants to fit a spline and resample the surface. If we have a similar algorithm for a surface that would be great.
- FE stiffness matrix generation code. Similar algorithms as in the current BioPSE package.
- Mesh Templates/Mesh warping
- Taking simple geometric objects and warp them into a more complicated shape to for instance define a ischemic region.
- Mapping mathematical functions on a mesh: Often data from images is not enough to build a model and one needs to define a geometrical function on top of the mesh for a certain parameter.
- Distance maps: Often parameters are defined depending on the distance to the edge of the object or depending on the distance to a certain point.
- One can think of M-cells/ Epicardial cells etc, they can be defined is being a certain distance from a certain boundary.
- Algorithms to calculate effective area/volume on a node to node basis of the amount of volume in unstructured mesh that can be assigned to that node.
Data Representation
- Import/Export of "simple" data formats: text files (for example matrices in rows and columns), data blocks of a certain data type with a small header file preferably in ascii (like nrrd). Usage of the current SCIRun native file formats requires linking against a lot of C++ classes and SCIRun infrastructure, which is an obstacle in linking against other programs.
- Import/Export of parts of datasets (Simulation data can run in Gbytes of data and storing all in memory becomes problematic)
- Support for multiple data entities attached to one mesh
- Currently SCIRun allows only one type of data on a mesh, hence a lot of duplication of pipelines mark the current networks. Models seldom have one entity attached to a mesh often one needs to think of conductivity tensors, membrane types, tissue types (segmentation), etc.
- Unstructured meshes: Hexhedral/Tetrahedral/Quadrilateral/Triangular elements: Full support for both hexahedral and tetrahedral elements ranging from segmentation to stiffness matrix generation.
- Structured meshes: MRI data/confocal data often is a regular multidimension matrix.
- Automation: representation of filenames, scalar/vector/tensor parameters is need for automating networks.
- Bundling projects: Models often consist of a collection of matrices, meshes, and parameters, bundling everything into one file/directory is useful as an organizational tool. Being able to systematically organize data of current and past simulations is something that makes life easier and will lead to a higher degree of automation and more productive scientists.
- Support for a dataset spread over multiple files and selecting part of the data.
- The newest version of CarioWave regenerates multiple files while the simulation is running. Examining a few files will allow the user to look at certain timespans of the data.
- Support for time depend data
- time scale can be irregular hence we need a kind of lookup system for actual time
- supporting time with in the geometrical objects
- Support for irregular spaced data
- An example of irregular spaced data is for example adaptive time refinement, each frame of data still has the same amount off data but it is spaced irregular in time with the timestep between data being irregular.
- This would require to record the spacing in every direction but would still allow for a regular matrix storage of the data.
User Interface
- Comparison mode: One of the most useful features in SCIRun/Map3d is the dual/triple display mode to compare different datasets in displays that are locked. If we keep the SCIRun platform it would be useful to extend this to BioImage/BioTensor. What one wants to do is comparisons between datasets.
- 2D/3D widgets for marking parts of a mesh:
- Marking of locations (constraint to volume or surface or unconstraint floating in 3D volume)
- labeling widgets, e.g. different colors for stimulus electrodes and reference electrodes, adding text to widgets.
- 2D Image viewer:
- Draw/compute segmentation: automated segmentation with options for user to override segmentation made
- Overlay of different segmentations/ properties computed on the mesh/
- Annotation of slice, e.g. slice number, slice size, slice normal in physical space etc.
- Synchronized displays (e.g. sync slice number or actual z postion etc.)
- 3D data viewer:
- Transparant surfaces
- The option to switch on and off surfaces/meshes (e.g. as currently in SCIRun)
- Synchronized displays (for comparison mode)
- Display of legend, model parameters used etc in figure.
- Graph viewer:
- Options to draw matlab like figures, with extensive options to set units, titles, grids, scales, etc.
- Draw time curves of data: being able to get time signals and display them in a graph
- Annotation of graph viewer: title, legend, axis names/numbers/units.
- Multiple lines in one graph with different colors
- Irregularly spaced x-axis for time data: the project probably requires adaptive time steps and thus sampling is not regular
- The interface should allow for creating images that can be used in publications: being able to choose amount of colors, write decent title headers, have possibility to select resolution, being able to added axis, adding symbols, being able to add legends.
