www.neuron.yale.edu

I have seen some posts about reseeding NetStim with each instance. I'm not very clear about the replies that I've found. Is there a none mod way to reseed? Does that make sense? Like netstimobject.seed = rand? Thanks!

rllin wrote:I have seen some posts about reseeding NetStim with each instance. I'm not very clear about the replies that I've found.

Could you be more clear about which posts you are referring to?

Mainly this one
http://www.neuron.yale.edu/phpBB/viewto ... stim#p8717

If you want each NetStim to generate events at times that are governed by independent pseudorandom streams, you need to use the approach described in
How to generate independent random spike streams
http://www.neuron.yale.edu/neuron/node/60
If you have specific questions about that approach, ask them.

Repeat
create a new NetStim instance
create a new Random instance
make the NetStim get its event times from the Random
Until enough NetStims have been created
Run a simulation and show results

I'm not sure why according to this would not work?

Why would this http://www.neuron.yale.edu/neuron/node/63 be needed?

1. It won't work because the
for . . .
and the
{ stuff to be executed }
are on separate lines.

2. If you fix that problem, it can't work because
netstim.seed() = somenumber
isn't how to use the NetStim class's seed() method to specify the random number seed. The correct syntax is
netstim.seed(somenumber)

3. Even if you fix problems 1 and 2, do you know whether calling a NetStim's seed() method will do anything to a Random instance that has been associated with it? Will it be the same as setting the MCellRan4's highindex, or will it be the same as setting the lowindex, or will it have no effect at all? You might want to experiment with that yourself and see what happens. But even if you discover that it does affect the lowindex or highindex, calling NetStim's seed() looks like a good way to cause problems for future code maintenance and debugging, because there doesn't seem to be any necessary reason for it to have any effect at all, or for there to be any guarantee that it will have the same effect in any future version of NEURON. So you might be burying a potential time bomb in your own code.

4. Even if the answer to question 3 is "calling a NetStim's seed() method does exactly what I want", there is a completely separate issue: whether it makes sense to write code like this
for i=0,N someparameter = rng.uniform(0,M)
First note this general problem: there is no guarantee that each call to rng.uniform will return a different value. If there are any repeats, you will have two or more random number generators that are NOT statistically independent.
Second, note this particular problem which arises if someparameter is the highindex of the ith instance of the MCellRan4 class: if two MCellRan4's have highindexes that are too close together, the one with the smaller highindex will soon be returning values that are identical to the values that were generated by the other one earlier in the same simulation. You need to make sure the highindex values are separated by at least as many times you are going to sample from the random number generators in the course of a simulation. You don't want to leave this up to chance--you have to take special care to ensure statistical independence.

Thanks for your reply, Ted.

Let me see if I understand NetStim for a second here, before I misunderstand your reply.

Each instance of NetStim is not necessarily independent because they have the same seed? Each instance would fire at the same times?

EDIT: Actually they wouldn't fire at the same times, right? Why are they not independent? http://www.neuron.yale.edu/neuron/node/60 says they aren't independent, but I don't see how from the example?

I tried implementing NetStim independence just like http://www.neuron.yale.edu/neuron/node/63
but I get an error where (I think this is where the issue is since the error starts when this is added)

The error is pretty vague though... This is the entirety of my code for generating NetStims

rllin wrote:Each instance of NetStim is not necessarily independent because they have the same seed?

Please read and re-read the documentation of mcell_ran4 and MCellRan4. Each call to the mcell_ran4 generator increments highindex by 1. Now imagine two instances of MCellRan4 called A and B, where A and B both have the same lowindex but A initially has highindex = m and B initially has highindex = m+n, where m & n are both > 0. A will return values that are statistically different from those that are returned by B until A's highindex has been incremented n times.

rllin wrote:I tried implementing NetStim independence
. . .
but I get an error where

Code: Select all

ns.noiseFromRandom(rs.r)

(I think this is where the issue is since the error starts when this is added)

Have you tried creating a hoc file called test.hoc which contains just these statements and then
nrngui test.hoc
(or double click on test.hoc)
?
If you don't see an error message, the problem lies elsewhere.

Yeah, there is no error message. Everything works fine though if I take out the extra code for reseeding though?

I actually get a different error now for some reason? This is when I use the snippet of code with my other code which runs with no problem without the reseeding.

rllin wrote:Yeah, there is no error message. Everything works fine though if I take out the extra code for reseeding though?

Suggest you pare back your model so that there is just one NetStim that drives one synaptic mechanism. In doing that, you may discover what is causing the problem. I can tell you that it isn't anything in the code you have displayed up to this point.

I don't see the error, but it works for only one NetStim. Problem is each run of the simulation has the same exact spikes. This shouldn't happen if reseeding is occurring, right?

It's exactly what should happen, if the pseudorandom sequence generator that generates the NetStim's spike times starts with the same high index and low index on each run. That's how you get reproducible randomness, which is absolutely essential for program development and debugging.