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

heterogeneous delays #109

Open
wxie2013 opened this issue May 5, 2020 · 8 comments
Open

heterogeneous delays #109

wxie2013 opened this issue May 5, 2020 · 8 comments

Comments

@wxie2013
Copy link

wxie2013 commented May 5, 2020

The recent versions of GeNN support heterogeneous delays. Is it possible to implement the heterogeneous delays in the interface? Thanks

@mstimberg
Copy link
Member

@tnowotny, @neworderofjamie: it seems that GeNN supports heterogeneous delays since version 3.2, but after a quick look at the documentation, I did not immediately see how to specify them. If it is straightforward, it would be great to support the feature in Brian2GeNN.

@neworderofjamie
Copy link
Collaborator

neworderofjamie commented May 6, 2020

So, on the GeNN side you use heterogeneous delays by modifying your weight update model e.g.

class StaticPulseDendriticDelay : public Base
{
public:
    DECLARE_WEIGHT_UPDATE_MODEL(StaticPulseDendriticDelay, 0, 2, 0, 0);

    SET_VARS({{"g", "scalar", VarAccess::READ_ONLY}, {"d", "uint8_t", VarAccess::READ_ONLY}});

    SET_SIM_CODE("$(addToInSynDelay, $(g), $(d));\n");
};

However, they are dendritic delays unlike the standard delays in GeNN which are axonal. This is irrelevant if they are used on static connections but, they don't necessarily play well with STDP as back-propogating postsynaptic spikes can't be delayed heterogeneosuly to match (if that makes sense)

@mstimberg
Copy link
Member

Thanks for the info @neworderofjamie . I'll have to think about this a bit more. Delays in Brian are always axonal at the moment, so there's no way to express the difference (i.e. to raise an error if the user provides axonal delays and ask them to specify dendritic delays instead). But just by checking what kind of variables are used in the statements we should be able to allow it whenever it does not matter.

@tnowotny
Copy link
Contributor

tnowotny commented Apr 1, 2021

This issue could be looked at in GSoC 2021 I think.

@wxie2013
Copy link
Author

wxie2013 commented May 13, 2022

So, on the GeNN side you use heterogeneous delays by modifying your weight update model e.g.

class StaticPulseDendriticDelay : public Base
{
public:
    DECLARE_WEIGHT_UPDATE_MODEL(StaticPulseDendriticDelay, 0, 2, 0, 0);

    SET_VARS({{"g", "scalar", VarAccess::READ_ONLY}, {"d", "uint8_t", VarAccess::READ_ONLY}});

    SET_SIM_CODE("$(addToInSynDelay, $(g), $(d));\n");
};

However, they are dendritic delays unlike the standard delays in GeNN which are axonal. This is irrelevant if they are used on static connections but, they don't necessarily play well with STDP as back-propogating postsynaptic spikes can't be delayed heterogeneosuly to match (if that makes sense)

Does it mean the standard delays in GeNN are axonal, but for heterogeneous delays, one has to use dendritic delay?

@tnowotny
Copy link
Contributor

yes, exactly. The axonal ones are homogeneous and defined in the add_synapse_population command, the dendritic ones as described by Jamie above.

@wxie2013
Copy link
Author

wxie2013 commented May 13, 2022

Thanks. It is correct that to implement heterogeneous delays in brian2genn, one need to update GeNN to have this function first? If this is correct, would you please provide some hints which part of the code in GeNN to start to work on this update in GeNN?

@neworderofjamie
Copy link
Collaborator

As an initial step, you could implement heterogeneous delays on static synapses without making any changes to GeNN by extending Brian2GeNN to genetate the code I pasted earlier (which I think would already be a big step forward).

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

No branches or pull requests

4 participants