GUI: Add E/I synaptic gains button

[asoplata]

Task 4 of #910

hnn_core/network:Network.update_weights() (
https://github.com/jonescompneurolab/hnn-core/blob/master/hnn_core/network.py#L1430 ) currently applies universally across all subsets of {Excitatory, Inhibitory} -> {Excitatory, Inhibitory}. If we assume that most users are going to want to universally increase the gain of a particular synapse connection, this means that both the Network > Connectivity or Network > Cell parameters VBoxes are not good places to add this. In the Connectivity case, a user would have to add the gain to every type of connection, which is annoying and time-consuming. In the Cell parameters case, we cannot select all Excitatory connections to update, which update_weights() currently requires.

For the sake of the tutorial, I think this should be solved in three steps:

1. Add a new VBox named Network > Universal synaptic gain with 4 adjustable values: the 4 combinations that update_weights() supports.
2. Later, either add another function or refactor update_weights() so that you can add a unitless gain modifier to connections the "lowest" level of the hierarchy.
3. Then, add entries in the Network > Connectivity vbox to customize these per every connection, if the user wants: e.g. add a gain box to L2_pyramidal -> L5_basket (soma) and similar.
4. At this point, if we want, we could also add additional per-cell_type synaptic gain entries in Network > Cell parameters vbox

[asoplata]

@dylansdaniels For the zero-ing out of the L2/3 synapses in the Gamma tutorial (near Fig 7 of https://jonescompneurolab.github.io/hnn-tutorials/gamma/gamma ), it may be fine for Thursday if the weights are changed manually. I think in the instance in the example, they would only need to change the outgoing L2/3 Pyramidal weights to 0, which is only about 15 clicks (shown below, they don't need to adjust the inhibitory weights).

I suggest this because the current update_weights() currently does not discriminate between L2 and L5, and will have to be changed before it could be used on Thursday, not to mention where it gets used and tested in the GUI would have to be implemented and tested, etc.

[dylansdaniels]

Makes sense! For class, I may make a separate config to load in with the weights set as such, just to save the clicks and speed things along. For updating the tutorial for now, maybe I sidestep this issue and just note that the weights will need to be changed to 0, and later we can add in language for the GUI buttons? @asoplata

[asoplata]

(Note that by "celltype", I mean one of {L2_basket, L2_pyramidal, L5_basket, L5_pyramidal}).

In thinking about this, there are several "levels" at which one would want to edit synaptic gain:

1. The "lowest" level: {celltype} x {compartment} x {synapse type}. In practice, I believe this is going to be the most detailed level by which users will want to change the gain using the GUI (for the gain of literally individual cells/connections, they can use the API). An API function still needs to be created for this (or net.update_weights() expanded). For the GUI, this should be added to the location indicated by 2 in the following comment: API: Synaptic gains #885 (comment) . Note that in the GUI, this is where not only should the user be able to edit the final gain, but this should ALSO display the actual current value of the gain (this is important).

2. The "highest" level: the four main connection types: {e-e, e-i, i-e, i-i}. Nick has already implemented changing these in the API, but this needs to be added to the GUI. Note that while this is a common use case, it does not differentiate between layers, which is needed for the Gamma tutorial (see section 4.1 https://jonescompneurolab.github.io/hnn-tutorials/gamma/gamma ). Adding this to the GUI should be carefully considered: note that everything currently in the "Network" tab currently both 1. lets the user change a property, and 2. importantly, lets a user SEE the current value of a property. For the gain of these connections types, there are some valid cases where this will be impossible; for example, if L2_pyramidal->L2_pyramidal's gain is 1, but L2_pyramidal->L5_pyramidal's gain is 0, then we cannot display the current gain solely using the categories of {e-e, e-i, i-e, i-i}. For this reason, I think if we want to add functionality to modify the gain of these types, we do the following:

   1. We add this as a separate tab next to "Connectivity" and "Cell parameters".
   2. Have one entry for each of {e-e, e-i, i-e, i-i} (default 1), but title them similarly to "Amount to multiply gain by"
   3. Also have a purple button that says "Multiply gains" and clearly indicates that this is performing an ACTION, instead of representing the network itself.
   4. Finally, the new, current values of the actual gains themselves will be updated and reflected on a per-{celltype}-x-{compartment} basis in the "Connectivity" tab.

3. We could add an intermediate level, such as {celltype}. In theory, this could go in the "Cell parameters" vbox (once it has been expanded to include all celltypes via GUI: Add inhibitory cells to "Cell parameters" GUI element #917 ). However, I don't think we should do this, since this won't add much value, but will increase the complexity. For example, if we wanted to add a per-celltype gain change from L2_pyramidal in the "Cell parameters" "Synapses" section, we would need to add many boxes like "AMPA gain to L2_pyramidal", "AMPA gain to L2_basket", "AMPA gain to L5_pyramidal", not to mention that it would only make sense to add the option per-synapse type. If we did this, we are basically re-inventing a second interface to do the same thing we will already have in the "Connectivity" tab.

Does anyone else have opinions about how to add synaptic gains to the GUI?