Detector/Recorder devices

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

\[ n*\delta_\tau - \tau_{max} - \delta_\tau/2 \]
\[ n*\delta_\tau - \tau_{max} + \delta_\tau/2 \]

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 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: 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

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 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 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