[MRG] GUI update init network

[gtdang]

Update of the _init_network_from_widgets function

Work done:

• DRYs _init_network_from_widgets by abstracting logic of getting values from drive widgets to _drive_widget_to_dict
• Filters poisson drive weights and constants for only weights that have positive values. This is because the API add_poisson_drive method can't accept 0 values for rate constants.
• Updated the init test to look at individual components of the Network because it is still a WIP to get things like tonics and connectivity equivalent between API and GUI. This will be addressed in further work.

[gtdang]

@ntolley We need to discuss this one.

The work on this PR derived from finding that the number of connections did not match the input file that is loaded into the GUI. We noticed that there were more connections in the GUI-derived network compared to an api network when both used the jones2009_3x3_drives.json input file. It was determined that this is because the GUI is supplying all widget values (even zero-weights) to the drive construction, so connections were created for nulled weights. This PR implements a method to filter and only provide the positive weights (and associated constants) to the drive construction.

This made sense in the context of the jones2009_3x3_drives.json file because it was constructed via the API by supplying only cell types with positive weights. However this does not work for the new default param file jones2009_base.json because this file was derived from the flat default.json file, which had 0 weights for nulled cell-types. With the filtering of this PR in place, the GUI derived network has less connections than the network read in by the API.

So it seems the equivalency is dependent on the how the input file was constructed (supplying the API 0 placeholders or not). I don't think we can rely on a definitive assert net_gui == net_api for these tests. And we need to choose a sensible behavior for the GUI: do we filter for only cell types with positive weights or do we supply all place-holder values?

[gtdang]

@ntolley We need to discuss this one.

The work on this PR derived from finding that the number of connections did not match the input file that is loaded into the GUI. We noticed that there were more connections in the GUI-derived network compared to an api network when both used the jones2009_3x3_drives.json input file. It was determined that this is because the GUI is supplying all widget values (even zero-weights) to the drive construction, so connections were created for nulled weights. This PR implements a method to filter and only provide the positive weights (and associated constants) to the drive construction.

This made sense in the context of the jones2009_3x3_drives.json file because it was constructed via the API by supplying only cell types with positive weights. However this does not work for the new default param file jones2009_base.json because this file was derived from the flat default.json file, which had 0 weights for nulled cell-types. With the filtering of this PR in place, the GUI derived network has less connections than the network read in by the API.

So it seems the equivalency is dependent on the how the input file was constructed (supplying the API 0 placeholders or not). I don't think we can rely on a definitive assert net_gui == net_api for these tests. And we need to choose a sensible behavior for the GUI: do we filter for only cell types with positive weights or do we supply all place-holder values?

Just to document offline discussion.

• We decided to not filter for 0 weights and add 0 weights to the test input file construction. This is for Evoked and Bursty drives.
• The poisson drive inputs are still being filtered by positive weights though because the add_poisson_drive api does not take 0 rate constants.