exp2syn without NetCon

[mattmc88]

If I put exp2delay.mod into the src/nrnoc, and compile it there by running mknrndll, exp2delay doesn't appear in the menu when I subsequently open the neuron GUI.

What am I doing wrong? Do I need to compile it in a different folder in order for it to come up, automatically?

Thanks Ted.

[mattmc88]

Okay, now I can get the demo to work! And should be able to do what I need!

However, if I place and then compile the exp2delay.mod file in the directory /src/nrnoc/ along with the other point mechanisms, and compile it, I still don't see exp2delay as a point process option.

If I change the working directory to the one with exp2delay.mod in it, I now see exp2delay in the PointProcess Manager. Does this make sense?

Is there a way to incorporate exp2delay.mod into Neuron so it doesn't have to be in the working directory? I know I'm getting greedy, here.

Truly fantastic support, Ted!

[ted]

if I place and then compile the exp2delay.mod file in the directory /src/nrnoc/ along with the other point mechanisms, and compile it

Don't do that. Don't put anything in NEURON's source code tree, or NEURON's installation tree. If you're working on a model that needs anything more than the built in mechanisms, put the mod files for the extra mechanisms into the same directory as your model's hoc and ses files, then compile them there. Please read
Suggestions for how to develop models
viewtopic.php?f=15&t=950

If I change the working directory to the one with exp2delay.mod in it, I now see exp2delay in the PointProcess Manager.

because NEURON automatically loads the nrnmech.dll file that it found there. It is best to put the mod file(s) in the same directory as your model's hoc file, and use mknrndll to create a nrnmech.dll there so it will be automatically loaded whenever you double click on your model's hoc file.

Is there a way to incorporate exp2delay.mod into Neuron so it doesn't have to be in the working directory?

Yes, but it would involve recompiling NEURON, and it would have many negative consequences.
1. Collisions in name space. Each mechanism needs a unique name (SUFFIX or POINT_PROCESS class name). There are many different variations of Na, K, Ca, Cl, Ih, leak etc. currents, each of which would have to be given its own name. Even in the course of model development it is often necessary to create slight variants, and compare them against each other. Every time you tried a new variant, you would have to cook up a new name for it and recompile NEURON. Name collisions would also occur if somebody else shared code with you. Following the recommended practice means that these situations never occur. Going to make a variant of a mod file? put the original in a subdirectory in case you have to revert to it (or, better yet, use a version control system like RCS, CVS, git, mercurial etc.). Want to try somebody else's model? Unzip it into a new directory and try it there, so the mechanism names in its mod files won't conflict with any of yours. Want to use somebody else's Ih mechanism in your model? If its SUFFIX is different from the SUFFIX of the Ih that you've been using, no problem. If it is the same, then either move your old mechanism's mod file into a subdirectory before copying the new one into the directory that contains your model's source code. The only time you have to be concerned about names is if you are in a situation where two essential mod files specify the same SUFFIX (or POINT_PROCESS class name). Then you decide which one whose name you will alter.
2. Separation of custom user-written mod files from the hoc and ses files that require them makes it more difficult to practice version control and keep track of which version of which mod file goes with which version of which hoc or ses file.
3. Model archiving and sharing would be much more difficult. With all user-written source code in one directory, just zip up all the hoc, ses, and mod files in that directory, and you have everything you need. Start putting mod files in NEURON's source code tree, and you have to remember the names of which mod files went with which hoc files.

[mattmc88]

Makes sense. I'll stick to the working directory

Thanks again!

[ted]

This stuff should really be spelled out clearly in the documentation, and probably in several places. One more thing to include in the next edition of The NEURON Book . . .

[Danko Georgiev]

Hi Ted,

thanks very much for providing the code for exp2syn with delay. Indeed i also noticed that the standard AlphaSynapse has only one constant not two. And yes, I am modeling a single neuron not network, so I wanted to input the synapse and activate it at predetermined time. So as far I understand the difference is that the Exp2syn fires when the neuron in a network fires. Thus in Exp2syn there is no "onset" input. On contrast, the AlphaSynapse has this "onset" option and you can stimulate it at a predetermined time, but there is only one time constant tau.
Fortunately, searching in Google I have found this topic and your code, so I copied it into a text file with extension .mod, then placed the file into directory C:\nrn71\demo\release and compiled it with mknrndll.
Then in the Point Process Manager appeared Exp2Delay.
I wrote this message so that others trying to do the same thing to save some time.
Maybe in future Neuron release it is good idea for the AlphaSynapse to be replaced with this new Exp2Delay one. For those who want to have the original AlphaSynapse it would be no trouble to type tau1=tau2, but those who want fast rising time and slow decay could use tau1 < tau2.
Once again thanks. The code is nice one.

Code: Select all

: based on AlphaSynapse and Exp2Syn
: like AlphaSynapse, produces a single conductance change at a predetermined time
: like Exp2Syn, time course of conductance change is difference between two exponentials
: tau1 must be < tau2
: if user specifies tau1 >= tau2, initialization will force tau1 to be slightly < tau2,
: and time course will closely approximate an alpha synapse with tau = tau2
: Matt McGinley and Ted Carnevale, 7/21/2010

NEURON {
	POINT_PROCESS Exp2Delay
	RANGE onset, tau1, tau2, gmax, e, i
	NONSPECIFIC_CURRENT i
	RANGE g
}

UNITS {
	(nA) = (nanoamp)
	(mV) = (millivolt)
	(uS) = (microsiemens)
}

PARAMETER {
	onset = 0 (ms)
	tau1 = 0.1 (ms) <1e-9,1e9>
	tau2 = 1.5 (ms) <1e-9,1e9>
	gmax = 0 (uS)
	e = 0	(mV)
}

ASSIGNED { v (mV) i (nA) g (uS) factor }

INITIAL {
	LOCAL tp
	if (tau1/tau2 > .9999) {
		tau1 = .9999*tau2
	}
	tp = (tau1*tau2)/(tau2 - tau1) * log(tau2/tau1)
	factor = -exp(-tp/tau1) + exp(-tp/tau2)
	factor = 1/factor
}

BREAKPOINT {
	if (gmax) { at_time(onset) }
        g = gmax*dblexp(t-onset)

	i = g*(v - e)
}

FUNCTION dblexp(x (ms)) {
  if (x < 0 || x/tau2 > 10) {
    dblexp = 0
  } else {
    dblexp = factor*(-exp(-x/tau1) + exp(-x/tau2))
  }
}

[ted]

With one exception, it is best not to change anything in NEURON's installation tree. Such changes
1. result in an idiosyncratic "personalized" version of NEURON and invite the creation of code that will not run on anyone else's machine. This destroys one of the primary benefits of using a simulation environment: the knowledge that user-written code will run anywhere.
2. will be wiped out if you ever update NEURON.

The one exception is the nrn.defaults file (nrn.def under MSWin), a text file that contains user-customizable specifications, most of which affect the appearance of NEURON's GUI.


Decisions about what changes to make to NEURON involve weighing the potential benefits against the likely costs. Replacing AlphaSynapse would break a large body of existing code; the value of adding Exp2SynDelay is questionable, since what that mechanism does can already be achieved with features that already exist. So it is unlikely that either of these changes will be made.