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

Issue when setting delay=0 to NetCon and multiple cores #17

Open
danilobenozzo opened this issue Jul 20, 2024 · 3 comments
Open

Issue when setting delay=0 to NetCon and multiple cores #17

danilobenozzo opened this issue Jul 20, 2024 · 3 comments

Comments

@danilobenozzo
Copy link
Contributor

https://github.com/dbbs-lab/bsb-neuron/blob/fc35e97006692c2e3aa1a570ce49b01c28d29b6d/bsb_neuron/connection.py#L30C5-L30C49
I think this overwrites the default values that were initialized here https://github.com/dbbs-lab/patch/blob/4d7442f726a556d28a7b72629baf3d427fac6568/patch/interpreter.py#L134 placing the NetCon.
A delay by default equals to 0 will give this NEURON error: usable mindelay is 0 (or less than dt for fixed step method) when running in parallel.
Probably better to keep the same default values as in patch/interpreter.py ?

@Helveg
Copy link
Contributor

Helveg commented Jul 20, 2024

Yes, a higher default would be better. It may even be best to make it a required argument without a default at all? Or default value None so that it indeed uses the nrn-patch default values.

@danilobenozzo
Copy link
Contributor Author

In the case of a transmitter sending to multiple receivers delay and weight cannot be receiver specific because they refer to the NetCon which is in the transmitter, right? So making them required arguments might be misleading for the user.
I prefer default value None so that the nrn-patch values are used, but should a is None check be added in patch.interpreter.ParallelCon()? As it is now, I think it will assign None

@Helveg
Copy link
Contributor

Helveg commented Jul 25, 2024

In the case of a transmitter sending to multiple receivers delay and weight cannot be receiver specific because they refer to the NetCon which is in the transmitter, right?

Hmm, indeed ... but that would mean that if you have a connection from section A to B and section A to C that they can not have different delays. That seems like an impossible restriction for NEURON, especially when you know that in NEURON 99.9% of users have strictly 1 NetCon on the soma of each cell. There must/might be a workaround. Maybe:

  • We can register a delay on the receiving side, somewhere in the NEURON calls that ParallelCon makes?
  • We can register 2 different GIDs to the same NetCon, with different delays?

Otherwise, ask the NEURON devs how to deal with the situation where 2 different delayed spike signals need to be emitted from the same Section.


Once you know more, it will become clear what the best solution is :)

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

2 participants