Replicate periodic evoked inputs with rhythmic inputs

[rythorpe]

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

[blakecaldwell]

I just observed this too with the default parameter set as a starting point where rhythmic inputs appear to have more of an effect. The code for generating inputs could use a lot of improvement. There aren't any methods for inspecting the generated rhythmic feeds in feed.py right now. If you wanted to add a method that allows comparison at the python level, we could definitely reuse that code as a test once integrated with hnn core.

[stephanie-r-jones]

One important difference in the evoked vs rhythmic input is the spatial spread of the input in the network. If I recall correctly, the evoked input targets the center of the network with a gaussian falloff, while the rhythmic input has a wider fall off and contacts all of the cells with nearly equal strength. There is also the issue of synchrony of the inputs, and evoked inputs have the option of being synchronous or asynchronous to the cells, while this is not an option for rhythmic inputs. We need to clarify this on the website.

[rythorpe]

I thought the gaussian falloff was for local network connection weights but that synchronous evoked inputs targeted all relevant cells (according to their type) at the same time and same strength. Is that not correct?

…

On 5/3/20 9:35 AM, stephanie-r-jones wrote: One important difference in the evoked vs rhythmic input is the spatial spread of the input in the network. If I recall correctly, the evoked input targets the center of the network with a gaussian falloff, while the rhythmic input has a wider fall off and contacts all of the cells with nearly equal strength. There is also the issue of synchrony of the inputs, and evoked inputs have the option of being synchronous or asynchronous to the cells, while this is not an option for rhythmic inputs. We need to clarify this on the website. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/jonescompneurolab/hnn/issues/208#issuecomment-623111334>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE2GT3SEOZMJQTTL46FENPTRPVXKRANCNFSM4MWZEODQ>.

[blakecaldwell]

@rythorpe I believe you are the best person to say what work remains to be done with this or if it will be part of hnn-core. Could you update this issue?

[rythorpe]

@blakecaldwell I think it will be much more intuitive to address this issue in hnn-core. Most of it can be addressed as we update the API.

[blakecaldwell]

Closed in favor of #114

[jasmainak]

I thought the gaussian falloff was for local network connection weights but that synchronous evoked inputs targeted all relevant cells (according to their type) at the same time and same strength. Is that not correct?

The gaussian fall-off is controlled by the "lamtha" parameter. For rhythmic inputs, it seems to be set at 100 and for evoked inputs, it's set at 3. So, what @stephanie-r-jones is saying seems correct. We need to make this stuff more transparent but getting their slowly!

[rythorpe]

I thought the gaussian falloff was for local network connection weights but that synchronous evoked inputs targeted all relevant cells (according to their type) at the same time and same strength. Is that not correct?

The gaussian fall-off is controlled by the "lamtha" parameter. For rhythmic inputs, it seems to be set at 100 and for evoked inputs, it's set at 3. So, what @stephanie-r-jones is saying seems correct. We need to make this stuff more transparent but getting their slowly!

Sure enough. Maybe we can add lamtha as an optional argument in our updated feed-creation API.

[jasmainak]

@rythorpe I'm closing this issue. It seems to be resolved now that we have a new feed-creation API and lamtha is a parameter with a different name -- space_constant. Please feel free to reopen if you disagree