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

Implementation on NESTML of a customized Volume Transmitter #1090

Open
Geenetto opened this issue Jul 22, 2024 · 7 comments
Open

Implementation on NESTML of a customized Volume Transmitter #1090

Geenetto opened this issue Jul 22, 2024 · 7 comments

Comments

@Geenetto
Copy link

Hi!
I need to implement a customized version of volume transmitter for specific connection rules I am working on.
Hence, I am pulling this issue to ask whether is possible to generate such model via NESTML and if you have some examples about it.

Thanks in advance for your availability :)

Have a nice day,
Emiliano

@clinssen
Copy link
Contributor

Hi, thanks for writing in! What is the kind of customisation to the volume transmitter that you would need? In NEST, the vt is only responsible for routing spikes; rather than customising the vt itself, could your custom rule be instead expressed in terms of the response of the synapse to the spike?

I trust you have already taken a look at the STDP-dopa tutorial https://nestml.readthedocs.io/en/latest/tutorials/stdp_dopa_synapse/stdp_dopa_synapse.html

@Geenetto
Copy link
Author

Yes, I have already taken a look at the STDP-dopa tutorial.

The volume transmitter that I want to implement, compared to the one implemented on NEST, makes use of the nodes' ID in order to send the neuromodulating signal to specific nodes, not to all nodes simultaneously.
Additionally, here I attach two images to explain what I want to implement:

This scheme is the NEST volume transmitter:
vt_NEST

This is what I want to implement:
vt_custom

Also, considering the differences, I want to avoid thee XY problem.

Last, but not least, I am tagging @alberto-antonietti , the person who made the model and I am working with.
In this way, for any major question, he can step in this conversation.

I hope this message explains my issue.

Have a good day,
Emiliano

@clinssen
Copy link
Contributor

Could you please clarify what, in the second diagram, POST is doing at/with the black line that passes through it? A mathematical or pseudocode formulation of the model could help.

@alberto-antonietti
Copy link

Hi Charl,

I am jumping in, here is the kind of rule we want to implement.

nest.Connect(pre_neuron, post_neuron, conn_spec=`one_to_one`, syn_spec=`our_stdp_rule`)

How the rule work:

if pre_spike (normal spike):
    update weight (e.g., LTP, weight += LTP_amount
if mod_spike (modulatory spike):
   update weight (e.g., LTD, convolve past pre_spikes with a custom kernel and then weight -= LTD_amout)

In a way, as in the standard STDP, we want to activate the update weight when POST receives a pre_spike (port 0).
Differently from the standard STDP, we want to activate the update weight when POST receives (from a different connection) a mod_spike (port 1). While in the standard STDP it is the post_spike itself that triggers the update.

In the second drawing, the spike received by POST on port 1 has to trigger an update_weight on the synapse(s) on port 0.

Please let me know if this is not clear, I will try to express it better :-)

@alberto-antonietti
Copy link

A possible workaround is to make POST fire every time a mod spike is received (then a post_spike is generated and triggers the update of the weight on the incoming synapses), but we wanted to avoid this to make the mechanisms more general.

@clinssen
Copy link
Contributor

Thanks for the explanation! Can the weight update then not be triggerd by statements in the onReceive(mod_spikes) block? Basically to write the NESTML model as you did in your pseudocode. Would this not work out of the box?

@alberto-antonietti
Copy link

The tricky thing is that the mod_spike does not travel through that synapse (pre->post) but through another one (mod->post). Do you see a simple way to implement this?

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

3 participants