Hello,
I'm implementing a receptor in NMODL ("recept"). This (distributed) mechanism needs to know the local agonist concentration. So I wrote another NMODL mechanism ("agon") which simply supplies the agonist concentration as a range variable("conc_agon").
But now I can't seem to access this variable from within the receptor mechanism. I specified it as conc_agon in the ASSIGNED block of the recept mod file and assumed that it would be read from neuron just like voltage.
It works fine when I specify the agonist concentration within the recept.mod file, but this is logically not satisfying because one could imagine another mechanism which wants to access the same agonist concentration.
So my two general questions are:
*) is it possible for an NMODL mechanism to access variables from another NMODL mechanism?
*) is there a way to specify dependencies between NMODL mechanisms? In my example, it would be nice if as soon as I insert the receptor, the agonist is inserted automatically (in case it isn't already inserted). - For ions, this seems to exist: if you have a USEION statement in an NMODL file, the ion is automatically inserted into the membrane as well.
Thank you and best wishes,
Christian.
communication between different NMODL mechanisms
-
ted
- Site Admin
- Posts: 6398
- Joined: Wed May 18, 2005 4:50 pm
- Location: Yale University School of Medicine
- Contact:
Re: communication between different NMODL mechanisms
Excellent questions.
feature. Read the following:
Pointer-Communication
http://www.neuron.yale.edu/neuron/stati ... munication
Basic NMODL Statements / Pointer
http://www.neuron.yale.edu/neuron/stati ... ml#Pointer
setpointer
http://www.neuron.yale.edu/neuron/stati ... setpointer
To see an example with comments about implementational details,
check out the ModelDB entry for this paper
Gruber AJ, Solla SA, Surmeier DJ, Houk JC (2003) Modulation of striatal
single units by expected reward: a spiny neuron model displaying
dopamine-induced bistability. J Neurophysiol 90:1095-114
http://senselab.med.yale.edu/senselab/m ... odel=39949
For the other way, see my answer to your 2nd question.
way to deal with extracellular or intracellular ligands, because it avoids
having to fool around with setpointer--the concentration you need to
access is automatically available as a RANGE variable. I didn't bother
doing this for the spiny neuron model, but if I were going to do any more
work with it, I would have moved away from POINTER.
So in your mod file that controls the agonist concentration, add this
USEION conc READ conc WRITE conc VALENCE 1
to the NEURON block (the last time I checked, it was necessary to
specify a nonzero VALENCE or else there would be an error msg).
Of course conc should be ASSIGNED.
And in your mod file that defines the properties of recept, add this
USEION conc READ conc VALENCE 1
(I'm not sure that the VALENCE 1 part is absolutely necessary, since
the agon mechanism already declares it, but it shouldn't hurt). Again,
conc should be ASSIGNED.
Let me know what you did, and how it worked.
--Ted
Can be done in two different ways. One is to use NMODL's "POINTER"exp wrote: *) is it possible for an NMODL mechanism to access variables from another NMODL mechanism?
feature. Read the following:
Pointer-Communication
http://www.neuron.yale.edu/neuron/stati ... munication
Basic NMODL Statements / Pointer
http://www.neuron.yale.edu/neuron/stati ... ml#Pointer
setpointer
http://www.neuron.yale.edu/neuron/stati ... setpointer
To see an example with comments about implementational details,
check out the ModelDB entry for this paper
Gruber AJ, Solla SA, Surmeier DJ, Houk JC (2003) Modulation of striatal
single units by expected reward: a spiny neuron model displaying
dopamine-induced bistability. J Neurophysiol 90:1095-114
http://senselab.med.yale.edu/senselab/m ... odel=39949
For the other way, see my answer to your 2nd question.
This is the second way: take advantage of USEION. IMO this is the best*) is there a way to specify dependencies between NMODL mechanisms? In my example, it would be nice if as soon as I insert the receptor, the agonist is inserted automatically (in case it isn't already inserted). - For ions, this seems to exist: if you have a USEION statement in an NMODL file, the ion is automatically inserted into the membrane as well.
way to deal with extracellular or intracellular ligands, because it avoids
having to fool around with setpointer--the concentration you need to
access is automatically available as a RANGE variable. I didn't bother
doing this for the spiny neuron model, but if I were going to do any more
work with it, I would have moved away from POINTER.
So in your mod file that controls the agonist concentration, add this
USEION conc READ conc WRITE conc VALENCE 1
to the NEURON block (the last time I checked, it was necessary to
specify a nonzero VALENCE or else there would be an error msg).
Of course conc should be ASSIGNED.
And in your mod file that defines the properties of recept, add this
USEION conc READ conc VALENCE 1
(I'm not sure that the VALENCE 1 part is absolutely necessary, since
the agon mechanism already declares it, but it shouldn't hurt). Again,
conc should be ASSIGNED.
Let me know what you did, and how it worked.
--Ted
Ted,
thank you for your help.
When I add
USEION conc READ conc WRITE conc VALENCE 1
to my mod file controlling the agonist concentration, I get a compilation error:
Translating agon.mod into agon.c
conc is not a valid ionic variable for conc at line 9 in file agon.mod
USEION conc READ conc WRITE conc VALENCE 1
the same happens if I have "USEION agon ..."
What I'll do for now is I'll treat the agonist as an impermeant ion. I can use the iono range variable for my exernal agonist concentration. It's not the most beautiful solution, as there will automatically be bookkeeping of an associated ionic current, which I will never need, but it should work.
Disadvantage: I don't think I can set a default value. Or can I?
What did you have in mind with your suggested solution ("second way")?
Am I right that your aim was to use USEION to load the NMODL specified mechanism for the agonist concentration instead of the automatic ionic mechanism? If so, why does agon.mod need to have a USEION statement? And shouldn't the line in recept.mod be "USEION agon READ conc VALENCE 1" instead of "USEION conc READ conc VALENCE 1"?
Best wishes,
Christian.
thank you for your help.
When I add
USEION conc READ conc WRITE conc VALENCE 1
to my mod file controlling the agonist concentration, I get a compilation error:
Translating agon.mod into agon.c
conc is not a valid ionic variable for conc at line 9 in file agon.mod
USEION conc READ conc WRITE conc VALENCE 1
the same happens if I have "USEION agon ..."
What I'll do for now is I'll treat the agonist as an impermeant ion. I can use the iono range variable for my exernal agonist concentration. It's not the most beautiful solution, as there will automatically be bookkeeping of an associated ionic current, which I will never need, but it should work.
Disadvantage: I don't think I can set a default value. Or can I?
What did you have in mind with your suggested solution ("second way")?
Am I right that your aim was to use USEION to load the NMODL specified mechanism for the agonist concentration instead of the automatic ionic mechanism? If so, why does agon.mod need to have a USEION statement? And shouldn't the line in recept.mod be "USEION agon READ conc VALENCE 1" instead of "USEION conc READ conc VALENCE 1"?
Best wishes,
Christian.
Ok, problem solved, the idea of the 2nd way to deal with the above problem is to have a "USEION agon ..." statement in both the agon.mod and the recept.mod files, and to use the range variable agono (which is automatically supplied) for the communication between the two mechanisms.
The use of pointers maybe addresses the problem of communication between NMODL mechanisms more directly, but the disadvantage is that the pointers have to be set on the hoc level, which is somewhat inconvenient and error prone for the user.
Thanks,
Christian.
The use of pointers maybe addresses the problem of communication between NMODL mechanisms more directly, but the disadvantage is that the pointers have to be set on the hoc level, which is somewhat inconvenient and error prone for the user.
Thanks,
Christian.