Strong distal drive, but weights set are set to 0 about hnn HOT 6 CLOSED

I think this was fixed in hnn_core? @rythorpe is this the same issue as jonescompneurolab/hnn-core#98?

from hnn.

@jasmainak Yes, kind-of. If I run the param file in hnn-core, I get the following:

Inputs:

Output spikes:

Agg. dipole:

If I delete all parameters pertaining to evdist_1 (via for key in params['*evdist_1*'].keys(): del params[key]) and re-run the simulation, I get

I think there are a few things going on here.

1. If evdist_1 parameters are given in the param file, plot functions in both HNN and hnn-core will plot the evoked inputs regardless of whether or not all synaptic weights are set to 0.

2. If the params['t0_input_dist'] < params['tstop_input_dist'] (in this case, 80 < 1001), HNN will plot the rhythmic distal inputs regardless of whether or not all synaptic weights are set to 0.

3. hnn-core does not plot any rhythmic inputs (prox or dist) in Network().plot_input(). This is a bug.

4. The difference between the aggregate dipole produce from the first parameter set compared to the dipole produced from the modified parameter set is due to different seeds.

from hnn.

@rythorpe 1. also seems to be a bug, no?

from hnn.

Thanks for reproducing this @rythorpe and the explanation points. It looks like I was making a faulty assumption what histograms would plot and a faulty connection between the distal input (green) and L2/3 spiking (green).

This seems to be in the same area of code as jonescompneurolab/hnn-core#98 but I think they are different issues?

@rythorpe 1. also seems to be a bug, no?

Maybe, but in any case, behavior needs to be consistent/defined for the histograms. 1 and 2 seem to be the core aspects to address in this issue. I think it's reasonable for a user to disable an input by making the weights all 0's, so perhaps a check could be done before creating the input (evoked and rhytmic) to ensure weights > 0?

There are actually two places where the histograms are plotted.
https://github.com/jonescompneurolab/hnn/blob/master/simdat.py#L282
https://github.com/jonescompneurolab/hnn/blob/master/spikefn.py#L235

The 0 weight issue is handled in the first place, but not the second. Note how the evoked distal input doesn't show up in the main GUI, but does in the Spike Viewer.

It'd be nice if the plotting functions in hnn_core could be called by the GUI. With functionality for rhythmic and poisson inputs added to Network.plot_input(), that function could be directly used for the histograms on the main GUI (simdat.py). For spikefn.py, read_spikes() would be called first.

from hnn.

@rythorpe 1. also seems to be a bug, no?

Our current convention across both HNN and hnn-core for evoked inputs, specifically, is that they are included in the simulation iff they are specified in the parameter file/set. Unlike rhythmic inputs, evoked feeds are not validated for non-zero synaptic weights (except when plotting in the main HNN GUI as Blake mentioned above) based on the assumption that if the user didn't want an evoked feed, the user shouldn't have included it in the parameter set to begin with. Ultimately, I think the fact that this assumption only applies to evoked inputs will lead to a lot of buggy behavior, but is not trivial to fix.

We can discuss this more in its own issue, but I think the user should be able to specify an arbitrary number of input feeds that are included in the simulation independent of synaptic weights. The key is that this should apply to all types of feeds across the board (e.g., the user could also specify rhythmic_dist_1, rhythmic_dist_2, or however many rhythmic inputs he or she desires). Such a scheme would 1) modularize and generalize how all feeds are imported and created, and 2) provide a sanity check in that all inputs that are specified in the parameter set should be visible in the hnn-core Network.spikes.types, Network.gid_dict, etc.

from hnn.

This original issue is fixed with the integration code. However, hnn-core threw a seemingly opaque exception on this file.

Starting simulation (8 cores). . .
Traceback (most recent call last):
  File "/Users/blake/repos/hnn/hnn/qt_thread.py", line 237, in run
    self._run(banner=banner, sim_length=sim_length)  # run simulation
  File "/Users/blake/repos/hnn/hnn/qt_thread.py", line 265, in _run
    net = Network(sim_params, add_drives_from_params=True)
  File "/Users/blake/repos/hnn-core/hnn_core/network.py", line 253, in __init__
    _add_drives_from_params(self)
  File "/Users/blake/repos/hnn-core/hnn_core/drives.py", line 144, in _add_drives_from_params
    net._instantiate_drives(n_trials=net.params['N_trials'])
  File "/Users/blake/repos/hnn-core/hnn_core/network.py", line 714, in _instantiate_drives
    seedcore=drive['seedcore'])
  File "/Users/blake/repos/hnn-core/hnn_core/drives.py", line 263, in _drive_cell_event_times
    prng2=prng2)
  File "/Users/blake/repos/hnn-core/hnn_core/drives.py", line 500, in _create_bursty_input
    raise ValueError('Burst duration cannot be greater than period')
ValueError: Burst duration cannot be greater than period

I'll open an hnn-core bug.

I could run the simulation by reducing spikes/burst to 5. There is no distal drive in the spiking plot

from hnn.