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

simplify process for initializing cell-to-cell connections #129

Closed
rythorpe opened this issue Jul 30, 2020 · 6 comments · Fixed by #164
Closed

simplify process for initializing cell-to-cell connections #129

rythorpe opened this issue Jul 30, 2020 · 6 comments · Fixed by #164
Labels
maint This issue or pull request already exists refactor

Comments

@rythorpe
Copy link
Contributor

Currently, various functions and wrappers are involved in allowing a NeuronNetwork instance to establish cell-to-cell (i.e., local network and feed) connections:

  1. NeuronNetwork()._build() calls _parnet_connect()

  2. NeuronNetwork()._parnet_connect() then calls parconnect(), parreceive(), and parconnect_ext() within one of the child cell classes (e.g., Pyramidal).

  3. Pyramidal().parconnect() then calls Pyramidal._connect() and Pyramidal().parreceive() and Pyramidal().parconnect_ext() calls Pyramidal()._parconnect_from_src() (all of which are inherited from the parent _Cell class). (Same for the basket cell class.)

  4. Finally, _PC.gid_connect() is called from the Pyramidal()._parconnect_from_src() which is the lowest common python element in establishing a cell-to-cell connection.

It would be nice to rearrange and simply this process so that it is more transparent to Network how and when network connections are made. Ideally, there would be a single function, a method in _Cell, that Network could call in order to create a given cell-to-cell connection.

@rythorpe rythorpe added the maint This issue or pull request already exists label Jul 30, 2020
@jasmainak
Copy link
Collaborator

jasmainak commented Jul 30, 2020

I would love to discuss this. +100, I literally had the same issue the other day wrapping my head around these methods

@blakecaldwell
Copy link
Member

Agreed! The reason that it was moved out of Network was because it used _PC. However, moving to _Cell with a from .neuron import _PC inside the function sounds great.

@rythorpe
Copy link
Contributor Author

Agreed! The reason that it was moved out of Network was because it used _PC. However, moving to _Cell with a from .neuron import _PC inside the function sounds great.

I think it's a great policy to keep all hoc references out of Network - good call @blakecaldwell. We should definitely try to maintain this moving forward. Should we anticipate encountering any pickling or parallelization errors by moving this _PC reference to _Cell?

@blakecaldwell
Copy link
Member

Should we anticipate encountering any pickling or parallelization errors by moving this _PC reference to _Cell?

We should be fine. _PC is already imported in cell.py and existing functions heavily rely on h. objects.

@jasmainak
Copy link
Collaborator

is there still stuff to do here after #164 ?

@rythorpe rythorpe linked a pull request Sep 13, 2020 that will close this issue
2 tasks
@rythorpe
Copy link
Contributor Author

is there still stuff to do here after #164 ?

Nope, I think you covered it! Thanks @jasmainak!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maint This issue or pull request already exists refactor
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants