Have you considered using something like boinc (http://boinc.berkeley.edu/) to harvest unused cycles from thousands of end user pc's? If you can make substantial gains in computation by tying together a few labs, I'd imagine that you could dramatically increase what you're capable of by harnessing a couple of orders of magnitude more cycles...
D. On 12/20/05, Eugen Leitl <[EMAIL PROTECTED]> wrote: > ----- Forwarded message from Barry Wark <[EMAIL PROTECTED]> ----- > > From: Barry Wark <[EMAIL PROTECTED]> > Date: Mon, 19 Dec 2005 16:20:54 -0800 > To: xgrid users <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Cc: Adrienne Fairhall <[EMAIL PROTECTED]> > Subject: Use of Xgrid in neural computation research > > At the request of Richard Crandall, here is a summary of some of the > work I have been doing in the computational neuroscience lab of > Adrienne Fairhall at the University of Washington. I hope to give you > a brief taste of what we're doing in the lab and then to explain how > many of the computational problems we face are easily amenable to > massively parallel architectures such as Xgrid and how parallelizing > computations allows researchers in the group to spend less time > writing code. > > Of course, we would be happy to answer questions or offer suggestions > if anyone is considering similar work. > > First, a bit of background. The goal of the Fairhall Lab is to > understand the computation performed by individual neurons and neural > circuits. For our purposes, "computation" is a functional description > of the neuron's mapping from stimuli to spike times: because mammalian > action potentials are stereotyped, the time of individual action > potentials is the only information transmitted to down-stream neurons. > As Hodgkin and Huxley first showed in 1952, the computation performed > by a single neuron at relatively short time scales can be described as > a system of nonlinear differential equations. These equations describe > the kinetics of ionic currents across the neuron's membrane, which are > both caused by the stimulus and are responsible for the generation and > propagation of an action potential response. The parameters of these > equations can be determined by experiment. Unfortunately, the > equations describing even simple neurons are not analytically solvable > and the form of the equations describing ionic current kinetics don't > provide direct insight into the 'computation' performed by the > neuron?is a neuron containing a particular set of ion channels an > integrator, a differentiator, a high-pass filter, etc.? So, how can we > map dynamical system descriptions to functional descriptions? This > question is a current focus of the lab and we take two approaches to > answering it: developing techniques to accurately define a functional > description of a neuron from experimental data and developing > analytical techniques to relate the dynamical system description to > the functional description and vice versa. > > As you might begin to guess from my description, many of the questions > we're addressing involve analyzing many thousands or millions of > neural responses in stimulus-response pairs, either to identify the > features of the stimulus that trigger an action-potential response or > to simulate the dynamical system with particular parameters and input. > Because we can identify the history dependence of a given neuron from > experimental data (or analytically from neuron models), we can divide > these analyses into independent stimulus-response units, suitable for > distribution across a parallel architecture. > > Because numerical research of this kind is often exploratory, coding > all of our analyses in efficient languages such as C or C++, for > example, often amounts to an unacceptable overhead. It is difficult to > use such code from an interactive prompt and incremental changes in UI > or algorithms require substantial coding effort, unless great care is > taken from the outset in code design. Most of the researchers in the > lab have no computer science background, so ease of development and > interaction with analysis code is a priority for us. Therefore, > interactive languages such as Matlab or Python are the preferred > language/environment for implementing analysis algorithms. The down > side to these languages, of course, is that they are much less > efficient than compiled languages, even though they use standard > numerical libraries for computations (e.g. Numerical python). > > Xgrid has provided a very welcome addition to our toolkit because it > allows us to mitigate the loss in computational efficiency of rapid > development languages. Instead of spending time re-coding analysis > routines in C/C++, researchers in our lab can now "simply" distribute > their analysis across our Xgrid (remember that our analyses are often > of many independent events). > > Briefly, our Xgrid is a 'desktop recovery'-type cluster. We do not > have the resources to install or maintain a dedicated cluster (yet), > but we can recover the un-used cycles from the many workstations in > our lab. Currently we have a heterogeneous grid of 10 processors (G4 > and G5) in 6 agents, totaling approx. 22 GHz. With only one job > running on the cluster, my analysis runs approximately 600% faster > than on a single 2.5GHz G5, a gain of about 68% of the added > processing power. Several projects have become feasible because > analysis time has been reduced from weeks to days. > > Now, here's the really subversive part of this technology that's > gotten us particularly excited: we offer other computational biology > labs access to the cluster in exchange for adding their workstations > to the grid. Without adding ownership cost (all of the work stations > were already in use by researchers), we provide significant > computational power to a growing number of researchers. Because each > group (at least so far) uses less computation time than they add to > the grid in spare cycles, everyone wins big. > > It seems that this type of application might become a very valuable > niche for Xgrid. Many computational biology groups in our department > do not have the resources or sufficiently urgent needs to justify a > dedicated computational cluster including acquisition and maintenance > costs. Nonetheless, many of these labs are finding that as the > complexity of their analyses increases, they wish they had more > computational power at their disposal. In addition, they want to > maintain the flexible, exploratory nature of their work. Xgrid > technology allows us to address both of these needs: as the grid grows > researchers have increasing computational power at their fingertips, > with no additional overhead, and they can continue to use interactive, > interpreted languages for coding their analysis without waiting too > long for results. > > If you've made it this far, thanks for reading. Please direct any > questions/comments/rants my way :) > > Barry > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Scitech mailing list ([EMAIL PROTECTED]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/scitech/eugen%40leitl.org > > This email sent to [EMAIL PROTECTED] > > ----- End forwarded message ----- > -- > Eugen* Leitl <a href="http://leitl.org";>leitl</a> http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > > ------- > To unsubscribe, change your address, or temporarily deactivate your > subscription, > please go to http://v2.listbox.com/member/[EMAIL PROTECTED] > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFDp7cOdbAkQ4sp9r4RAg8EAJsGpp47WbhKpq/ZbVtEaHAmiBoLMwCgmk+z > gjB22w4hd239dV9Jwx30r2I= > =drUA > -----END PGP SIGNATURE----- > > > ------- To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/[EMAIL PROTECTED]
