-
Notifications
You must be signed in to change notification settings - Fork 45
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
Spike management proposal #330
Comments
@ingablundell What is your opinion? |
@Silmathoron Thank you for this! I am still not sure this is more intuitive. Your problem with the "curr_sum" notation was, if I remember this correctly, that it is unintuitive to write down a convolution of a function that you don't know. But when you write down the equation plus the initial values the solution will be unique (you won't be able to state anything weird with a computer). So from a mathematical point of view it makes a lot of sense to define the convolution. And I think it is nice to be able to see exactly what the equation is we are solving from looking at the ODE. |
@ingablundell that was not really my argument: I was saying that if he provides an ODE and its initial conditions in the equation block, the user expects you to solve this ODE in a step by step fashion, which means he does not expect NESTML to use a step function, thus the use of the convolution. My objective was:
The last point is arguably not guaranteed since it is based only on my gut feeling and a discussion with Sam during the workshop, which makes it a rather small user panel... EDIT: maybe the best would be to send a form on NEST_USER to directly get the opinion of the guys who might use NESTML... |
Also: Am I right in assuming that you want no explicit initial values for I_syn_ex'? |
@ingablundell ok, removing L151 would at the very least make both implementations more coherent! (which also addresses point 3) I think asking the users is best... you could implement both, but I think this could easily lead to possibly confusing code constructs... Eventually, if you decide to keep these EDIT: and no, I do want to be able to set initial values for |
I just realized that my proposal might not be as simple to implement as I first thought...
Any thoughts/comment on that? |
@Silmathoron |
I'm sorry, I did not get your a) point... which issue were you referring to? Maybe to clarify:
This means that:
To summarize, it would lead to:
|
To me b) is a bit weird (maybe because I'm neither a modeler nor a physicist) and we would want it to be possible to apply spikes not only the derivative of maximum order (i.e. n-1 here). This: psc_alpha implicit --> apply_spikes(I_syn_ex', spikes_ex, normalization=1pA*e/tau_syn_ex) (spikes applied to the 1st derivative) is definitely a possibility but we would also have to allow calling apply_spikes several times for one "shape", right? E.g. we might want I(0)=0; I'(0)=a; I''(0)=b; a and b being some constants. Then we would have to call apply_spikes for I and I'. |
I think you try to answer this question already in your last sentence... but I really don't understand what you mean... |
I''= ... +\sum_{ti\le t}\sum{k\in spike}w_k \delta(t-t_i) \frac{e}{\tau} Therefore we don't need to state any intitial values for I'. About applying spikes on both I and I': No idea. What I meant was just, that I could conceive people stating a number of initial values that don't equal zero. But maybe that wouldn't happen. |
I completely agree with you until the "Therefore": we still need to state the initial value of I'm not sure I understand your sentence
Could you elaborate on that? Do you mean "initialize a state variable with a non-zero value" or "initializing a finite number of state variables"? |
What do you mean by
Did you possibly overlook the
in the equation? By adding the deltas we implicitly use initial values 0 for I and e/tau for I'. I'm a bit confused. Did you forget to state the initial values for I' in your test.nestml file? I am not actually trying to advocate not stating initial values. |
I meant that you're missing initial conditions and therefore that your system is not uniquely determined: diracs do not provide the equivalent of initial conditions, so I do not understand your
Do you mean that in NESTML you set |
I try to summarize the current state of the discussion regarding spike handling (#368 is related to the current issue). The idea is to change the current nestml syntax with respect to initial values as follows: a) For every differential equation form the b) Buffers store the type, cf. #368 c) The shape is associated The return value of the
@ingablundell @Silmathoron What do you think? |
@DimitriPlotnikov this looks nice to me, except for the unitless part, for which I'm not sure this is a good idea. |
@Silmathoron I'm even starting to think, that it would be a good idea to mark shape function explicitly. Since it could avoid the confusion and would align to the functional notation of the shape function. E.g.:
|
Done in #382 |
This proposal tries to provide a way to minimize the amount of code necessary to manage spike arrival and spike effect while also providing a unique interface for the ODE vs shape definition.
This would only involve one
apply_spikes
function taking as parameters:I_syn_ex
)spikesEx
)shape
function if we use the function definition.In the
update
block, you would then call:apply_spikes(I_syn_ex, spikesEx)
orapply_spikes(I_syn_ex, spikesEx, I_shape)
Attached examples in the zip file.
spike_proposal.zip
The text was updated successfully, but these errors were encountered: