Skip to content
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

Nest Tsodyks2_synapse and Tsodyks_synapse - raises an error and sets up tau_psc inconsistently #810

Open
hamanpa opened this issue Dec 9, 2024 · 0 comments

Comments

@hamanpa
Copy link

hamanpa commented Dec 9, 2024

Issues:

  1. Class Projection has two methods _connect and _convergent_connect which behave inconsistently when using native_synapse_type with tsodyks_synapse - the former ignores any provided tau_psc, the latter respects the provided tau_psc
  2. Using native_synapse_type with tsodyks2_synapse leads to an error due to PyNN trying to provide tau_psc

(I kept them together as the issues seem connected)

Description - Issue 1

Nest provides two implementations of Tsodyks-Markram synapse:

Using a synapse model like

syn_pars = {'tau_psc': 20, 'U': 0.75, 'delay': 1.0, 'tau_fac': 0.0, 'tau_rec': 1., 'weight': 20.0}
synapse = sim.native_synapse_type('tsodyks_synapse')(**syn_pars)

with syn_pars dictionary containing tau_psc key, may lead to two results depending on the connector used later - either tau_psc in the synapse is the one provided in syn_pars or it is set to synaptic time constant.

If the connector calls method Projection._connect, PyNN checks the synaptic time constant and sets up tau_psc accordingly and creates the connections.

If the connector calls method Projection._convergent_connect, PyNN will use the provided tau_psc value, if given. The method works roughly as follows:

  1. it is issued with dictionary connection_parameters where the tau_psc from syn_pars is stored
  2. PyNN creates a dictionary syn_dict which is updated and will be used as a basis for creating connections and synapses
  3. PyNN checks whether the synapse is Tsodyks type, if so, it will update syn_dict with tau_psc based on the synaptic time constant (so now, there are two tau_psc values, one in syn_dict and one in connection_parameters)
  4. PyNN creates another dictionary _common_synapse_property_names which consist technical identifiers
  5. PyNN initializes connections with paremteres from syn_dict
  6. PyNN changes the parameters of synapses based on the values in connection_parameters (i.e. changing tau_psc to one provided in step 1.)

So PyNN behavior is (for tsodyks_synapse)

  1. _connect:
    1. use tau_psc based on synaptic time constant regardless tau_psc was provided or not
  2. _convergent_connect:
    1. if tau_psc is provided, it will be used (as it is done in step 6.)
    2. if it is not provided, it will use synaptic time constant (as it is initialized in 3.)

Issue 2

This also explains the error for tsodyks2_synapse:
seting up synapse model as tsodyks2_synapse, PyNN loads tau_psc from synaptic time constant in step 3. and then tries to create the connection. That raises NESTError because nest does not expect tau_psc for tsodyks2_synapse model.

This seems it could be resolved by modifying the if conditions

Minimal code raising the error

import pyNN.nest as sim

sim.setup(timestep=0.1)
syn_pars = {'U': 0.75, 'delay': 1.0, 'tau_fac': 0.0, 'tau_rec': 1., 'weight': 20.0}
synapse = sim.native_synapse_type('tsodyks2_synapse')(**syn_pars)
neuron1 = sim.Population(1, sim.EIF_cond_exp_isfa_ista())
neuron2 = sim.Population(1, sim.EIF_cond_exp_isfa_ista())
connector = sim.AllToAllConnector()
projection = sim.Projection(neuron1, neuron2, connector, synapse_type=synapse, receptor_type='excitatory')

gives

ConnectionError: DictError in SLI function Connect_g_g_D_D: Unused dictionary items: tau_psc. presynaptic_cells=NodeCollection(metadata=None, model=aeif_cond_exp, size=1, first=3), postsynaptic_cell=6, weights=20.0, delays=1.0, synapse model='tsodyks2_synapse_lbl'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant