All devices

Back to model directory

class ac_generator : public DeviceNode
#include <ac_generator.h>

Name: ac_generator - provides AC input current

Description:

This device produces an ac-current sent by a CurrentEvent. The current is given by

\[\]

where

\[\]

Parameters:

amplitude

pA

Amplitude of sine current

offset

pA

Constant amplitude offset

frequency

Hz

Frequency

phase

degree

Phase of sine current (0-360 deg)

Setting start and stop (see StimulatingDevice) only windows the current as defined above. It does not shift the time axis.

References:

1

Rotter S and Diesmann M (1999). Exact digital simulation of time- invariant linear systems with applications to neuronal modeling, Biol. Cybern. 81, 381-402. DOI: https://doi.org/10.1007/s004220050570

Sends: CurrentEvent

Author: Johan Hake, Spring 2003

SeeAlso: Device, StimulatingDevice, dc_generator, step_current_generator

class correlation_detector : public Node
#include <correlation_detector.h>

Name: correlation_detector - Device for evaluating cross correlation between two spike sources

Description:

The correlation_detector device is a recording device. It is used to record spikes from two pools of spike inputs and calculates the count_histogram of inter-spike intervals (raw cross correlation) binned to bins of duration \( \delta_\tau \). The result can be obtained via GetStatus under the key /count_histogram. In parallel it records a weighted histogram, where the connection weights are used to weight every count. In order to minimize numerical errors the Kahan summation algorithm is used when calculating the weighted histogram. (http://en.wikipedia.org/wiki/Kahan_summation_algorithm) Both are arrays of \( 2*\tau_{max}/\delta_\tau+1 \) values containing the histogram counts in the following way:

Let \( t_{1,i}\) be the spike times of source 1, \( t_{2,j} \) the spike times of source 2. histogram[n] then contains the sum of products of the weight \( w_{1,i}*w_{2,j}, \) count_histogram[n] contains 1 summed over all events with \( t_{2,j}-t_{1,i} \) in

\[\]
\[\]

The bins are centered around the time difference they represent, but are left-closed and right-open. This means that events with time difference -tau_max-delta_tau/2 are counted in the leftmost bin, but event with difference tau_max+delta_tau/2 are not counted at all.

The correlation detector has two inputs, which are selected via the receptor_port of the incoming connection: All incoming connections with receptor_port = 0 will be pooled as the spike source 1, the ones with receptor_port = 1 will be used as spike source 2.

Parameters:

Tstart

real

Time when to start counting events. This time should be set to at least start + tau_max in order to avoid edge effects of the correlation counts.

Tstop

real

Time when to stop counting events. This time should be set to at most Tsim - tau_max, where Tsim is the duration of simulation, in order to avoid edge effects of the correlation counts.

delta_tau

ms

Bin width. This has to be an odd multiple of the resolution, to allow the symmetry between positive and negative time-lags.

tau_max

ms

One-sided width. In the lower triagnular part events with differences in [0, tau_max+delta_tau/2) are counted. On the diagonal and in the upper triangular part events with differences in (0, tau_max+delta_tau/2].

N_channels

integer

The number of pools. This defines the range of receptor_type. Default is 1. Setting N_channels clears count_covariance, covariance and n_events.

histogram

squared synaptic weights

read-only - raw, weighted, cross-correlation counts Unit depends on model

histogram_correction

list of integers

read-only - Correction factors for kahan summation algoritm

n_events

list of integers

Number of events from source 0 and 1. By setting n_events to [0,0], the histogram is cleared.

Remarks:

This recorder does not record to file, screen or memory in the usual sense.

Correlation detectors IGNORE any connection delays.

Correlation detector breaks with the persistence scheme as follows: the internal buffers for storing spikes are part of State_, but are initialized by init_buffers_().

Example:

See Auto- and crosscorrelation functions for spike trains[cross_check_mip_corrdet.py] in pynest/examples.

 SLI

 /s1 /spike_generator Create def
 /s2 /spike_generator Create def
 s1 << /spike_times [ 1.0 1.5 2.7 4.0 5.1 ] >> SetStatus
 s2 << /spike_times [ 0.9 1.8 2.1 2.3 3.5 3.8 4.9 ] >> SetStatus
 /cd /correlation_detector Create def
 cd << /delta_tau 0.5 /tau_max 2.5 >> SetStatus
 s1 cd << /receptor_type 0 >> Connect
 s2 cd << /receptor_type 1 >> Connect
 10 Simulate
 cd [/n_events] get ==   --> [# 5 7 #]
 cd [/histogram] get ==  --> [. 0 3 3 1 4 3 2 6 1 2 2 .]
 cd << /reset true >> SetStatus
 cd [/histogram] get ==  --> [. 0 0 0 0 0 0 0 0 0 0 0 .]

Receives: SpikeEvent

Author: Moritz Helias Jakob Jordan (implemented Kahan summation algorithm) 2013/02/18

FirstVersion: 2007/5/21

SeeAlso: spike_detector, Device, PseudoRecordingDevice

Availability: NEST

class correlomatrix_detector : public Node
#include <correlomatrix_detector.h>

Name: correlomatrix_detector - Device for measuring the covariance matrix from several inputs

Description:

The correlomatrix_detector is a recording device. It is used to record spikes from several pools of spike inputs and calculates the covariance matrix of inter-spike intervals (raw auto and cross correlation) binned to bins of duration delta_tau. The histogram is only recorded for non-negative time lags. The negative part can be obtained by the symmetry of the covariance matrix \( C(t) = C^T(-t) \). The result can be obtained via GetStatus under the key /count_covariance. In parallel it records a weighted histogram, where the connection weight are used to weight every count, which is available under the key /covariance. Both are matrices of size N_channels x N_channels, with each entry C_ij being a vector of size tau_max/delta_tau + 1 containing the (weighted) histogram for non-negative time lags.

The bins are centered around the time difference they represent, and are left-closed and right-open in the lower triangular part of the matrix. On the diagonal and in the upper triangular part the intervals are left-open and right-closed. This ensures proper counting of events at the border of bins, allowing consistent integration of a histogram over negative and positive time lags by stacking two parts of the histogram

(C(t)=[C[i][j][::-1],C[j][i][1:]]).

In this case one needs to exclude C[j][i][0] to avoid counting the zero-lag bin twice.

The correlomatrix_detector has a variable number of inputs which can be set via SetStatus under the key N_channels. All incoming connections to a specified receptor will be pooled.

Parameters:

Tstart

real

Time when to start counting events. This time should be set to at least start + tau_max in order to avoid edge effects of the correlation counts.

Tstop

real

Time when to stop counting events. This time should be set to at most Tsim - tau_max, where Tsim is the duration of simulation, in order to avoid edge effects of the correlation counts.

delta_tau

ms

Bin width. This has to be an odd multiple of the resolution, to allow the symmetry between positive and negative time-lags.

tau_max

ms

One-sided width. In the lower triagnular part events with differences in [0, tau_max+delta_tau/2) are counted. On the diagonal and in the upper triangular part events with differences in (0, tau_max+delta_tau/2].

N_channels

integer

The number of pools. This defines the range of receptor_type. Default is 1. Setting N_channels clears count_covariance, covariance and n_events.

covariance

3D matrix of integers

matrix of read-only -raw, weighted, auto/cross correlation

count_covariance

3D matrix of integers

matrix of read-only -raw, auto/cross correlation counts

n_events

list of integers

number of events from all sources

Remarks: This recorder does not record to file, screen or memory in the usual sense.

Note

Correlomatrix detectors IGNORE any connection delays.

Note

Correlomatrix detector breaks with the persistence scheme as follows: the internal buffers for storing spikes are part of State_, but are initialized by init_buffers_().

Example:

/s1 /spike_generator Create def
/s2 /spike_generator Create def
s1 << /spike_times [ 1.0 1.5 2.7 4.0 5.1 ] >> SetStatus
s2 << /spike_times [ 0.9 1.8 2.1 2.3 3.5 3.8 4.9 ] >> SetStatus
/cm /correlomatrix_detector Create def
cm << /N_channels 2 /delta_tau 0.5 /tau_max 2.5 >> SetStatus
s1 cm << /receptor_type 0 >> Connect
s2 cm << /receptor_type 1 >> Connect
10 Simulate
cm [/n_events] get ==   --> [# 5 7 #]
cm [/count_covariance] get ==  --> [[<# 5 1 2 2 0 2 #> <# 3 4 1 3 3 0 #>]
                                    [<# 3 2 6 1 2 2 #> <# 9 3 4 6 1 2 #>]]
cm << /N_channels 2 >> SetStatus
cm [/count_covariance] get ==  --> [[<# 0 0 0 0 0 0 #> <# 0 0 0 0 0 0 #>]
                                    [<# 0 0 0 0 0 0 #> <# 0 0 0 0 0 0 #>]]

Receives: SpikeEvent

Author: Dmytro Grytskyy Jakob Jordan

FirstVersion: 2013/02/27

SeeAlso: correlation_detector, spike_detector, Device, PseudoRecordingDevice

Availability: NEST

class correlospinmatrix_detector : public Node
#include <correlospinmatrix_detector.h>

Name: correlospinmatrix_detector - Device for measuring the covariance matrix from several inputs

Description:

The correlospinmatrix_detector is a recording device. It is used to record correlations from binary neurons from several binary sources and calculates the raw auto and cross correlation binned to bins of duration delta_tau. The result can be obtained via GetStatus under the key /count_covariance. The result is a tensor of rank 3 of size N_channels x N_channels, with each entry \( C_{ij} \) being a vector of size \( 2*\tau_{max}/\delta_{\tau} + 1 \) containing the histogram for the different time lags.

The bins are centered around the time difference they represent, and are left-closed and right-open in the lower triangular part of the matrix. On the diagonal and in the upper triangular part the intervals are left-open and right-closed. This ensures proper counting of events at the border of bins.

The correlospinmatrix_detector has a variable number of inputs which can be set via SetStatus under the key N_channels. All incoming connections to a specified receptor will be pooled.

Parameters:

Tstart

real

Time when to start counting events. This time should be set to at least start + tau_max in order to avoid edge effects of the correlation counts.

Tstop

real

Time when to stop counting events. This time should be set to at most Tsim - tau_max, where Tsim is the duration of simulation, in order to avoid edge effects of the correlation counts.

delta_tau

ms

Bin width. This has to be an odd multiple of the resolution, to allow the symmetry between positive and negative time-lags.

tau_max

ms

One-sided width. In the lower triagnular part events with differences in [0, tau_max+delta_tau/2) are counted. On the diagonal and in the upper triangular part events with differences in (0, tau_max+delta_tau/2].

N_channels

integer

The number of pools. This defines the range of receptor_type. Default is 1. Setting N_channels clears count_covariance, covariance and n_events.

covariance

3D matrix of integers

matrix of read-only -raw, weighted, auto/cross correlation

count_covariance

3D matrix of integers

matrix of read-only -raw, auto/cross correlation counts

Remarks:

This recorder does not record to file, screen or memory in the usual sense. The result must be obtained by a call to GetStatus. Setting either N_channels, Tstart, Tstop, tau_max or delta_tau clears count_covariance.

Correlospinmatrix detectors IGNORE any connection delays.

Correlospinmatrix detector breaks with the persistence scheme as follows: the internal buffers for storing spikes are part of State_, but are initialized by init_buffers_().

Example:

See also pynest/examples/correlospinmatrix_detector_two_neuron.py for a script reproducing a setting studied in Fig 1 of Grinzburg & Sompolinsky (1994) PRE 50(4) p. 3171.

See also examples/nest/correlospinmatrix_detector.sli for a basic example in sli.

/sg1 /spike_generator Create def
/sg2 /spike_generator Create def
/sg3 /spike_generator Create def

/csd /correlospinmatrix_detector Create def

csd << /N_channels 3 /tau_max 10. /delta_tau 1.0 >> SetStatus

sg1 << /spike_times [10. 10. 16.] >> SetStatus
sg2 << /spike_times [15. 15. 20.] >> SetStatus


% one final event needed so that last down transition will be detected
sg3 << /spike_times [25.] >> SetStatus


sg1 csd << /receptor_type 0 >> Connect
sg2 csd << /receptor_type 1 >> Connect
sg3 csd << /receptor_type 2 >> Connect

100. Simulate

Receives: SpikeEvent

Author: Moritz Helias

FirstVersion: 2015/08/25

SeeAlso: correlation_detector, correlomatrix_detector, spike_detector, Device, PseudoRecordingDevice

Availability: NEST

class dc_generator : public DeviceNode
#include <dc_generator.h>

Name: dc_generator - provides DC input current

Description: The DC-Generator provides a constant DC Input to the connected node. The unit of the current is pA.

Parameters:

The following parameters can be set in the status dictionary:

amplitude

pA

Amplitude of current

Examples:

SLI

The dc current can be altered in the following way:
/dc_generator Create /dc_gen Set  % Creates a dc_generator, which is a node
dc_gen GetStatus info             % View properties (amplitude is 0)
dc_gen << /amplitude 1500. >> SetStatus
dc_gen GetStatus info             % amplitude is now 1500.0

Remarks:

The dc_generator is rather inefficient, since it needs to send the same current information on each time step. If you only need a constant bias current into a neuron, you should set it directly in the neuron, e.g., dc_generator.

Sends: CurrentEvent

Author: docu by Sirko Straube

SeeAlso: Device, StimulatingDevice

class gamma_sup_generator : public DeviceNode
#include <gamma_sup_generator.h>

Name: gamma_sup_generator - simulate the superimposed spike train of a population of gamma process. Description:

The gamma_sup_generator generator simulates the pooled spike train of a population of neurons firing independently with gamma process statistics.

Parameters:

The following parameters appear in the element’s status dictionary:

rate

spikes/s

Mean firing rate of the component processes, default: 0 spikes/s

gamma_shape

integer

Shape paramter of component gamma processes, default: 1

n_proc

integer

Number of superimposed independent component processes, default: 1

References:

1

Deger, Helias, Boucsein, Rotter (2011). Statistical properties of superimposed stationary spike trains. Journal of Computational Neuroscience. DOI: https://doi.org/10.1007/s10827-011-0362-8

Author: Jan 2011, Moritz Deger

SeeAlso: ppd_sup_generator, poisson_generator_ps, spike_generator, Device, StimulatingDevice

class inhomogeneous_poisson_generator : public DeviceNode
#include <inhomogeneous_poisson_generator.h>

Name: inhomogeneous_poisson_generator - provides Poisson spike trains at a piecewise constant rate

Description: The inhomogeneous Poisson generator provides Poisson spike trains at a piecewise constant rate to the connected node(s). The rate of the process is changed at the specified times. The unit of the instantaneous rate is spikes/s. By default, each target of the generator will receive a different spike train.

Parameters: The following parameters can be set in the status dictionary:

rate_times

list of ms

Times at which rate changes

rate_values

list of spikes/s

Rate of Poisson spike train

allow_offgrid_times

boolean

If false, spike times will be rounded to the nearest step if they are less than tic/2 from the step, otherwise NEST reports an error. If true, spike times are rounded to the nearest step if within tic/2 from the step,otherwise they are rounded up to the end of the step. Default: false

Examples:

The rate can be altered in the following way:

/inhomogeneous_poisson_generator Create /sc Set
sc << /rate_times [0.2 0.5] /rate_values [2.0 4.0] >> SetStatus

The average firing rate of each realization of the Poisson process will be 0.0 in the time interval [0, 0.2), 2.0 in the interval [0.2, 0.5) and 4.0 from then on.

Receives: DataLoggingRequest

Sends: SpikeEvent

Authors: Renato Duarte, Barna Zajzon

SeeAlso: sinusoidal_poisson_generator, step_current_generator, Device, StimulatingDevice

class mip_generator : public DeviceNode
#include <mip_generator.h>

class mip_generator

Class mip_generator generates spike trains as described in the MIP model.

Name: mip_generator - create spike trains as described by the MIP model.

Description:

The mip_generator generates correlated spike trains using an Multiple Interaction Process (MIP) as described in [1]. Underlying principle is a Poisson mother process with rate r, the spikes of which are copied into the child processes with a certain probability p. Every node the mip_generator is connected to receives a distinct child process as input, whose rate is p*r. The value of the pairwise correlation coefficient of two child processes created by a MIP process equals p.

Parameters:

The following parameters appear in the element’s status dictionary:

rate

spikes/s

Mean firing rate of the mother process

p_copy

real

Copy probability

mother_rng

rng

Random number generator of mother process

mother_seed

integer

Seed of RNG of mother process

Remarks:

The MIP generator may emit more than one spike through a child process during a single time step, especially at high rates. If this happens, the generator does not actually send out n spikes. Instead, it emits a single spike with n-fold synaptic weight for the sake of efficiency. Furthermore, note that as with the Poisson generator, different threads have their own copy of a MIP generator. By using the same mother_seed it is ensured that the mother process is identical for each of the generators.

IMPORTANT: The mother_seed of mpi_generator must be different from any seeds used for the global or thread-specific RNGs set in the kernel.

Sends: SpikeEvent

References:

1

Kuhn A, Aertsen A, Rotter S (2003). Higher-order statistics of input ensembles and the response of simple model neurons. Neural Computation 15:67-101. DOI: https://doi.org/10.1162/089976603321043702

Author: May 2006, Helias

SeeAlso: Device

class multimeter : public DeviceNode
#include <multimeter.h>

Name: multimeter - Device to record analog data from neurons.

Synopsis: multimeter Create

Description:

A multimeter records a user-defined set of state variables from connected nodes to memory, file or stdout.

The multimeter must be configured with the list of variables to record from, otherwise it will not record anything. The /recordables property of a neuron model shows which quantities can be recorded with a multimeter. A single multimeter should only record from neurons of the same basic type (e.g. /iaf_cond_alpha and any user-defined models derived from it using CopyModel). If the defaults or status dictionary of a model neuron does not contain a /recordables entry, it is not ready for use with multimeter.

By default, multimeters record values once per ms. Set the parameter /interval to change this. The recording interval cannot be smaller than the resolution.

Results are returned in the /events entry of the status dictionary. For each recorded quantity, a vector of doubles is returned. The vector has the same name as the /recordable. If /withtime is set, times are given in the /times vector in /events.

Accumulator mode: A multimeter can operate in accumulator mode. In this case, values for all recorded variables are added across all recorded nodes (but kept separate in time). This can be useful to record average membrane potential in a population.

To activate accumulator mode, either set /to_accumulator to true, or set /record_to [ /accumulator ]. In accumulator mode, you cannot record to file, to memory, to screen, with GID or with weight. You must activate accumulator mode before simulating. Accumulator data is never written to file. You must extract it from the device using GetStatus.

Remarks:

  • The set of variables to record and the recording interval must be set BEFORE the multimeter is connected to any node, and cannot be changed afterwards.

  • A multimeter cannot be frozen.

  • If you record with multimeter in accumulator mode and some of the nodes you record from are frozen and others are not, data will only be collected from the unfrozen nodes. Most likely, this will lead to confusing results, so you should not use multimeter with frozen nodes.

Parameters:

Note

If you want to pick up values at every time stamp, you must set the interval to the simulation resolution.

See

UniversalDataLogger

The following parameters can be set in the status dictionary:

interval

ms

Recording interval

record_from

array

Array containing the names of variables to record from, obtained from the /recordables entry of the model from which one wants to record

Examples:

SLI ] /iaf_cond_alpha Create /n Set
SLI ] n /recordables get ==
[/V_m /g_ex /g_in /t_ref_remaining]
SLI ] /multimeter Create /mm Set
SLI ] mm << /interval 0.5 /record_from [/V_m /g_ex /g_in] >> SetStatus
SLI ] mm n Connect
SLI ] 10 Simulate
SLI ] mm /events get info
--------------------------------------------------
Name                     Type                Value
--------------------------------------------------
g_ex                     doublevectortype    <doublevectortype>
g_in                     doublevectortype    <doublevectortype>
senders                  intvectortype       <intvectortype>
times                    doublevectortype    <doublevectortype>
t_ref_remaining          doublevectortype    <doublevectortype>
V_m                      doublevectortype    <doublevectortype>
rate                     doublevectortype    <doublevectortype>
--------------------------------------------------
Total number of entries: 6

Sends: DataLoggingRequest

FirstVersion: 2009-04-01

Author: Hans Ekkehard Plesser, Barna Zajzon (added offset support March 2017)

SeeAlso: Device, RecordingDevice

Subclassed by nest::voltmeter

class music_cont_in_proxy : public DeviceNode
#include <music_cont_in_proxy.h>

Name: music_cont_in_proxy - A device which receives continuous data from MUSIC.

Description:

A music_cont_in_proxy can be used to receive continuous data from remote MUSIC applications in NEST.

It uses the MUSIC library to receive the data from other applications. The music_cont_in_proxy represents a complete port to which MUSIC can connect and send data. The music_cont_in_proxy can queried using GetStatus to retrieve the messages.

Parameters:

The following properties are available in the status dictionary:

port_name

string

The name of the MUSIC input port to listen to (default: cont_in)

port_width

integer

The width of the MUSIC input port

data

list

The data received on the port

published

boolean

A bool indicating if the port has been already published with MUSIC

The parameter port_name can be set using SetStatus.

Examples:

/music_cont_in_proxy Create /mcip Set
10 Simulate
mcip GetStatus /data get /gaze_directions Set

Author: Jochen Martin Eppler

FirstVersion: July 2010

Availability: Only when compiled with MUSIC

SeeAlso: music_event_out_proxy, music_event_in_proxy, music_message_in_proxy

class music_cont_out_proxy : public DeviceNode
#include <music_cont_out_proxy.h>

Name: music_cont_out_proxy - A device which sends continuous data from NEST to MUSIC.

Description:

A music_cont_out_proxy can be used to send continuous data from neurons over MUSIC to remote applications. It works in a similar fashion like the multimeter model. The user has to specify the recordable values to observe (e.g. [“V_m”]) via the record_from parameter. The target neurons are specified by a list of global neuron ids which must be passed via the “targets” parameter. The music_cont_out_proxy will be connected automatically to the specified target neurons. It is not possible to apply further changes to the list of target neurons or observed quantities once the simulation has been started for the first time.

In case of multiple recordables the data can be read out (PyNEST only) of the receiving buffer via the following access pattern:

buffer[ target_gid_index ][ recordable_index] = buffer[ target_gid_index *
record_from.size() + recordable_index ]

For example:
target_gids = [ 2, 5, 4 ], record_from = ["V_m"] and

we want to get "V_m" for neuron with GID 5: buffer[ 1*1 + 0 ]

Parameters:

The following properties are available in the status dictionary:

interval

ms

Recording interval

targets

array

Global id list of neurons to be observed

port_name

string

The name of the MUSIC input port to listen to (default: cont_in)

port_width

integer

The width of the MUSIC input port

published

boolean

A bool indicating if the port has been already published with MUSIC

record_from

array

Array containing the names of variables to record from, obtained from the /recordables entry of the model from which one wants to record

Author: Martin Asghar Schulze, Forschungszentrum fur Informatik Karlsruhe (FZI)

FirstVersion: March 2016

Availability: Only when compiled with MPI and MUSIC

SeeAlso: music_cont_in_proxy, music_event_out_proxy, music_event_in_proxy, music_message_in_proxy

class music_event_in_proxy : public DeviceNode
#include <music_event_in_proxy.h>

Name: music_event_in_proxy - A device which receives spikes from MUSIC.

Description:

A music_event_in_proxy can be used to pass spikes to nodes within NEST which are received from another application.

It uses the MUSIC library to receive spike events from other applications. The music_event_in_proxy represents one channel on a port to which MUSIC can connect an event source. The music_event_in_proxy can be connected to local neurons or devices within NEST to receive the events. Multiple music_in_proxies can be configured to listen on the same port, but each channel can only listened to by a single proxy.

Parameters:

The following properties are available in the status dictionary:

port_name

string

The name of the MUSIC input port to listen to (default: event_in)

music_channel

integer

The MUSIC global index on the input port to listen to

registered

boolean

A bool indicating if the port has been already registered with the corresponding MUSIC event handler

The parameters port_name and music_channel can be set using SetStatus. The acceptable latency of the MUSIC input port can be set using the command SetAcceptableLatency.

Examples:

/music_event_in_proxy Create /meip Set
meip << /music_channel 2 >> SetStatus
/iaf_psc_alpha Create /n Set
(event_in) 0.2 SetAcceptableLatency
meip n Connect

Author: Moritz Helias, Jochen Martin Eppler

FirstVersion: October 2008

Availability: Only when compiled with MUSIC

SeeAlso: SetAcceptableLatency, music_event_out_proxy, music_cont_in_proxy, music_message_in_proxy

class music_event_out_proxy : public DeviceNode
#include <music_event_out_proxy.h>

Name: music_event_out_proxy - Device to forward spikes to remote applications using MUSIC.

Description:

A music_event_out_proxy is used to send spikes to a remote application that also uses MUSIC.

The music_event_out_proxy represents a complete MUSIC event output port. The channel on the port to which a source node forwards its events is determined during connection setup by using the parameter music_channel of the connection. The name of the port is set via SetStatus (see Parameters section below).

Parameters:

The following properties are available in the status dictionary:

port_name

string

The name of the MUSIC output_port to forward events to (default: event_out)

port_width

integer

The width of the MUSIC input port

published

boolean

A bool indicating if the port has been already published with MUSIC

The parameter port_name can be set using SetStatus.

Examples:

/iaf_psc_alpha Create /n Set
/music_event_out_proxy Create /meop Set
n meop << /music_channel 2 >> Connect

Author: Moritz Helias, Jochen Martin Eppler

FirstVersion: March 2009

Availability: Only when compiled with MUSIC

SeeAlso: music_event_in_proxy, music_cont_in_proxy, music_message_in_proxy

class MsgHandler : public MessageHandler
#include <music_message_in_proxy.h>

Name: music_message_in_proxy - A device which receives message strings from MUSIC.

Description:

A music_message_in_proxy can be used to receive message strings from remote MUSIC applications in NEST.

It uses the MUSIC library to receive message strings from other applications. The music_message_in_proxy represents an input port to which MUSIC can connect a message source. The music_message_in_proxy can queried using GetStatus to retrieve the messages.

Parameters:

The following properties are available in the status dictionary:

port_name

string

The name of the MUSIC input port to listen to (default: message_in)

port_width

integer

The width of the MUSIC input port

data

array

A sub-dictionary that contains the string messages in the form of two arrays: messages - The strings message_times - The times the messages were sent (ms)

n_messages

integer

The number of messages

published

boolean

A bool indicating if the port has been already published with MUSIC

The parameter port_name can be set using SetStatus. The field n_messages can be set to 0 to clear the data arrays.

Examples:

/music_message_in_proxy Create /mmip Set
10 Simulate
mmip GetStatus /data get /messages get 0 get /command Set
(Executing command ') command join ('.) join =
command cvx exec

Author: Jochen Martin Eppler

FirstVersion: July 2010

Availability: Only when compiled with MUSIC

SeeAlso: music_event_out_proxy, music_event_in_proxy, music_cont_in_proxy

class noise_generator : public DeviceNode
#include <noise_generator.h>

Name: noise_generator - Device to generate Gaussian white noise current.

Description: This device can be used to inject a Gaussian “white” noise current into a node.

The current is not really white, but a piecewise constant current with Gaussian distributed amplitude. The current changes at intervals of dt. dt must be a multiple of the simulation step size, the default is 1.0ms, corresponding to a 1kHz cut-off. Additionally a second sinusodial modulated term can be added to the standard deviation of the noise.

The current generated is given by

\[\]

where \( N_j \) are Gaussian random numbers with unit standard deviation and \( t_0 \) is the device onset time. If the modulation is added the current is given by

\[\]
For a detailed discussion of the properties of the noise generator, please see the noise_generator.ipynb notebook included in the NEST source code (docs/model_details).

Parameters: The following parameters can be set in the status dictionary:

mean

pA

Mean value of the noise current

std

pA

Standard deviation of noise current

dt

ms

Interval between changes in current, default 1.0ms

std_mod

pA

Modulated standard deviation of noise current

phase

real

Phase of sine modulation (0-360 deg)

frequency

Hz

Frequency of sine modulation

Remarks:

  • All targets receive different currents.

  • The currents for all targets change at the same points in time.

  • The interval between changes, dt, must be a multiple of the time step.

  • The effect of this noise current on a neuron DEPENDS ON DT. Consider the membrane potential fluctuations evoked when a noise current is injected into a neuron. The standard deviation of these fluctuations across an ensemble will increase with dt for a given value of std. For the leaky integrate-and-fire neuron with time constant \( \tau_m \) and capacity \( C_m \), membrane potential fluctuations Sigma at time s \( t_j+delay \) are given by

    \[\]
    for large \( t_j \). In the white noise limit, dt -> 0, one has
    \[\]
    To obtain comparable results for different values of dt, you must adapt std.

  • As the noise generator provides a different current for each of its targets, the current recorded represents the instantaneous average of all the currents computed. When there exists only a single target, this would be equivalent to the actual current provided to that target.

Sends: CurrentEvent

SeeAlso: Device

Author: Ported to NEST2 API 08/2007 by Jochen Eppler, updated 07/2008 by HEP

class poisson_generator : public DeviceNode
#include <poisson_generator.h>

Name: poisson_generator - simulate neuron firing with Poisson processes statistics. Description:

The poisson_generator simulates a neuron that is firing with Poisson statistics, i.e. exponentially distributed interspike intervals. It will generate a unique spike train for each of it’s targets. If you do not want this behavior and need the same spike train for all targets, you have to use a parrot neuron inbetween the poisson generator and the targets.

Parameters:

The following parameters appear in the element’s status dictionary:

rate

spikes/s

Mean firing rate

origin

ms

Time origin for device timer

start

ms

Begin of device application with resp. to origin

stop

ms

End of device application with resp. to origin

Sends: SpikeEvent

Remarks:

A Poisson generator may, especially at high rates, emit more than one spike during a single time step. If this happens, the generator does not actually send out n spikes. Instead, it emits a single spike with n-fold synaptic weight for the sake of efficiency.

The design decision to implement the Poisson generator as a device which sends spikes to all connected nodes on every time step and then discards the spikes that should not have happened generating random numbers at the recipient side via an event hook is twofold.

On one hand, it leads to the saturation of the messaging network with an enormous amount of spikes, most of which will never get delivered and should not have been generated in the first place.

On the other hand, a proper implementation of the Poisson generator needs to provide two basic features: (a) generated spike trains should be IID processes w.r.t. target neurons to which the generator is connected and (b) as long as virtual_num_proc is constant, each neuron should receive an identical Poisson spike train in order to guarantee reproducibility of the simulations across varying machine numbers.

Therefore, first, as Network::get_network().send sends spikes to all the recipients, differentiation has to happen in the hook, second, the hook can use the RNG from the thread where the recipient neuron sits, which explains the current design of the generator. For details, refer to:

http://ken.brainworks.uni-freiburg.de/cgi-bin/mailman/private/nest_developer/2011-January/002977.html

SeeAlso: poisson_generator_ps, Device, parrot_neuron

class ppd_sup_generator : public DeviceNode
#include <ppd_sup_generator.h>

Name: ppd_sup_generator - simulate the superimposed spike train of a population of Poisson processes with dead time.

Description:

The ppd_sup_generator generator simulates the pooled spike train of a population of neurons firing independently with Poisson process with dead time statistics. The rate parameter can also be sine-modulated. The generator does not initialize to equilibrium in this case, initial transients might occur.

Parameters:

The following parameters appear in the element’s status dictionary:

rate

spikes/s

Mean firing rate of the component processes, default: 0 spikes/s

dead_time

ms

Minimal time between two spikes of the component processes, default: 0 ms

n_proc

integer

Number of superimposed independent component processes, default: 1

frequency

Hz

Rate modulation frequency, default: 0 Hz

relative_amplitude

real

Relative rate modulation amplitude, default: 0

Remarks:

References:

1

Deger M, Helias M, Boucsein C, Rotter S (2011). Statistical properties of superimposed stationary spike trains. Journal of Computational Neuroscience. DOI: https://doi.org/10.1007/s10827-011-0362-8

Authors: June 2009, Moritz Deger, Moritz Helias

SeeAlso: gamma_sup_generator, poisson_generator_ps, spike_generator, Device, StimulatingDevice

class pulsepacket_generator : public Node
#include <pulsepacket_generator.h>

Name: pulsepacket_generator - Generate sequence of Gaussian pulse packets.

Description:

The pulsepacket_generator produces a spike train contains Gaussian pulse packets centered about given times. A Gaussian pulse packet is a given number of spikes with normal distributed random displacements from the center time of the pulse. It resembles the output of synfire groups of neurons.

Parameters:

pulse_times

ms

Times of the centers of pulses

activity

integer

Number of spikes per pulse

sdev

ms

Standard deviation of spike times in each pulse

Remarks:

  • All targets receive identical spike trains.

  • New pulse packets are generated when activity or sdev are changed.

  • Gaussian pulse are independently generated for each given pulse-center time.

  • Both standard deviation and number of spikes may be set at any time. Pulses are then re-generated with the new values.

Sends: SpikeEvent

SeeAlso: spike_generator, StimulatingDevice

class sinusoidal_gamma_generator : public DeviceNode
#include <sinusoidal_gamma_generator.h>

Name: sinusoidal_gamma_generator - Generates sinusoidally modulated gamma spike trains.

Description:

sinusoidal_gamma_generator generates sinusoidally modulated gamma spike trains. By default, each target of the generator will receive a different spike train.

The instantaneous rate of the process is given by

\[\]

Parameters:

The following parameters can be set in the status dictionary:

rate

spikes/s

Mean firing rate, default: 0 spikes/s

amplitude

spikes/s

Firing rate modulation amplitude, default: 0 s^-1

frequency

Hz

Modulation frequency, default: 0 Hz

phase

real

Modulation phase in degree [0-360], default: 0

order

real

Gamma order (>= 1), default: 1

individual_spike_trains

boolean

See note below, default: true

Remarks:

  • The gamma generator requires 0 <= amplitude <= rate.

  • The state of the generator is reset on calibration.

  • The generator does not support precise spike timing.

  • You can use the multimeter to sample the rate of the generator.

  • The generator will create different trains if run at different temporal resolutions.

  • Individual spike trains vs single spike train: By default, the generator sends a different spike train to each of its targets. If /individual_spike_trains is set to false using either SetDefaults or CopyModel before a generator node is created, the generator will send the same spike train to all of its targets.

Receives: DataLoggingRequest

Sends: SpikeEvent

References:

1

Barbieri et al. (2001). Construction and analysis of non-Poisson stimulus-response models of neural spiking activity. Journal of Neuroscience Methods, 105:25-3. DOI: https://doi.org/10.1016/S0165-0270(00)00344-7

FirstVersion: October 2007, May 2013

Author: Hans E Plesser, Thomas Heiberg

SeeAlso: sinusoidal_poisson_generator, gamma_sup_generator AC Gamma Generator. Generates AC-modulated inhomogeneous gamma process.

Note

The simulator works by calculating the hazard h(t) for each time step and comparing h(t) dt to a [0,1)-uniform number. The hazard is given by

\[\]
with
\[\]
\[\]
and the incomplete Gamma function \( Gamma(a,z) \); \( a \) is the order of the gamma function and \(t_0\) the time of the most recent spike.

Note

This implementation includes an additional \( a \) factor in the calculation of \(\Lambda(t)\) and \(h(t)\) in order to keep the mean rate constant with varying \(a\)

Note

Let \(t_0\) be the time of the most recent spike. If stimulus parameters are changed at \(t_c > t_0\), then \(\Lambda(t)\) is integrated piecewise for \(t>t_c\) as

\[\]
where “old” and “new” indicate old an new parameter values, respectively.

class sinusoidal_poisson_generator : public DeviceNode
#include <sinusoidal_poisson_generator.h>

Name: sinusoidal_poisson_generator - Generates sinusoidally modulated Poisson spike trains.

Description:

sinusoidal_poisson_generator generates sinusoidally modulated Poisson spike trains. By default, each target of the generator will receive a different spike train.

The instantaneous rate of the process is given by

\[\]
Parameters:

The following parameters can be set in the status dictionary:

rate

real

Mean firing rate in spikes/second, default: 0 s^-1

amplitude

real

Firing rate modulation amplitude in spikes/second, default: 0 s^-1

frequency

Hz

Modulation frequency, default: 0 Hz

phase

real

Modulation phase in degree [0-360], default: 0

individual_spike_trains

boolean

See note below, default: true

Remarks:

  • If amplitude > rate, firing rate is cut off at zero. In this case, the mean firing rate will be less than rate.

  • The state of the generator is reset on calibration.

  • The generator does not support precise spike timing.

  • You can use the multimeter to sample the rate of the generator.

  • The generator will create different trains if run at different temporal resolutions.

  • Individual spike trains vs single spike train: By default, the generator sends a different spike train to each of its targets. If /individual_spike_trains is set to false using either SetDefaults or CopyModel before a generator node is created, the generator will send the same spike train to all of its targets.

Receives: DataLoggingRequest

Sends: SpikeEvent

FirstVersion: July 2006, Oct 2009, May 2013

Author: Hans Ekkehard Plesser

SeeAlso: poisson_generator, sinusoidal_gamma_generator

class spike_detector : public DeviceNode
#include <spike_detector.h>

Name: spike_detector - Device for detecting single spikes.

Description:

The spike_detector device is a recording device. It is used to record spikes from a single neuron, or from multiple neurons at once. Data is recorded in memory or to file as for all RecordingDevices. By default, GID and time of each spike is recorded.

The spike detector can also record spike times with full precision from neurons emitting precisely timed spikes. Set /precise_times to achieve this. If there are precise models and /precise_times is not set, it will be set to True at the start of the simulation and /precision will be increased to 15 from its default value of 3.

Any node from which spikes are to be recorded, must be connected to the spike detector using a normal connect command. Any connection weight and delay will be ignored for that connection.

Simulations progress in cycles defined by the minimum delay. During each cycle, the spike detector records (stores in memory or writes to screen/file) the spikes generated during the previous cycle. As a consequence, any spikes generated during the cycle immediately preceding the end of the simulation time will not be recorded. Setting the /stop parameter to at the latest one min_delay period before the end of the simulation time ensures that all spikes desired to be recorded, are recorded.

Spike are not necessarily written to file in chronological order.

Note:

Spikes are buffered in a two-segment buffer. We need to distinguish between two types of spikes: those delivered from the global event queue (almost all spikes) and spikes delivered locally from devices that are replicated on VPs (has_proxies() == false).

  • Spikes from the global queue are delivered by deliver_events() at the beginning of each update cycle and are stored only until update() is called during the same update cycle. Global queue spikes are thus written to the read_toggle() segment of the buffer, from which update() reads.

  • Spikes delivered locally may be delivered before or after spike_detector::update() is executed. These spikes are therefore buffered in the write_toggle() segment of the buffer and output during the next cycle.

  • After all spikes are recorded, update() clears the read_toggle() segment of the buffer.

Receives: SpikeEvent

SeeAlso: spike_detector, Device, RecordingDevice

class spike_dilutor : public DeviceNode
#include <spike_dilutor.h>

Name: spike_dilutor - repeats incoming spikes with a certain probability.

Description:

The device repeats incoming spikes with a certain probability. Targets will receive diffenrent spike trains.

Remarks:

In parallel simulations, a copy of the device is present on each process and spikes are collected only from local sources.

Parameters:

The following parameters appear in the element’s status dictionary:

p_copy

real

Copy probability

Sends: SpikeEvent

Author: Adapted from mip_generator by Kunkel, Oct 2011 ported to Nest 2.6 by: Setareh, April 2015

SeeAlso: mip_generator

class spike_generator : public DeviceNode
#include <spike_generator.h>

Name: spike_generator - A device which generates spikes from an array with spike-times.

Synopsis: spike_generator Create -> gid

Description:

A spike generator can be used to generate spikes at specific times which are given to the spike generator as an array.

Spike times are given in milliseconds, and must be sorted with the earliest spike first. All spike times must be strictly in the future. Trying to set a spike time in the past or at the current time step, will cause a NEST error. Setting a spike time of 0.0 will also result in an error.

Spike times may not coincide with a time step, i.e., are not a multiple of the simulation resolution. Three options control how spike times that do not coincide with a step are handled (see examples below):

Multiple occurrences of the same time indicate that more than one event is to be generated at this particular time.

Additionally, spike_weights can be set. This also is an array, which contains one weight value per spike time. If set, the spikes are delivered with the respective weight multiplied with the weight of the connection. To disable this functionality, the spike_weights array can be set to an empty array.

/precise_times   default: false

If false, spike times will be rounded to simulation steps, i.e., multiples of the resolution. The rounding is controlled by the two other flags. If true, spike times will not be rounded but represented exactly as a combination of step and offset. This should only be used if all neurons receiving the spike train can handle precise timing information. In this case, the other two options are ignored.

/allow_offgrid_times   default: false

If false, spike times will be rounded to the nearest step if they are less than tic/2 from the step, otherwise NEST reports an error. If true, spike times are rounded to the nearest step if within tic/2 from the step, otherwise they are rounded up to the end of the step.

/shift_now_spikes   default: false

This option is mainly for use by the PyNN-NEST interface. If false, spike times rounded down to the current point in time will be considered in the past and ignored. If true, spike times that are rounded down to the current time step are shifted one time step into the future.

Note that GetStatus will report the spike times that the spike_generator will actually use, i.e., for grid-based simulation the spike times rounded to the appropriate point on the time grid. This means that GetStatus may return different /spike_times values at different resolutions.

Example:

spike_generator << /spike_times [1.0 2.0 3.0] >> SetStatus

Instructs the spike generator to generate events at 1.0, 2.0, and
3.0 milliseconds, relative to the device-timer origin.

Example:

Assume that NEST works with default resolution (step size) of 0.1ms and default tic length of 0.001ms. Then, spikes times not falling onto the grid will be handled as follows for different option settings:

/spike_generator << /spike_times [1.0 1.9999 3.0001] >> Create
---> spikes at steps 10 (==1.0ms), 20 (==2.0ms) and 30 (==3.0ms)

/spike_generator << /spike_times [1.0 1.05 3.0001] >> Create
---> error, spike time 1.05 not within tic/2 of step

/spike_generator << /spike_times [1.0 1.05 3.0001]
                    /allow_offgrid_times true >> Create
---> spikes at steps 10, 11 (mid-step time rounded up),
     30 (time within tic/2 of step moved to step)

/spike_generator << /spike_times [1.0 1.05 3.0001]
                    /precise_times true >> Create
---> spikes at step 10, offset 0.0; step 11, offset -0.05;
     step 31, offset -0.0999

Assume we have simulated 10.0ms and simulation times is thus 10.0 (step 100).
Then, any spike times set, at this time, must be later than step 100.

/spike_generator << /spike_times [10.0001] >> Create
---> spike time is within tic/2 of step 100, rounded down to 100 thus
     not in the future, spike will not be emitted

/spike_generator << /spike_times [10.0001] /precise_times true >> Create
---> spike at step 101, offset -0.0999 is in the future

/spike_generator
  << /spike_times [10.0001 11.0001] /shift_now_spikes true >>
Create
---> spike at step 101, spike shifted into the future, and spike at step 110,
     not shifted, since it is in the future anyways

Example:

spike_generator
  << /spike_times [1.0 2.0] /spike_weights [5.0 -8.0] >>
SetStatus

Instructs the spike generator to generate an event with weight 5.0
at 1.0 ms, and an event with weight -8.0 at 2.0 ms, relative to
the device-timer origin.

spike_generator << /spike_weights [] >> SetStatus

Instructs the spike generator to generate events at 1.0, 2.0, and
3.0 milliseconds, and use the weight of the connection.

Parameters: The following properties can be set in the status dictionary.

origin

ms

Time origin for device timer

start

ms

Earliest possible time stamp of a spike to be emitted

stop

ms

Earliest time stamp of a potential spike event that is not emitted

spike_times

ms

Spike-times

spike_weights

synaptic weights

Corresponding spike-weights, the unit depends on the receiver

spike_multiplicities

integer

Multiplicities of spikes, same length as spike_times; mostly for debugging

precise_times

boolean

see above

allow_offgrid_times

boolean

see above

shift_now_spikes

boolean

see above

Sends: SpikeEvent

Author: Gewaltig, Diesmann, Eppler

SeeAlso: Device, StimulatingDevice, testsuite::test_spike_generator

class spin_detector : public DeviceNode
#include <spin_detector.h>

Name: spin_detector - Device for detecting binary states in neurons.

Description:

The spin_detector is a recording device. It is used to decode and record binary states from spiking activity from a single neuron, or from multiple neurons at once. A single spike signals the 0 state, two spikes at the same time signal the 1 state. If a neuron is in the 0 or 1 state and emits the spiking activity corresponding to the same state, the same state is recorded again. Therefore, it is not only the transitions that are recorded. Data is recorded in memory or to file as for all RecordingDevices. By default, GID, time, and binary state (0 or 1) for each decoded state is recorded. The state can be accessed from [‘events’][‘weight’].

The spin_detector can also record binary state times with full precision from neurons emitting precisely timed spikes. Set /precise_times to true to achieve this. If there are precise models and /precise_times is not set, it will be set to True at the start of the simulation and /precision will be increased to 15 from its default value of 3.

Any node from which binary states are to be recorded, must be connected to the spin_detector using the Connect command. Any connection weight and delay will be ignored for that connection.

Simulations progress in cycles defined by the minimum delay. During each cycle, the spin_detector records (stores in memory or writes to screen/file) the states during the previous cycle. As a consequence, any state information that was decoded during the cycle immediately preceding the end of the simulation time will not be recorded. Setting the /stop parameter to at the latest one min_delay period before the end of the simulation time ensures that all binary states desired to be recorded, are recorded.

states are not necessarily written to file in chronological order.

Receives: SpikeEvent

SeeAlso: spike_detector, Device, RecordingDevice Spin detector class.

This class decodes binary states based on incoming spikes. It receives spikes via its handle(SpikeEvent&) method, decodes the state, and stores them via its RecordingDevice in the update() method.

Spikes are buffered in a two-segment buffer. We need to distinguish between two types of spikes: those delivered from the global event queue (almost all spikes) and spikes delivered locally from devices that are replicated on VPs (has_proxies() == false).

  • Spikes from the global queue are delivered by deliver_events() at the beginning of each update cycle and are stored only until update() is called during the same update cycle. Global queue spikes are thus written to the read_toggle() segment of the buffer, from which update() reads.

  • Spikes delivered locally may be delivered before or after spin_detector::update() is executed. These spikes are therefore buffered in the write_toggle() segment of the buffer and output during the next cycle.

  • After all spikes are recieved and states are decoded, update() clears the read_toggle() segment of the buffer.

class step_current_generator : public DeviceNode
#include <step_current_generator.h>

Name: step_current_generator - provides a piecewise constant DC input current

Description:

The dc_generator provides a piecewise constant DC input to the connected node(s). The amplitude of the current is changed at the specified times. The unit of the current is pA.

Parameters:

The following parameters can be set in the status dictionary:

amplitude_times

list of ms

Times at which current changes

amplitude_values

list of pA

Amplitudes of step current current

allow_offgrid_times

boolean

Default false

If false, times will be rounded to the nearest step if they are less than tic/2 from the step, otherwise NEST reports an error. If true, times are rounded to the nearest step if within tic/2 from the step, otherwise they are rounded up to the end of the step.

Note:

Times of amplitude changes must be strictly increasing after conversion to simulation time steps. The option allow_offgrid_times may be useful, e.g., if you are using randomized times for current changes which typically would not fall onto simulation time steps.

Examples:

The current can be altered in the following way:

/step_current_generator Create /sc Set
sc << /amplitude_times [0.2 0.5] /amplitude_values [2.0 4.0] >> SetStatus

The amplitude of the DC will be 0.0 pA in the time interval [0, 0.2),
2.0 pA in the interval [0.2, 0.5) and 4.0 from then on.

Sends: CurrentEvent

Author: Jochen Martin Eppler, Jens Kremkow

SeeAlso: ac_generator, dc_generator, step_current_generator, Device, StimulatingDevice

class step_rate_generator : public DeviceNode
#include <step_rate_generator.h>

Name: step_rate_generator - provides a piecewise constant input rate

Description:

The rate_generator provides a piecewise constant rate input to the connected rate unit(s). Please note that this input is handled in the same way as input from any other rate unit, i.e. it is processed by the input function of the receiving rate unit. The amplitude of the rate is changed at the specified times. The unit of the rate is Hz.

Parameters:

The following parameters can be set in the status dictionary:

amplitude_times

list of ms

Times at which current changes

amplitude_values

list of pA

Amplitudes of step current current

allow_offgrid_times

boolean

Default false

If false, times will be rounded to the nearest step if they are less than tic/2 from the step, otherwise NEST reports an error. If true, times are rounded to the nearest step if within tic/2 from the step, otherwise they are rounded up to the end of the step.

Note:

Times of amplitude changes must be strictly increasing after conversion to simulation time steps. The option allow_offgrid_times may be useful, e.g., if you are using randomized times for rate changes which typically would not fall onto simulation time steps.

Examples:

The rate can be altered in the following way:

/step_rate_generator Create /sc Set sc << /amplitude_times [0.2 0.5] /amplitude_values [2.0 4.0] >> SetStatus

The amplitude of the rate will be 0.0 Hz in the time interval [0, 0.2), 2.0 Hz in the interval [0.2, 0.5) and 4.0 Hz from then on.

Sends: DelayedRateConnectionEvent

Author: Sandra Nestler, David Dahmen

SeeAlso: step_current_generator, Device, StimulatingDevice

class weight_recorder : public DeviceNode
#include <weight_recorder.h>

Name: weight_recorder - Device for detecting single spikes.

Description:

The weight_recorder device is a recording device. It is used to record weights from synapses. Data is recorded in memory or to file as for all RecordingDevices. By default, source GID, target GID, time and weight of each spike is recorded.

In order to record only from a subset of connected synapses, the weight_recorder accepts the parameters ‘senders’ and ‘targets’, with which the recorded data is limited to the synapses with the corresponding source or target gid.

The weight recorder can also record weights with full precision from neurons emitting precisely timed spikes. Set /precise_times to achieve this.

Data is not necessarily written to file in chronological order.

Receives: WeightRecordingEvent

SeeAlso: weight_recorder, spike_detector, Device, RecordingDevice