CIBC:Collab:McVeigh

From NCRR Biomedical Software Development, Engineering, and Dissemination Wiki

Contents 1 Project Description 2 Project Status 3 Project Progress/Development 4 Software development 5 Technical Requirements for PSE 5.1 Program Infrastructure 5.2 Algorithms 5.3 Data Representation 5.4 User Interface

Project Description

The overall goal of Dr. McVeigh's research is to develop a computational model to predict the susceptibility to fatal ventricular arrhythmia. Dr. McVeigh and his colleagues have developed methods to measure electrical, mechanical, and geometrical properties of normal and abnormal myocardial tissue with unprecedented resolution in the working heart, both in patient and experimental studies. Dr. McVeigh's group is studying the interplay between these properties and their relative roles in generating the substrate for ventricular arrhythmia. Their ultimate goal is to understand the propensity for the onset of fatal ventricular arrhythmia and to predict which patients are at high risk for sudden death.

The first scientific aim of this research is to test the hypothesis that regions of abnormal geometry and mechanics in heartsfollowing myocardial infarction (MI) contribute to reentry circuits of ventricular tachycardia (VT). Dr. McVeigh and his group will examine electromechanical maps from canine hearts during normal HIS-Purkinje conduction to study the association between electrophysiological parameters and the magnitude and timing of myocardial strains with particular attention to the MI border zone. Subsequently, they will induce reentry VT by programmed stimulation with up to three extra stimuli and acquire electromechanical data during the resulting arrhythmias. By registering the electrical, geometrical, and mechanical data, they will be able to dissect the contributions of the geometry and mechanics to propensity for ventricular arrhythmia. Dr. McVeigh's group anticipates that the reentry circuit will appear in the peri-infarct zone (both the infarct border zone and within the infarct), where they expect the heterogeneity of the conduction properties to be greatest. They will also use diffusion weighted MRI and diffusion tensor imaging to determine the predominant fiber directions in the infarct and noninfarct regions, then to determine the fiber stress and strain. This information will allow them to evaluate whether transmural heterogeneity of fiber stress and strain in the peri-infarct zone may generate foci for stretch-activated ventricular ectopy to initiate VT. Thus they can test the hypothesis that regions of abnormal geometry and mechanics contribute to reentry circuits of ventricular arrhythmia.

The second scientific aim is to develop a computational model to predict the propensity to ventricular arrhythmia in post-MI subjects. Out of the electrical, geometrical and mechanical data acquired in the first aim, members of Dr. McVeigh's group will identify specific parameters that could contribute to post-MI VT. Potential geometrical parameters include the infarct size, location, distribution, and the thickness of surviving epicardial rim. Candidates for mechanical parameters include the magnitude of abnormal stretch and the size, location, and distribution of the region of abnormal stretch. Based on these parameters, they will develop a bidomain computational model that will predict electrical behaviors and the susceptibility to post-MI VT from geometrical and mechanical data.

Project Status

Exploring what components are needed for this project.

Project Progress/Development

Working on registration of various MRI images both CINE and Anatomical aimed at building a full heart model with a torso surrounding it. While in DC I helped Bruce to construct a torso mesh that surrounds the auckland heart, we prototyped a few meshing algorithms in Matlab and worked on registration techniques to align a predefined model of the heart to the correct position in the heart.

--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

• 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.

• 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.

• 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.

• Implementation of more matrix solvers: We currently use BiCGstab in the simulation tools. (One could think of Algebraic MultiGrid as well)

• Implementation of PETSc/MPI matrix solvers to solve large matrix problem efficiently with preconditioners in parallel. (SCIRun has only ported the single processor versions.)

• Implementation of matrix solvers that solve multiple right handsides at the same time.

• Segmentation algorithms: flood fill, watershed, etc....

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 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 use of degenerate hexahedral meshes

• Support for time dependent 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 time-dependent geometries

• Support for Dicom format of data, support of reading location of MRI scan to combine multiple scans into one image (orientation data is stored in these objects)

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.
  • Multimodel visualization of scalar, vector, and tensor quantitites
  • Visualization on time-dependent geometries

• 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.