-
Notifications
You must be signed in to change notification settings - Fork 394
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
fix(lib/iob): Move value checks up to index.js #1437
Conversation
@mountrcg can you test this and confirm whether it helps with your issue, and otherwise works properly? |
I should probably mention that I'm running with these changes on my rig. I haven't noticed any issues, but I'm happy to run it for a few days and confirm that is still the case. |
just saw this now and will test, great stuff @ChanceHarrison |
warnings have been reduced to:
but thats on the simulator, I might not have enough treatments on it. will test on live data shortly. |
same result on live system, 7 warnings only |
lovely, fixed in my book! |
When Insulin Peak Time is set too low o high.
@@ -1,6 +1,6 @@ | |||
{ | |||
"name": "oref0", | |||
"version": "0.7.0", | |||
"version": "0.7.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is an artifact? Will need to check it before merging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure! All I can say is that it wasn't in my original changeset.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was because you based your change on master instead of dev, so shows up as a diff after I rebased to dev.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, of course. My bad on the base branch. Fortunately, it doesn't seem to make a significant difference in this context (beyond the version diff in package.json
). Let me know if you would like me to do anything on my end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll probably git reset --hard origin/dev
and cherry-pick your commits, then git push -f it, unless you beat me to it.
Merged via abf9c6b |
I had to revert this: 10f9e27 It is causing future IOB predictions to be incorrect (highly negative). |
To repro, run oref0-calculate-iob and look at the resulting iob.json. Note the iob values at the very end of the json file. With current dev (and the version previous to the regression), they'll be near zero. With the regression, they'll be highly negative.
|
(Mostly) fixes #1436
The root cause of the above issue is that the logic for using and validating custom insulinPeakTime (and by extension, the errors that are logged from said logic) was all the way down (in the sense of a call stack) in
calculate.js
. This means that the validation logic was running many more times than necessary (and in the case of when the values fall out of the tolerable range, an absurd amount of log messages).Here's what the typical flow might look like for that:
The changes I made move such value handling (both that in
calculate.js
and intotal.js
; thought the former was the source of pain, both were moved for consistency) toindex.js
, where the handling can be done once and the values can be used many times incalcualte.js
andtotal.js
.As this change asserts, why would we fetch the values, validate them, and log on error in
calculate.js
(which can, in the worst case be called 48 * the number of treatments that are being evaluated in the DIA times) when we can do so once inlib/iob/index.js
and just pass the values down?This is a much better situation, because we only get one log message for each invocation of
lib/iob
.The fix isn't perfect (and why I say it only mostly fixes #1436), because invoking
oref0-meal
results in somewhere between 15 and 20lib/iob
invocations, and thus an equivalent number of log messages. Not ideal, but much more palatable than the original number.Arguably a similar (if not more effective) fix for the logging issue would be to have just commented out the lines that were doing the logging entirely, but getting rid of one of the only ways that the user might know their config has out-of-range values didn't feel good.
On that note, I think it might be worth considering how we can get the log message into the pump-loop log instead of just the shared-node log, since I don't think there is much (if any) documentation that directs users to look in the shared-node log.
That, and maybe the pump-loop should just fail on out-of-range config values? It would certainly be more noticeable, but maybe also not desirable since it's an issue that we can correct programmatically by using the min/max allowed value.