Could you please fix this .hoc file?
If I did, what would you learn? Here's how to figure it out for yourself.
So what's mean of "cannot assign to left hand side"?
Seems pretty clear: it's complaining about an assignment statement, i.e. a statment of the form
a = b
So the problem is in one of the assignment statements in the hoc file.
But which one? This is a run time error message (it occurs during simulation), and hoc often gives rather vague clues about the causes of run time errors. But this one seems rather specific: there's a problem with initstim(). So take a close look at the contents of proc initstim().
A good strategy for localizing errors is to look for statements that use unfamiliar keywords. If you're not sure about the usage of a particular keyword, read about it in the Programmer's Reference. proc initstim() doesn't contain a lot of keywords, so you won't have much reading to do before you discover the problem. Once you find the error, look for other instances of it and fix them too.
"Aha! ted made a mistake!"
Yes, and you can figure out how to fix it. There are several lessons here. First, trust noone's code, not even your own (I know this one particularly well). Second, the only way to stop making mistakes is to stop doing things. Third, with continued practice it is possible to develop skill in debugging, especially when there is no "integrated development environment." Fourth, except for the most trivial cases, program development always proceeds in a cycle of incremental revision and testing. Incremental revison means that, even though one may--and should--have an overall plan in mind, and may even have constructed a detailed outline of what the final program will look like, only the most trivial programs can be implemented at one pass. Anything with reasonable complexity will require multiple iterations.
What's mean of the function "fih = new FInitializeHandler("initstim()")" in your code?
Have you read the Programmer's Reference documentation of the FInitializeHandler class? Have you searched the NEURON Forum for discussions that involve this keyword?
If this code works, how can I stop the simulation?
If I were you, I'd use NEURON's standard run system to control simulation flow ("simulation flow" includes starting and stopping simulations). The easiest way to do this during program development is with the GUI. To learn how to use the GUI, work through this tutorial
Construction and Use of Models: Part 1. Elementary Tools
which is listed on the Documentation page of NEURON's WWW site
http://www.neuron.yale.edu/.
After you have everything working the way you want it, you may want to use hoc statements to control program execution. But believe me, you have a lot to discover about this simple model you have implemented, and it will be much easier if you start by using the NEURON Main Menu toolbar to construct a custom user interface with a RunControl panel and a "Voltage axis" graph that shows axon membrane potential at both 0 and 0.5. For example, you need to discover the axon's resting potential so you can specify the proper initial value for membrane potential (otherwise your simulations will contain an initialization transient that may take many tens of milliseconds to decay). You also need to know how long a simulation must run in order to have a reasonable chance of including at least one synaptic event. And you may want to adjust the strength of the synaptic input, or the synaptic time constant.
how can I control the amplitude of the stimulation?
By changing the NetCon's weight; read in the Programmer's Reference about NetStim and ExpSyn.
Comments about the NMODL code:
I'd suggest changing the suffix in the NMODL block to lower case, specifically hp. Why?
1. First, about lower case: Capitalized keywords are generally reserved for the names of object classes. Point processes are objects, so the NMODL code that defines a class of point process uses a capitalized word for the name of the object class. Your h current is a density mechanism, not an object class. NMODL code that defines a density mechanism therefore uses a lower case word for the name of the density mechanism.
2. Next, about whether or not to use an "i" or an "I" (upper case i) as the first letter in the name of a mechanism. Most mechanisms that generate a current, whether they are point processes or density mechanisms, declare a variable that starts with "i" in the NEURON block. This variable can be used by user-written hoc statements to discover the current that is generated by the mechanism.
The complete hoc name of this variable will be of the form
i..._suffix for a density mechanism,
or, in the case of point processes,
ClassName.i... or objrefname.i...
If the suffix starts with "i", or the ClassName or objrefname starts with i, then the user-written hoc code will have variable names with redundant i's, like this
i_ihp
or
IGABA.i
or
igaba.i
If you were writing a paper, you might have a variable called i_hp or GABAi or igaba, but nobody would deliberately choose names like i_ihp, IGABAi, or igabai (or even worse, ih_ih, ik_ik etc.). So why write NMODL code in a way that forces similar hiccups in hoc?
The ASSIGNED block declares
taur (/ms)
rinf (/ms)
which is silly. Won't cause an error in your simulation, but will gag modlunit (have you checked this mod file with modlunit?) and will make experienced NEURON users lift an eyebrow. Time constants in NMODL use (ms), and steady state values of dimensionless state variables are dimensionless (the corresponding units specification is (1)).
Comments about the hoc code:
The statement
eh = -20
does nothing useful because the name on the left hand side is not used anywhere else in the program. You probably meant eh_hp.
By the way, to eliminate this hiccup you might want to change the declaration in the ASSIGNED block of the mod file to
e (mV)
Don't forget to revise the "ih =" statement in the BREAKPOINT block.