jonescompneurolab / hnn-core Goto Github PK

Enable users to run a non-interactive batch of simulations of the HNN model by specifying a set of parameters values to use. This could be used for sweeping a range of parameter values (e.g. optimization), a list of specific parameter files to iterate over, and/or a distribution to draw from in choosing parameter values (e.g. priors for SNPE).

This will be a new interface for running simulations via hnn_core.simulator with the parameters to use specified as input and the results retrievable by their respective Python objects, and optionally saving the results/parameter files to disk.

Investigate what can be learned from how it is done in scipy and NetPyNE batch simulations.

So when trying to run Sphinx Gallery I get an error that is easy to understand. However, I feel that I'm probably missing something in your workflow rather than touch examples/README.txt. Could you include more verbose instructions in CONTRIBUTING?

(hnn) Blakes-MacBook-Pro:doc blake$ make html
sphinx-build -b html -d _build/doctrees   . _build/html
Running Sphinx v2.1.1
making output directory... done
generating gallery...

Exception occurred:
  File "/Users/blake/miniconda3/envs/hnn/lib/python3.6/site-packages/sphinx_gallery/gen_gallery.py", line 262, in generate_gallery_rst
    .format(examples_dir))
FileNotFoundError: Main example directory /Users/blake/repos/mne-neuron-new/doc/../examples does not have a README.txt file. Please write one to introduce your gallery.
The full traceback has been saved in /var/folders/zq/5r57yxls19q2wcq98g5r4gb40000gn/T/sphinx-err-ikb8ajow.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
make: *** [html] Error 2

I believe this example is not totally accurate: https://jonescompneurolab.github.io/hnn-core/auto_examples/plot_firing_pattern.html#sphx-glr-auto-examples-plot-firing-pattern-py.

It plots the somatic voltage you observe in the network when giving an input current to the individual cells. What we want is to plot the somatic voltages of any cell during the simulation of the entire network

I'll make a PR later in the evening

... and no intermediate text files

• custom mechanisms should be build during install time
• requirements should be added to the install script or as a requirements.txt file

The code for MPIBackend in #79 waits for the subprocess to complete after all trials have run before printing progress messages to the screen. This was done for simplicity as interactively communicating the stdout from the child process while the job is running will require some handling using select in parallel_backends.py.

In short, the progress messages should appear the same regardless of the backend used (JoblibBackend or MPIBackend).

The manifest.in is useful when using pip to install (not working at the moment). It can be used to include the parameter files ...

Some issues that came up in #44

• add crop method to dipole
• add read_dipole function
• add mechanism info to cell repr

As many of you know I have spent the last year or so changing the model L5 pyramidal cells so that the simulated voltage traces in the dendrites look more similar to electrophysiological data recorded from pyramidal neuron dendrites, especially during calcium spikes/bursts. To do this, I changed the L5_pyramidal.py so that the dendritic Na, Kv, and Ca (L-type) conductances are distributed as functions of the distance from the soma, rather than setting the whole dendrite equal to one value. Here is the modified file for anyone who wants to look at or use these (saved as .txt because github didn't allow attaching .py files): L5_pyramidal.txt

For anyone using it

Important: I believe that if you are only changing this file out for the existing L5_pyramidal.py file you will run into an error with __create_all_IClamp() that will stop the code from working. I will get around to fixing this soon but in the meantime just copy the version of this function that's in the original code and replace this function. The reason is that I added functionality to inject current into the dendrite for some of my simulations but that involved changing other files as well. Sorry about this!

Within the file I have included a way to switch back and forth from these distributions ("updated_HNN_dends") to the regular HNN distributions ("classic_HNN_dends") which are constant values for everything except HCN channels. Just comment one or the other out under the _biophys_dends function like so

def __biophys_dends(self):
# self.classic_HNN_dends()
self.updated_HNN_dends()

You have to save the file, then quit HNN and restart it in order for this to do anything because this code gets run right when it is launched.

Right now the dendritic and somatic conductances are still adjustable from the GUI or the param files. The parameters I've been using for these three channels (Cell Parameters > L5 Pyr Biophysics) are:

L5Pyr_soma_gkbar_hh2: 0.06
L5Pyr_soma_gnabar_hh2: 0.32
L5Pyr_soma_gbar_ca: 10.0
L5Pyr_dend_gkbar_hh2: 0.0001
L5Pyr_dend_gnabar_hh2: 0.0028
L5Pyr_dend_gbar_ca: 40.0

The dendritic conductances are now functions of these values. Some of these changes are pretty drastic. With these values, the channel density distribution will now look like this (dotted lines are "classic" conductances).

Files
I have roughly hand-tuned the evoked input parameters for the threshold and suprathreshold ERP parameter files so that, with these changes to the L5 pyramidal cells, the output provides a good fit to the data. These need to be improved/optimized more. Once again I had to upload as .txt but they should be .param files.

ERP_yes.txt

ERP_suprathreshold.txt

For HNN development

I am sure there is a much better way for this code to be written and organized! Not to mention that hnn-core gets rid of the L5_pyramidal.py file. Some things to think about include

• whether there would be a way for users to easily switch back and forth from the "classic" and "updated" distributions from the GUI, rather than the bad solution I have of changing the source code and relaunching
• whether the parameters I have characterizing the distributions (e.g. the distance where the calcium conductance levels off) ought to be hard-coded as they are now or adjustable by the user.

Also, I changed and added a lot more files in order to be able to record and plot voltage traces, calcium currents, and calcium conductances in individual compartments of the L5 pyramidal neurons. I think some of these plots could be useful to include in the new versions of HNN. I've just created a public repository SMPugliese/hnn_calcium (https://github.com/SMPugliese/hnn_calcium) with the most up to date files I have on my computer. Let me know if there is another place you would prefer me to put these files.

Background

The ability to calculate LFP for simulated electrodes in the model (#150) allow for time vs. depth laminar CSD plots to be generated. Laminar CSD (electrodes arranged vertically) is the primary goal of this feature because laminar CSD is commonly used in animal studies where a laminar probe is inserted into the cortext to measure extracellular potentials. In the experimental animal studies, CSD is calculated from the bandpass filtered LFP data (low-frequency portion of extracellular potentials) to identify underlying neuronal activity at specific cortical layers. Such activity is identified as a "sink" (net influx of current into cell) or "source" (efflux into extracellular space) in the temporal-spatial domain.

Figure 5 from Sherman et al. 2016 shows laminar CSD plots of an anesthetized mouse and an awake monkey.

Sherman MA, Lee S, Law R, et al. Neural mechanisms of transient neocortical beta rhythms: Converging evidence from humans, computational modeling, monkeys, and mice. Proc Natl Acad Sci U S A. 2016;113(33):E4885-E4894. doi:10.1073/pnas.1604135113

CSD can be calculated via

numpy.diff(LFP_data,n=2,axis=ax)/spacing_mm**2

The sign may be adjusted to make a current sinks negative and sources positive.

Goal

Create laminar CSD plots from simulated data that are comparable to Figure 5 in Sherman et al. 2016

Requirements

1. Averaging LFP over multiple trials is typically done before computing CSD

2. CSD plots are created using a 2D spline over values at each electrode depth. Support various spline functions.

3. Users need to be able to easily adjust the X,Y scales to match simulated data with their experimental data

4. The CSD of the first and last channels cannot be computed using the 2nd spatial derivative. The Vaknin method is used to derive approximate CSD signals at these points

   G. Vaknin, P.G. DiScenna, T.J. Teyler, A method for calculating current source density (CSD) analysis without resorting to recording sites outside the sampling volume, Journal of Neuroscience Methods, Volume 24, Issue 2, 1988, Pages 131-135, ISSN 0165-0270, https://doi.org/10.1016/0165-0270(88)90056-8.

5. Implement iCSD method as an alternative to numpy.diff() above

Hi all,
I was just trying the examples in trunk on macos and was unable to get any of the 3 to run.

1. plot_simulate_somato fails looking for data (/Users/bloyl/mne_data/MNE-somato-data/MEG/somato/sef_raw_sss.fif) maybe the mne dataset has reorganized?

2. plot_simulate_alpha.py and plot_simulate_evoked both fail with a variant of

File "/Users/bloyl/Projects/hnn-core/hnn_core/basket.py", line 27, in _biophysics
    self.soma.insert('hh2')
ValueError: argument not a density mechanism name.

Hi there,

After installing hnn-core on my Mac, as per instructions in the README.rst file, python hangs (for several hours!) when I try to import hnn_core. Do I need a certain version of Anaconda (e.g., 2 or 3) for this to work?

See standard output below:
$ python
Python 3.6.8 |Anaconda, Inc.| (default, Dec 29 2018, 19:04:46)
[GCC 4.2.1 Compatible Clang 4.0.1 (tags/RELEASE_401/final)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

import hnn_core

@rythorpe you might be interested in this. I was looking into how a cell receives connections and realized that there are conditional statements in the network connection that depend on the input spike pattern. See here:

https://github.com/jonescompneurolab/hnn-core/blob/master/hnn_core/pyramidal.py#L534-L593

do you have any idea why the extpois and extgauss might have different connection patterns?

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.

As per @rythorpe there should be an upward deflection after the proximal input. See here:

#35 (comment)

Purpose:
To make code that was previously only in HNN GUI dual-purpose and serve for the analysis of simulations run by hnn-core from the command-line.

Rationale:
Since HNN GUI will import hnn-core already for hnn_core.simulator to run the NEURON solver, this will be a better home for the analysis functions. These functions will benefit from documentation and unit testing as part of hnn-core

Proposed components:

• Simulated LFP in hnn_core.simulator (#150)
• CSD calculation and plotting (#68)
• Objective functions for model optimization (parts from #77)
• Wrappers for parameter estimation with SNPE
• Spectral analysis
• RMSE calculation to data (#83 - closed, needs PR)

In addition to moving the code, the following improvments will be made:

• Code cleanup (Use library functions, formatting, etc.)
• Unit testing
• Documentation

The Network.plot_input() method currently only plots evoked inputs. It should plot all input types (e.g., rhythmic, Poisson, etc.). See jonescompneurolab/hnn#178 (comment).

I currently have a param file with evoked inputs that have periodic spacing. My goal is to replicate the simulation with only rhythmic inputs, however, there seems to be a discrepancy in how synaptic weights are assigned for evoked vs. rhythmic inputs. The following screenshots demonstrate this issue and their corresponding param files are attached. Note that, according to the param files, the synaptic conductancies for proximal and distal inputs are congruent across simulations.

I realize that there is a difference in how jitter is applied to individual evoked inputs vs. a series of rhythmic inputs; however, the fact that the simulations above produce dipoles that are different by an order of magnitude is confusing.

param_files.zip

The code Salvador has written for HNN can replace the network-building code in network.py and cell.py (maybe feed.py). This would allow users to modify the network configuration in an ad hoc fashion. It also would integrate with the web-based HNN GUI (bokeh-based) being developed by MetaCell.

So the question is how can these 4 files be integrated into mne-neuron, and lead towards a single code base for HNN?
https://github.com/jonescompneurolab/hnn/tree/netpyne/netpyne

Sometimes, the correct key may not be used because of a typo. The params object should check and not allow any key.

While working on #103 (after #98 broke the alpha example) we got hit by inconsistent handling of 'common' and 'unique' (renamed in #103) parameter sets (see discussion there for context).

The (new) test_feed.py:test_extfeed() illustrates the confusion: Poisson and Gaussian input parameters are always created by create_pext, but the 'common' ones aren't.

Variable naming (git grep p_ext) is quite poor, but rather than fiddling with names, it seems time to refactor the parameter handling process.

I suppose we're talking about an internal refactoring, where the API is less important than code clarity? Users shouldn't need to know anything about how the parameters are handled internally, right? The statefulness of the ExtFeed object is currently not used, so is it time to re-write the methods as functions? Or is there a higher meaning that's not obvious?

Some points to discuss here:

• should parameter-files be flat, or more structured? (backwards compatibility-issue vs. clarity)
• per-need inclusion of external feeds into net, which the gid_dict would then reflect (currently inconsistent for common vs. unique types, where no common input gids are created in the network object when t0 > tstop)

For instance when comparing different backends, the networks can be smaller

see: https://hnn.brown.edu/index.php/gamma-tutorial/

Implement a scheme for seeding multiple trials that allows for validating results with JoblibBackend and MPIBackend in #79. Ideally, this will produce the same results as HNN GUI. After this point, we can implement a plan for making changes such as how trials are seeded with provisions for being able to go back and test the "original" seeding scheme.

Note that #55 started to address this, but RMSE is a somewhat separate feature. The checks in test_hnn_core.py are more thorough than RMSE.

Looking at diff, probably only a few params need to be changed:

$ diff default.param OnlyRhythmicDistal.param 
2c2
<     "tstop": 170,
---
>     "tstop": 710.,
5c5
<     "N_trials": 1,
---
>     "N_trials": 0,
8,11c8,11
<     "save_spec_data": 0,
<     "f_max_spec": 100,
<     "dipole_scalefctr": 3000,
<     "dipole_smooth_win": 30,
---
>     "save_spec_data": 1,
>     "f_max_spec": 40.,
>     "dipole_scalefctr": 150000.0,
>     "dipole_smooth_win": 0,
119,123c119,123
<     "gbar_L2Pyr_L2Pyr_ampa": 0.0005,
<     "gbar_L2Pyr_L2Pyr_nmda": 0.0005,
<     "gbar_L2Basket_L2Pyr_gabaa": 0.05,
<     "gbar_L2Basket_L2Pyr_gabab": 0.05,
<     "gbar_L2Pyr_L5Pyr": 0.00025,
---
>     "gbar_L2Pyr_L2Pyr_ampa": 5e-4,
>     "gbar_L2Pyr_L2Pyr_nmda": 5e-4,
>     "gbar_L2Basket_L2Pyr_gabaa": 5e-2,
>     "gbar_L2Basket_L2Pyr_gabab": 5e-2,
>     "gbar_L2Pyr_L5Pyr": 2.5e-4,
126,134c126,134
<     "gbar_L5Pyr_L5Pyr_nmda": 0.0005,
<     "gbar_L5Basket_L5Pyr_gabaa": 0.025,
<     "gbar_L5Basket_L5Pyr_gabab": 0.025,
<     "gbar_L2Pyr_L2Basket": 0.0005,
<     "gbar_L2Basket_L2Basket": 0.02,
<     "gbar_L2Pyr_L5Basket": 0.00025,
<     "gbar_L5Pyr_L5Basket": 0.0005,
<     "gbar_L5Basket_L5Basket": 0.02,
<     "t0_input_prox": 1000.0,
---
>     "gbar_L5Pyr_L5Pyr_nmda": 5e-4,
>     "gbar_L5Basket_L5Pyr_gabaa": 2.5e-2,
>     "gbar_L5Basket_L5Pyr_gabab": 2.5e-2,
>     "gbar_L2Pyr_L2Basket": 5e-4,
>     "gbar_L2Basket_L2Basket": 2e-2,
>     "gbar_L2Pyr_L5Basket": 2.5e-4,
>     "gbar_L5Pyr_L5Basket": 5e-4,
>     "gbar_L5Basket_L5Basket": 2e-2,
>     "t0_input_prox": 2000.0,
136,138c136,138
<     "tstop_input_prox": 1001,
<     "f_input_prox": 10.0,
<     "f_stdev_prox": 20.0,
---
>     "tstop_input_prox": 710.,
>     "f_input_prox": 10.,
>     "f_stdev_prox": 20.,
151c151
<     "t0_input_dist": 1000,
---
>     "t0_input_dist": 50.,
153,155c153,155
<     "tstop_input_dist": 1001,
<     "f_input_dist": 10.0,
<     "f_stdev_dist": 20.0,
---
>     "tstop_input_dist": 710.,
>     "f_input_dist": 10.,
>     "f_stdev_dist": 20.,
158c158
<     "input_dist_A_weight_L2Pyr_ampa": 0.0,
---
>     "input_dist_A_weight_L2Pyr_ampa": 5.4e-5,
163c163
<     "input_dist_A_weight_L5Pyr_ampa": 0.0,
---
>     "input_dist_A_weight_L5Pyr_ampa": 5.4e-5,
166,167c166,167
<     "t_evprox_1": 26.61,
<     "sigma_t_evprox_1": 2.47,
---
>     "t_evprox_1": 1000,
>     "sigma_t_evprox_1": 2.5,
169c169
<     "gbar_evprox_1_L2Pyr_ampa": 0.01525,
---
>     "gbar_evprox_1_L2Pyr_ampa": 0.0,
171c171
<     "gbar_evprox_1_L2Basket_ampa": 0.08831,
---
>     "gbar_evprox_1_L2Basket_ampa": 0.0,
173c173
<     "gbar_evprox_1_L5Pyr_ampa": 0.00865,
---
>     "gbar_evprox_1_L5Pyr_ampa": 0.0,
175c175
<     "gbar_evprox_1_L5Basket_ampa": 0.19934,
---
>     "gbar_evprox_1_L5Basket_ampa": 0.0,
177,178c177,178
<     "t_evdist_1": 63.53,
<     "sigma_t_evdist_1": 3.85,
---
>     "t_evdist_1": 2000.0,
>     "sigma_t_evdist_1": 6.,
180,187c180,187
<     "gbar_evdist_1_L2Pyr_ampa": 0.000007,
<     "gbar_evdist_1_L2Pyr_nmda": 0.004317,
<     "gbar_evdist_1_L2Basket_ampa": 0.006562,
<     "gbar_evdist_1_L2Basket_nmda": 0.019482,
<     "gbar_evdist_1_L5Pyr_ampa": 0.142300,
<     "gbar_evdist_1_L5Pyr_nmda": 0.080074,
<     "t_evprox_2": 137.12,
<     "sigma_t_evprox_2": 8.33,
---
>     "gbar_evdist_1_L2Pyr_ampa": 0.0,
>     "gbar_evdist_1_L2Pyr_nmda": 0.0,
>     "gbar_evdist_1_L2Basket_ampa": 0.0,
>     "gbar_evdist_1_L2Basket_nmda": 0.0,
>     "gbar_evdist_1_L5Pyr_ampa": 0.0,
>     "gbar_evdist_1_L5Pyr_nmda": 0.0,
>     "t_evprox_2": 2000.0,
>     "sigma_t_evprox_2": 7.,
189c189
<     "gbar_evprox_2_L2Pyr_ampa": 1.438840,
---
>     "gbar_evprox_2_L2Pyr_ampa": 0.0,
191c191
<     "gbar_evprox_2_L2Basket_ampa": 0.000003,
---
>     "gbar_evprox_2_L2Basket_ampa": 0.0,
193c193
<     "gbar_evprox_2_L5Pyr_ampa": 0.684013,
---
>     "gbar_evprox_2_L5Pyr_ampa": 0.0,
195c195
<     "gbar_evprox_2_L5Basket_ampa": 0.008958,
---
>     "gbar_evprox_2_L5Basket_ampa": 0.0,
197c197
<     "sync_evinput": 0,
---
>     "sync_evinput": 1,
224c224
<     "Itonic_T_L5Basket": -1.0
---
>     "Itonic_T_L5Basket": -1.0,

It looks like a dipole.write() function exists but it needs to be fixed so that the name is assigned appropriately for each dipole file created.

A similar function would be great for network spiking so that we can generate data files similar to those produced by HNN.

Rather than having a NeuronNetwork instance modify a cell's gid-to-node assignment within a parallel context (i.e., via _PC.set_gid2node(gid, rank), we should try delegating the task to the _Cell and _ArtificialCell classes. This way, the Network or NeuronNetwork classes can simply create a list of gid values and let the cell objects handle their respective NEURON backends.

It's very cool that results can be compared to HNN on new commits. However, a couple of issues running the tests locally

1. Tests should probably not depend on mne:

========================================================= ERRORS =========================================================
_________________________________ ERROR collecting mne_neuron/tests/test_compare_hnn.py __________________________________
ImportError while importing test module '/Users/blake/repos/mne-neuron-new/mne_neuron/tests/test_compare_hnn.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
mne_neuron/tests/test_compare_hnn.py:6: in <module>
    from mne.utils import _fetch_file
E   ModuleNotFoundError: No module named 'mne'
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 errors during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
================================================ 1 error in 0.37 seconds =================================================

2. Where is /test_data/ (forgive my ignorance of travis CI)?
   https://github.com/jasmainak/mne-neuron/blob/master/mne_neuron/tests/test_compare_hnn.py#L16

see #119 (comment)

@blakecaldwell to continue off our discussion from today, I was proposing something along the lines of

tmax = 0.17
params = read_params('N20.json')

for t in np.arange(0, tmax, 0.5):
   net = Network(params)
   # extfeeds = create_extfeeds(params)
   extfeeds = [ExtFeed('proximal', t=0.05),
                      ExtFeed('distal', t=0.1)]
   dipoles = simulate_dipole(net, extfeeds, t=tmax, tstep=0.03)

I think you had two objections:

1. How will this be backwards compatible with HNN?
2. What is the advantage of doing this over params.update

For 2., I think the answer is that params is an antipattern in the same way kwargs is. There are many blog posts or stack overflow posts which explain this -- e.g., here.

As for 1., we could choose to be backwards compatible by adding an additional argument params to simulate_dipole that defaults to None but with a deprecation warning that it will be removed in the next release cycle.

Since all the common and unique feeds are assigned to the same location, the pos_dict does not need keys for each of them. See related discussion with @rythorpe

Moving this to hnn-core from hnn

From @rythorpe in https://github.com/jonescompneurolab/hnn/issues/208

I currently have a param file with evoked inputs that have periodic spacing. My goal is to replicate the simulation with only rhythmic inputs, however, there seems to be a discrepancy in how synaptic weights are assigned for evoked vs. rhythmic inputs. The following screenshots demonstrate this issue and their corresponding param files are attached. Note that, according to the param files, the synaptic conductancies for proximal and distal inputs are congruent across simulations.

Walkthroughs in examples for evoked and gamma work fine, but alpha fails mysteriously. I've set 'tstop': 110.0 for speed, but below is equally valid for the default 710.0.

In the hopes of finding a bug in params, I even tried this (3 keys differ, not that they seemed important):

params_fname = op.join(hnn_core_root, '../hnn/param', 'OnlyRhythmicDist.param')

But I get the same plots. The same example works fine in hnn, in the same conda env., where NEURON is from PyPi (7.8.0-127-g91f6e623+).

I guess what I'm asking is: any pointers on where to start debugging my setup? I suppose it's likely my NEURON installation, though I've been through the tests for nrnpython, which run quite happily in a parallel context (openmpi, mpi4py) on my dual-core macOS Catalina laptop.

https://github.com/hnnsolver/hnn-core/blob/0aa973ef430e67e3266883e909ea02945d41a1ac/hnn_core/dipole.py#L27-L34

@jasmainak I'm preparing a PR to add ParallelContext (n_cores > 1, but not compatible with n_jobs > 1). A function similar to _clone_and_simulate will be called, and the net.* functions need to be part of it. Can you explain why these functions need to separate from Network(params, n_cores)? All of _clone_and_simulate gets pickled, right? Perhaps these net.* calls can be part of an appropriately named method of Network.

Running git bisect to find difference between HNN and mne-neuron results gave:

c76a27b is the first bad commit
commit c76a27b
Author: Mainak Jas [email protected]
Date: Wed Feb 6 17:03:18 2019 -0500

[MRG]: refactor parconnect (#6)

* MAINT: refactor parconnect

* FIX remove redundant self

* FIX A_weight

* MAINT: use postsyns instead of dendrites

* DOC synapse -> receptor

I'm experiencing an issue where I get significantly different results, particularly noticeable in the inter-trial variability, in HNN versus hnn-core. Running the attached param file in HNN (top) and hnn-core (bottom) using the attached python script, I get the figures shown below. Furthermore, I haven't been able to reproduce this issue using the default parameter set.

issue_demo.zip