-
Notifications
You must be signed in to change notification settings - Fork 22
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
Strong distal drive, but weights set are set to 0 #178
Comments
I think this was fixed in |
@jasmainak Yes, kind-of. If I run the param file in hnn-core, I get the following: If I delete all parameters pertaining to I think there are a few things going on here.
|
@rythorpe 1. also seems to be a bug, no? |
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?
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. 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 |
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 |
When this param file is run, there is a strong distal drive that induces spiking, but the parameter file doesn't specify any valid distal inputs (weights are all 0).
The text was updated successfully, but these errors were encountered: