Support NetPyNE model specification about hnn-core HOT 7 OPEN

I would start with a WIP pull request that makes netpyne an optional dependency (nested import) and shows how you can obtain the same result (with a test).

However, even before spending too much time doing this, I would suggest writing an example. How do you expect the user to interact with these new capabilities? If they change the network, in what ways would they do it in the context of EEG/MEG signals?

from hnn-core.

This is more work than I plan on undertaking. Instead, I may first adopt some of the changes in PR #55 into the NetPyNE branch above.

If they change the network, in what ways would they do it in the context of EEG/MEG signals?

1. performance: it would allow for reconfiguration of the network (e.g. synaptic weights) without tearing it down (necessary to avoid memory leaks) and rebuilding it
2. it helps the HNN project goals by inferring a mechanistic understanding of EEG/MEG signals, not limited by the static network configuration used in HNN (and mne-python)

from hnn-core.

Oops, I meant mne-neuron instead of mne-python ^^

from hnn-core.

okay netpyne adoption is in my mental roadmap :) However, I don't want to rush it. Since the HNN code base is small it allows me to iterate fast, try things and learn more about Neuron. Adding a minimal GUI would not be that difficult (hopefully) once the code is a bit settled. In the meanwhile, I am hoping netpyne codebase improves a bit in terms of documentation / API etc. so one doesn't have to spend hours figuring out details of how it works.

from hnn-core.

Example of how this could look:
#93

This hides Neuron stuff inside of netpyne. Everything in hnn-core can be pickled, which makes it easier for joblibs and MPI to coexist.

Now network.py and cell.py just define the netpyne specification (not object-oriented) which is passed into netpyne. Work remains to make this more readable, and there are some questions about hard-coded values.

Note, several organizational splits:

1. Moved spiking functions out of Net and into their own class Spike
2. Moved simulation functions into simulation.py. These basically call netpyne simulation functions.
3. MPI features/complexity in mpi.py. This is for advanced use cases on cluster compute systems.

from hnn-core.

maybe we need a netpyne coding sprint to understand and improve netpyne ... :)

from hnn-core.

True. I think that'd be very helpful...

from hnn-core.