INDUSTRY

By Steve Fisher, Editor in Chief -- The University of Alabama at Birmingham’s Department of Biomedical Engineering recently announced that it is using a Dell PowerEdge server cluster to improve the understanding and treatment of cardiac arrhythmias, a condition that causes approximately 400,000 deaths annually in North America. Dr. Andrew Pollard, Associate Professor of UAB’s Biomedical Engineering Department spoke with Supercomputing Online about the university’s use of cluster computing. SCO: Please tell us about UAB's Cardiac Rhythm Management Lab (CRML). POLLARD: CRML is a research center with 5 Cardiology faculty and 8 Biomedical Engineering faculty that was established in 1994 at UAB. The Director is Professor Raymond E. Ideker. The Assistant Director is Professor William M. Smith. The laboratory includes a wide range of resources for the study of the electrical activity in heart tissue, i.e. cardiac electrophysiology. These resources include: (a) a set of electrical mapping systems capable of archiving electrograms on 528 channels at 2000 samples/s acquisition rates for 2 hour periods; (b) a set of optical mapping systems in which imaging techniques are used to archive fluorescence signals representing cellular activity from hearts and tissue preparations; (c) facilities for recordings from individual cardiac cells; and (d) computational facilities for modeling the heart's electrical activity and for the signal analyses to interpret data from experiments. SCO: Please provide a technical break-down of the Dell cluster the lab will be using. POLLARD: We set this up as a standard Beowulf-type cluster. It contains: -4 PowerEdge 300SC servers with dual P3/800 CPUs, 512MB RAM that formed the original machines. One of these four machines contains two network interfaces. This machine communicates with the outside world on one interface and the rest of the cluster via Blind IP on the other interface. -12 PowerEdge 1400SC servers with P3/1.3GHZ CPUs, 1GB RAM were purchased earlier this year to fill out the cluster with 16 machines and 32 CPUs. -a Dell 24-port managed switch and a set of KVM switches and SmartUPS boxes -Every one of the machines runs RedHat 7.1. SCO: Please tell us specifically how you are, and will be using the cluster. What goals do you hope do achieve via its use? POLLARD: For a number of years, we have developed codes to simulate the electrical activity in different types of heart tissue. These codes work by solving a set of equations that are intended to represent the current that flows: (a) through the ion-sensitive channels in individual heart cell membranes; (b) between individual cells as they are arranged within tissue preparations through structures called gap junctions; and (c) around the cells themselves, which is important to represent the interaction between an electrical stimulus and the tissue. Changes to the cellular ionic currents and to the tissue architecture that accompany a number of disease states contribute to the initiation and maintenance of abnormal tissue excitation, which is a component of lethal cardiac arrhythmias. As a practical note, the great thing about such a reasonably priced computational resource is that it can be used for a wide range of studies. For simulations in prototype modes that contain relatively few cells, it is possible to launch 32 separate versions of the same code using different parameters. Although this is not a highly advertised type of parallelism, it sure is an important practical solution to the time required for completing a given study. At the other extreme, we integrate Parallel Virtual Machine (PVM) library calls into parts of the code to use the cluster as a single machine. Because the main computational requirements for these simulations involves local calculations on subgrids, the code parallelizes well. In between these extremes, we can build 4-CPU or 8-CPU virtual machines to achieve some parallelism while running multiple simulations. The bottom line here is that the low cost means that sharing the resource is not much of an issue. Because the codes compile under Linux and are parallelized with open source tools, our maintenance costs are effectively non-existent. Instead of paying licensing fees for a UNIX-type operating system on a large server-class machine, we can replace 8-16 CPUs every year as a part of the maintenance plan. SCO: Why did UAB select Dell over other vendors? POLLARD: We selected Dell because we had a good experience with the first 4 servers in the cluster and the pricing for the last 12 servers was reasonable. Our goal was to stay near $1,000 per CPU, and we were able to do that with both purchases. SCO: Please tell us a bit about the NIH grant that allowed UAB to acquire the Dell cluster, thereby quadrupling its computing power. POLLARD: We recently received a Program Project Grant from the National Institutes of Health to study Mechanisms and Therapy of Ischemic Cardiac Sudden Death. Dr. Ideker is the Principal Investigator, with CRML faculty leading different projects within the larger grant. Myocardial ischemia is a condition in which there is a loss of blood supply to the heart. As part of this project, we have designed simulations that incorporate specific ionic changes that occur during ischemia, and have been able to study how arrhythmias are initiated under these conditions. We have also used simulations to understand how arrhythmias are maintained in tissue with normal characteristics, with the expectation that the cluster will allow us to complete parallelized simulations that incorporate the ionic changes we associate with ischemia. Finally, simulations of this type have been used to understand how defibrillation strength electrical shocks act to terminate arrhythmias. We plan to study this problem in the setting of ischemia using the cluster. SCO: Is there anything else you'd like the readers to know about? POLLARD: I hope that my enthusiasm for this approach comes through in my comments. We have a limited number of people doing dedicated computational work and what looks like an attractive horizon with spare cycles. This approach is one that provides us with a great deal of independence in terms of the hardware, the software and perhaps most significantly, the system maintenance. We are by no means experts in parallel computing, yet the PVM libraries are sufficiently mature that message passing can be used within our codes with minimal tuning because the CPUs are well matched. Similarly, there are tools for much of the system administration so we can be independent in that part as well. I had read a number of Beowulf how-to documents over the years, and the support within that community for someone getting started with this type of approach is very, very good.