Sermon et al. helper functions

[agchesebro]

Helper functions to resolve #377.

[agchesebro]

@harisorgn the latest version of sermon_dbs_tutorial.jl has the different weights I'd mentioned. The comments on lines 40-51 are the initial version where I was building the connection rule into the weight and then just letting it get multiplied by the rest of the expression in BloxConnector. The one in lines 53-60 is the one that actually can go through structural_simplify without errors because I moved all of the things into kwargs to avoid the states getting collected as parameters. The dispatch of BloxConnector for this rule is in sermon_dbs.jl starting at line 72. For reference, these equations come from the Sermon paper equations 1, 5, and 6.

[agchesebro]

@helmutstrey @harisorgn quick update: I've got the code working in the sense that it's all connected and running, but it doesn't remotely reproduce the paper with the parameters and equations the authors give. I've noted some diagnostic plots that should reproduce some of the figures from the paper directly (but don't) and where I think there must be a dropped factor in one of the equations. I'll also put this in Slack so we can discuss if it's worth reaching out to the authors for their code.

[harisorgn]

This looks hardcoded for the particular tutorial case, i.e. expecting 3 elements in kwargs[:extra_bloxs]. You can imagine this breaking very easily if a user passes a different number in that keyword. We should generalize this in a loop, seems doable?

[harisorgn]

Same as above about kwargs[:extra_bloxs] but now it's kwargs[:extra_params]. I understand that we might want to keep this conenction rule specific to the tutorial (for now) in the interest of development speed, but we should think about the most likely breaking cases.

[harisorgn]

I don't see an else to this if. Could we just claim that (for now) :sermon_rule is the only possible connection rule to reduce the kwargs that are exposed to the user? Or were you planning on adding more rules?

[harisorgn]

Does it make sense to define a PooledKuramotoOscillator <: CompositeBlox that contains some pools and some oscillators? The oscillators would then connect to each other based on pool parameters as you want, and the System that is contained in this new Blox would hold all pool parameters and states, so you don't get any complaints on the final system construction/simplification. I think something like this would work and it's not too hard to get namespaces correctly.

The alternative could be that you keep pools and oscillators separate as you do and pass in the connection rule between oscillators some expression that involves pool states/parameters. We would then need to get the namespaces of these pool symbolics correct, so that you don't get almost duplicates in structural_simplify (e.g. pool1.state1 and global_namespace.pool1.state1) which I suspect is an issue with your original implementation.

[agchesebro]

@gabrevaya this is the stimulator for an arbitrary pulse train

[agchesebro]

@gabrevaya this is the connection rule for the DBS stimulator to Kuramoto blocks