New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better documentation of hh_cond_exp_traub and Brette-2007-compatible refractory time #944

Merged
merged 5 commits into from May 28, 2018

Conversation

Projects
None yet
3 participants
@heplesser
Contributor

heplesser commented Apr 27, 2018

When fixing #473 to make t_ref configurable in hh_cond_exp_traub, we configured the model with t_ref==0 as default. This does not work properly, since the spike detection mechanism relies on an absolute refractory peroid. This PR sets the default t_ref=2ms as used in the Brette et al (2007) review and documents the relation of this model to the review more clearly, as well as differences from the Traub&Miles (1991) model.

See #329 (comment) for a thorough discussion.

@Silmathoron

I have mixed feelings about this:

  • on the one hand the current behaviour is wrong and the fix is quite obviously better
  • on the other hand this feels horribly ad hoc and I feel we should rather try to improve the "spike detection" mechanism.

That being said, I am aware of the fact that it is very likely none of us has the time (nor probably any desire) to do this...
So unless we decide to remove the model altogether, I'll approve the PR ^^"

@heplesser

This comment has been minimized.

Show comment
Hide comment
@heplesser

heplesser Apr 27, 2018

Contributor

@Silmathoron This neuron model is used for the "hh_coba" benchmark in the Brette et al (2007) simulator review, so we ought to keep it in NEST. Unfortunately, the paper text does not describe spike or reset mechanisms at all. Benchmark code for different simulators is available on ModelDB, although it is not easy to infer how spike detection is done by the different simulators. The most transparent is Brian:

P=NeuronGroup(4000,model=eqs,
              threshold=EmpiricalThreshold(threshold=-20*mV,refractory=3*ms),
              implicit=True,freeze=True,compile=False)

I.e., a fixed threshold at -20 mV and an absolute refractory period of 3 ms. Since no reset is specified, I assume that without the refractory period, Brian would emit spikes for each time step until membrane potential drops below -20 mV.

I have not been able to find threshold conditions for other simulators, although for Neuron this piece of code

proc connect2target() { //$o1 target point process, $o2 returned NetCon
  soma $o2 = new NetCon(&v(1), $o1)
  $o2.threshold = -10 //*	
}

looks like there may be a spike threshold of 10 mV.

Quite a mess, but maybe compatibility with the Brian implementation would not be a bad idea?

Contributor

heplesser commented Apr 27, 2018

@Silmathoron This neuron model is used for the "hh_coba" benchmark in the Brette et al (2007) simulator review, so we ought to keep it in NEST. Unfortunately, the paper text does not describe spike or reset mechanisms at all. Benchmark code for different simulators is available on ModelDB, although it is not easy to infer how spike detection is done by the different simulators. The most transparent is Brian:

P=NeuronGroup(4000,model=eqs,
              threshold=EmpiricalThreshold(threshold=-20*mV,refractory=3*ms),
              implicit=True,freeze=True,compile=False)

I.e., a fixed threshold at -20 mV and an absolute refractory period of 3 ms. Since no reset is specified, I assume that without the refractory period, Brian would emit spikes for each time step until membrane potential drops below -20 mV.

I have not been able to find threshold conditions for other simulators, although for Neuron this piece of code

proc connect2target() { //$o1 target point process, $o2 returned NetCon
  soma $o2 = new NetCon(&v(1), $o1)
  $o2.threshold = -10 //*	
}

looks like there may be a spike threshold of 10 mV.

Quite a mess, but maybe compatibility with the Brian implementation would not be a bad idea?

@heplesser

This comment has been minimized.

Show comment
Hide comment
@heplesser

heplesser Apr 30, 2018

Contributor

See also #329.

Contributor

heplesser commented Apr 30, 2018

See also #329.

@heplesser

This comment has been minimized.

Show comment
Hide comment
@heplesser

heplesser Apr 30, 2018

Contributor

See #329 (comment) for a thorough discussion of the situation and options.

Contributor

heplesser commented Apr 30, 2018

See #329 (comment) for a thorough discussion of the situation and options.

@heplesser

This comment has been minimized.

Show comment
Hide comment
@heplesser

heplesser May 2, 2018

Contributor

@Silmathoron @diesmann I have updated the PR after discussions, so default t_ref now is 2 ms. I also made the connection to Brette et al (2007) clearer in the documentation. Could you take a look?

Contributor

heplesser commented May 2, 2018

@Silmathoron @diesmann I have updated the PR after discussions, so default t_ref now is 2 ms. I also made the connection to Brette et al (2007) clearer in the documentation. Could you take a look?

@heplesser heplesser changed the title from Configure hh_cond_exp_traub with sensible t_ref. to Better documentation of hh_cond_exp_traub and Brette-2007-compatible refractory time May 2, 2018

@heplesser heplesser added this to the NEST 2.16 milestone May 2, 2018

@Silmathoron

This comment has been minimized.

Show comment
Hide comment
@Silmathoron

Silmathoron May 3, 2018

Contributor

@heplesser so all the changes mentioned in #329 including the change in spike detection would be for NEST 3?

Contributor

Silmathoron commented May 3, 2018

@heplesser so all the changes mentioned in #329 including the change in spike detection would be for NEST 3?

@heplesser

This comment has been minimized.

Show comment
Hide comment
@heplesser

heplesser May 3, 2018

Contributor

@Silmathoron Yes, they would all be for NEST 3 and then in a new model, while the current hh_cond_exp_traub would be kept primarily to keep the Brette et al (2007) examples runnning.

Contributor

heplesser commented May 3, 2018

@Silmathoron Yes, they would all be for NEST 3 and then in a new model, while the current hh_cond_exp_traub would be kept primarily to keep the Brette et al (2007) examples runnning.

@Silmathoron

Fine with me 👍

@heplesser heplesser requested a review from suku248 May 28, 2018

@suku248

👍 thanks @heplesser

@heplesser heplesser removed the request for review from diesmann May 28, 2018

@heplesser heplesser merged commit d175510 into nest:master May 28, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@heplesser heplesser deleted the heplesser:fix-hh-cond-exp-traub-tref branch Aug 1, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment