-
Notifications
You must be signed in to change notification settings - Fork 16
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
[CSTP] Ensuring all IM refractory period steps complete #23
Comments
@jkopsick has created code that may fix this issue in the branch ca3net_imfix. Note: this branch also includes code from the proposed bug fix for issue 18. His code update also enables a custom refractory period time value in milliseconds to be set. Either @jkopsick or I will create a push request with this code. |
How hard would it be to create a unit test that specifically reveals this bug, then passes with the fix? I see a lot of new tests on that branch, but they are large and complex. Wondering if smaller tests can help cover bugs like this one. |
Thanks @SigmaX , it should be relatively straightforward to create such a unit test. I think it could be a small simulation to test that the spike timings occur as expected from the IM model. I don't know who authored each unit test (e.g., Jeffrey, Lars, or I) but perhaps moving forward some smaller tests can be made. Jeffrey and I are still testing the code and could work on such a unit test once we are closer to ready to submit a push request. |
In the connection-specific STP branch (feat/ca3net) the refractory period (RP) included for Izhikevich model neurons can in some cases not process all integration calculation steps in an erroneous way. Specifically, when v_next > vpeak, only the first of the Runge-Kutta 4 (RK4) integration calculation steps are computed and not the rest of them. A note is that the RP code has only currently been implemented in RK4, not other integration methods.
Update 12/30/22: code in kernel_findFiring() has been updated to correctly support RP of any time value. A constant named RP_MAX_LST has been created to support that. However, the value of RP_MAX_LST being 20M is perhaps arbitrary and possibly should be set to a much higher value. Also, looking into the issues related to the kernel_findFiring() code may reveal the same problem exists for LIF-based RP. Another Github issue is likely to be created about this related to LIF.
The text was updated successfully, but these errors were encountered: