Arrays as RANGE variables

[gartland]

I'm using a bit of code from the examples that are around implementing radial diffusion with a variable number of concentric shells. The diffusible ion concentration is stored in a STATE variable that is initialized as an array and then used in a KINETIC block. I'd like to be able to see these concentrations from hoc during the a simulation so I think I need to make it a RANGE variable only it doesn't seem possible for a RANGE variable to be an array. My work around has been to make a whole bunch of RANGE variables, one for each shell and this makes it work fine.

It would be nice to be able to change the number of shells easily without having to add more variables each time (the KINETIC block works so nicely if you can loop over the array of concentrations...). Also I'd like to be accessing the concentration of several different diffusible molecules so I'd really rather not confuse things by having to make a RANGE variable for every molecule and every shell.

What is the best way to be able to see STATE variables that are arrays, in hoc (or python which is what I'm using....though if I get it into hoc i bet it'll be visible in python too!)?

Thanks,

-Andrew

[ted]

The diffusible ion concentration is stored in a STATE variable that is initialized as an array

It would be more correct to say that the concentrations are STATE variables that are referenced by means of an array syntax.

I'd like to be able to see these concentrations from hoc during the a simulation so I think I need to make it a RANGE variable only it doesn't seem possible for a RANGE variable to be an array. My work around has been to make a whole bunch of RANGE variables, one for each shell and this makes it work fine.

A workaround for a nonexistent problem. All STATEs are automatically RANGE variables, visible from hoc with the syntax

Code: Select all

statename_suffix[index](range)

without having to be declared as such in the NEURON block.

So there's no need to create bogus RANGE variables. In retrospect it's not surprising to think otherwise, because what is called statename in NMODL is called statename_suffix from hoc--one might easily have imagined something like statename_suffix, try it, and get an error message but no hint as to the correct syntax.

For a concrete example, consider these excerpts from the NMODL code for the cadifus mechanism described in Example 9.8: Calcium diffusion with buffering of the NEURON book (page 245 et seq.):

Code: Select all

NEURON {
  SUFFIX cadifus
 . . .
DEFINE Nannuli 4
 . . .
STATE {
  ca[Nannuli]       (mM) <1e-10>
  CaBuffer[Nannuli] (mM)
  Buffer[Nannuli]   (mM)
}

So ca[0] . . . ca[3] are accessible from hoc at any range value x as ca_cadifus[0](x) etc., and likewise for CaBuffer and Buffer.

Hint: to discover the name of something that belongs to a density mechanism or point process, create a toy model (one section, maybe with nseg = 3), insert or attach the mechanism, then bring up a Graph and use its Plot what? function to browse the names of hoc-accessible variables.

It would be nice to be able to change the number of shells easily without having to add more variables each time (the KINETIC block works so nicely if you can loop over the array of concentrations...). Also I'd like to be accessing the concentration of several different diffusible molecules so I'd really rather not confuse things by having to make a RANGE variable for every molecule and every shell.

Both are now nonissues, unless you mean something very different from what I think you do.

[gartland]

Brilliant! I figured that this was probably a non-issue, but I couldn't find the answer I needed. Thanks!

So if I try to "record" the state variable that is syntactically represented as an array, will it be multiplexed into the vector that is doing the recording? I bet this will answer my other standing question in the "NEURON Hacks" section as well...

-Andrew

[ted]

So if I try to "record" the state variable that is syntactically represented as an array, will it be multiplexed into the vector that is doing the recording?

In a word, no.