From bnews@cns.caltech.edu Tue Nov 10 12:05:50 1992 Date: Tue, 10 Nov 92 12:05:49 PST From: bnews@cns.caltech.edu (Babel News Account) Subject: Traub Channels >From sampat@cvax.ipfw.indiana.edu I am a student at Purdue University at Fort Wayne and am doing research for Dr. Samir Sayegh in Neural Networks. I am using Genesis to simulate a hippocampal neuron. To do this, I am expanding some of the Squid files; i.e., I am trying to encode the Calcium and the Calcium-dependent-Potassium channels (along with the Calcium concentration) in a similar manner as you have implemented the Sodium and Potassium channels. My research partner has used equations and numbers from the book: Neuronal Networks of the Hippocampus by Roger Traub. Accordingly, we had to change some other numbers due to differences in units. Our ultimate goal is to show bursting activity in the neuron. Unfortunately, we are not getting this effect completely! We feel that we are misunderstanding some of the message passing code in genesis, or something along those lines. Could you send us some details on the steps that we might need to take in order to carry out our implementation. We could send you some of the files in Squid that we have modified if this helps you to understand our problem/implementaion more clearly. Thank you very much! Pulin Sampat and Sattar Jaboori Department of Physics Purdue University at Fort Wayne, Indiana e-mail: sampat@ipfw.indiana.edu or jaboori@ipfw.indiana.edu =============================================================== >From Dave Beeman GENESIS Users Group You asked for some information to help you implement Traub's bursting pyramidal cell model. A tutorial based on this model can be found in the babel directory "newsims/traub91". Some notes on the implementation of the Calcium dependent channels are in the directory "tutorials/tabchan_tut". Dave Beeman GENESIS Users Group =============================================================== rom bnews@cns.caltech.edu Tue Nov 10 12:43:06 1992 Date: Tue, 10 Nov 92 12:43:04 PST From: bnews@cns.caltech.edu (Babel News Account) Subject: Xodus and concurency From: charles@anatomy.ucl.ac.uk (Charles King) Hi, I'm currently doing a PhD under John O'Keefe and Michael Recce at University College London, part of which involves simulating the CA1 area of the hippocampus. I've been spending the past month working with calcium-dependant conductances, variably-patterned input streams, and the effects of external neuro-modulators, such as acetylcholine and I've got a few questions to ask: 1) How easy would it be to modify Xodus to interface with other graphics products? We have a tool here called Dev Guide which allows interactive creation of forms and then produces a C source implementation into which you can slip your application code. Basically what I want to know is whether modifying Xodus is going to be relatively easy. =============================================================== Upinder Bhalla responds: Hi, I would advise against messing with Xodus at this stage. Its interaction with Genesis is not very clean and involves all sorts of convolutions. If you are really keen you might try modifying an existing widget, but anything beyond that would probably be a traumatic experience. It is possible to compile your own functions in with Genesis. So a possible ugly hack would be to do a completely stand-alone widget - nothing to do with Xodus - and figure out how to make it interact with the simulation. You might even consider doing this from the UNIX shell, which can be called from the Genesis script language. We plan to release a much more self-contained and easily modifiable Xodus in a few months, but that will probably be too late for you. >From the sounds of it you have the original Genesis release. Some of the widgets have been improved since then, and may do what you need. Certainly a lot of the functionality you are interested in (Ca dependencies etc) is currently implemented. Dave Beeman who handles BABEL, even has a hippocampal pyramidal cell model using Traub's '91 parameters. You might want to look into these. ------------------------------------------------------------------- Dave Beeman continues: Upi Bhalla answered some of your questions about XODUS. Here is another suggestion. The easiest way to interface XODUS to external programs is to communicate via file I/O. The xfileview widget will read and display data files which can be written by other programs. Likewise, the disk_out asc_file objects can be used to output data to other programs. Once you have access to BABEL, you can find information on these in the following places: babel/newdocs/disk_out.doc babel/newsims/kendemo genesis/Doc/disk_out.doc genesis/Doc/disk_in.doc genesis/Doc/asc_file.doc ================================================================= and a second question: 2) We are using a Sparc Server which has two processors running in parallel. I often run simulations late at night and over the weekend as they eat CPU cycles. It's become rather frustrating. Would it be possible to adapt Genesis to run concurrently? Jim Bower writes: With respect to concurrency, version 1.5 of GENESIS currently in testing at Caltech, will be concurrent, running on parallel machines as well as on networked workstations. This version will be available generally soon. We will also start sometime after the first of the year to provide GENESIS users access to the Intel Touchstone Delta here to run large scale parameter searches. ------------------------------- From bnews@cns.caltech.edu Tue Nov 10 12:54:26 1992 Date: Tue, 10 Nov 92 12:54:25 PST From: bnews@cns.caltech.edu (Babel News Account) Subject: more optics ideas Further response to David M. Senseman regarding optical simulations in GENESI from Dave Beeman: You asked if createmap, gen_3d_msg, and volume_connect would be suitable for your application. These are fairly general and should do the job. However, if you run into a situation where these don't provide all the flexibility that you need, don't forget that they can be replaced by a "for loop" in a GENESIS script. This will be slower during the setup of your simulation, but will not effect the speed at which it runs. Creating/copying elements and setting up messages explicitly in a loop has the advantage of being less error-prone, as you don't have to rely upon your understanding of the synatax of functions such as createmap.