Exponential curves #568

sulkaharo · 2017-07-25T13:10:10Z

Implements #544 - needs testing help, do not merge until confirmed to work.

NOTE: consider testing this extremely experimental! This code branch implements the new exponential curve model for insulin activity. This is a fairly big change compared to the old bilinear model, so if you do participate in the testing of this feature, assume you will need to monitor your BG closely and might need to adjust your profile to fit.

The code now supports three new configuration variables in preferences.json:

curve, with legal values of blank, "bilinear", "rapid-acting" and "ultra-rapid"
- If left blank or set to "bilinear", OpenAPS uses the old insulin activity model
- If set to "ultra-rapid", the new curve model analyzed from publicly available data for Fiasp from Novo Nordisk is used, set to reach activity peak at 55 minutes
- If set to "rapid-acting", the new curve model analyzed from publicly available data for Novorapid (Novolog) from Novo Nordisk is used. This curve should match well to Novorapid, Novolog, Humalog and Apidra and is set to peak at 75 minutes
insulinPeakTime, with legal values from 35 to 120. The value defines the minutes from bolus to peak. Note if you don't set it, the above mentioned peak defaults are used.
useCustomPeakTime, which must be set to "true" for the customized insulinPeakTime value to take effect

In order to use the rapid-acting or ultra-rapid curves, your pump must be set to 5 hour DIA, or longer. 6 hours is recommended as the starting point.

The underlying mathematical model is developed by @dm61.

Below are the activity and IOB graphs at various DIA and peak values

Testing

Both Fiasp and Novorapid curves are modeled after 5 hour DIA (compared to 3 hour default DIA for the old model). Due to the curve shape, the insulin activity contribution at the 5 hour mark is extremely low but should model the actual insulin tail more effectively than the old model, so it'd be extremely beneficial to get testing help from users who currently have their DIA set to a lower value (3 or 4 hours), who would set their DIA to 5 hours with the new curve model and report back if OpenAPS correctly keeps the basal rates in balance.

For Fiasp users, please start testing with DIA = 6, curve = "ultra-rapid" and do not set insulinPeakTime. If it looks like Fiasp is peaking for you faster or slower than OpenAPS expects (similar to your DIA being shorter or longer in the old parlance), please adjust insulinPeakTime by a small amount (such as 5 minutes) from the default of 55.

Note on Fiasp

Multiple users have reported cab take up to a month for the body to fully to adapt to Fiasp. If your body needs to adapt, you're likely to see the first few days post adopting Fiasp to work well and then hit a sudden resistance period, where your total daily dose will increase substantially and you might need to adjust every setting in your profile (ISF, carb ratios, basals). Cause for this is unknown but this is expected on some individuals and this doesn't indicate the loop is behaving unexpectedly.

PieterGit · 2017-07-25T14:44:38Z

How can you find/calculate the insulinPeakTime that must be used?
Or should I first test Novorapid with insulinPeakTime 55 min and DIA=5h?

sulkaharo · 2017-07-25T14:52:10Z

@PieterGit Start with DIA=5 and curve = fiasp. The peak time defaults to 55, which is the "official" peak from Novo.

sulkaharo · 2017-07-25T15:22:42Z

Oops, @PieterGit the peak time setting is currently only supported for Fiasp. I'll look at adding it for Novo, too.

mgranberryto

This has nothing to do with this PR per se, but I have noticed a recent performance regression that I noticed when I started using the exponential curves.

I had gone a while between loop updates prior to implementing the exponential curves so this isn't necessarily the cause, but oref0-meal has gone from returning almost instantaneously to requiring well over a minute to execute in my loop. I don't know whether it's because the IOB formula is now significantly more resource-intensive to calculate (non-integral powers are computationally expensive) or because oref0-meal is operating on significantly more data with the merged pump history or both, but it is leading to a non-trivial amount of extra load on my Edison and I can no longer loop through the night if I forget to plug in at night. SMB boluses are also coming in minutes later now, which should lead to more control instability. It's small, but small things add up.

I have thought about pre-calculating the iob/activity values for "1 unit" from 0 ... dia minutes and returning those cached values scaled by the insulin dose. It would also be possible to calculate the current insulin math as a cross-correlation of the IOB and activity arrays with a per-minute insulin delivery vector. In an experiment in Python I found that to result in near-instantaneous all-day calculations, but I haven't gone through the effort of implementing it in JavaScript.

mgranberryto · 2017-07-25T15:09:20Z

lib/iob/calculate.js

+
+    if (treatment.insulin) {
+        var bolusTime = new Date(treatment.date);
+        var minAgo = diaratio * (time - bolusTime) / 1000 / 60;


If you have the spreadsheet up, I'd like to see how the peak time adjustments affect NovoRapid too. This looks to me like it will completely break as it currently stands.

Changed the code so it uses 75 minutes as the baseline for Novo.

mgranberryto · 2017-07-25T15:10:56Z

lib/iob/calculate.js

+
+    curve = curve.toLowerCase();
+
+    if (curve != 'novorapid' && curve != 'fiasp') {


I know I didn't include it in the code you started with, but it is probably worth including 'novolog' as a curve option too, as an alias for 'novorapid'.

👍 Renamed the curves to generic names, will push soon.

mgranberryto · 2017-07-25T15:16:42Z

lib/iob/calculate.js

+    	return;
+    }
+
+	var usePeakTime = false;


It's a nitpick, but it looks like indentation is irregular here. It's probably worth cleaning this up or using an editor to reformat the function.

Reformatted!

mgranberryto · 2017-07-25T15:17:37Z

lib/iob/calculate.js

+		console.error('Pump DIA must be set to 5 hours if using the Insulin Peak Time setting');
+
+		if (profile.insulinPeakTime < 35 || profile.insulinPeakTime > 80) {
+			console.error('Insulin Peak Time is only supported for values between 35 to 80 minutes');


Perhaps this should come earlier and it should be restricted to fiasp only.

Added scaling for Novo, too, and expanded the range.

mgranberryto · 2017-07-25T15:18:03Z

lib/iob/calculate.js

+
+    var diaratio =  5.0 / profile.dia;
+
+	if (profile.insulinPeakTime !== undefined) {


The indentation is different here too.

Reformatted.

mgranberryto · 2017-07-25T15:20:00Z

lib/iob/calculate.js

+
+        if (minAgo < end) {
+            if (curve.toLowerCase() === 'fiasp') {
+                iobContrib = treatment.insulin * (((minAgo / 55) + 1) * Math.exp(-(minAgo) / 55));


Does the peak scaling change the AUC for activity? I haven't done the math, but it feels like it might. A normalization term might be needed.

Yeah the AUC changes; here's what the AUC normalized curves look like. The change in the calculated activity is pretty dramatic, wonder if this would work.

sulkaharo · 2017-07-25T17:37:37Z

My Excel that made the graphs

iob act model.xlsx

…Novo peak scaling. AUC normalized for activity.

mgranberryto

It's a little tough seeing what changed in the tests through Github's interface. Did you just add a couple tests?

This appears to address the concerns that I had, aside from verifying that the peak-scaled and normalized IOB and activity formulas correspond with eachother. Intuitively they look like they should, but I haven't yet done the math.

mgranberryto · 2017-07-25T17:49:59Z

tests/iob.test.js

+        afterDIA.bolussnooze.should.equal(0);
+    });
+
+    it('should calculate IOB with Fiasp', function() {


Should this text be changed for consistency now that fiasp has been changed to ultrafast?

mgranberryto · 2017-07-25T17:51:16Z

tests/iob.test.js

+    });
+
+
+    it('should calculate IOB with Fiasp peak setting of 55', function() {


It says "Fiasp" here too.

mgranberryto · 2017-07-25T17:54:13Z

lib/iob/calculate.js

-    	console.error('Unsupported curve function: "' + curve + '". Supported curves: bilinear, novorapid and fiasp.');
-    	return;
+
+    if (curve != 'fast-acting' && curve != 'ultrafast') {


rapid-acting is the language commonly used in the USA for Novolog, Humalog, and Apidra, and short-acting for regular. Would rapid and ultra-rapid work better here?

👍 changed

mgranberryto · 2017-07-25T17:56:43Z

lib/iob/calculate.js

+            var y = (minAgo - peak) / 5;
            iobContrib = treatment.insulin * (0.001323 * y * y - .054233 * y + .55556);
            //activityContrib=sens*treatment.insulin*(2/dia/60-(minAgo-peak)*2/dia/60/(60*dia-peak));
            activityContrib = treatment.insulin * (2 / dia / 60 - (minAgo - peak) * 2 / dia / 60 / (60 * 3 - peak));


I haven't tested this, but I want to verify that activity integrates to something ~= treatment.insulin post-scaling. Strange things will happen if it doesn't.

This is the old algorithm, which I'm leaving exactly as-is

mgranberryto · 2017-07-25T18:08:40Z

Thanks for making the effort to push this across the finish line. This is going to make a huge difference.

sulkaharo · 2017-07-25T19:08:23Z

@mgranberry thanks for the comments! Better get this right <3

sulkaharo · 2017-07-25T19:38:14Z

Here's the current activity curve for rapid-acting model

ghost · 2017-07-26T05:12:06Z

Have remaining 85U Humalog in my reservoir, with a new reservoir will give Fiasp a 2nd trial testing the curve adjustments

PieterGit · 2017-07-26T21:12:21Z

testing this with jubi 0.2.0 rig on node 6.11.1 and with curve=rapid-acting (novorapid). First results are nice (quite flat). Please also add the curve preference to oref0/lib/profile/index.js. CPU usage of the rig seems a bit higher.

…g, added default curve to profile to ensure the correct curve is used

ghost · 2017-07-27T09:12:24Z

running now w/ Fiasp and ultra-rapid, today breakfast 7.00 am, 85g carbs, 11U Fiasp per pump, here the curve 4 hours later

sulkaharo · 2017-07-27T10:04:19Z

If you're on this branch, please update to the latest push. I made a fix to the profile.json generation that ensures the new curves are actually being used at all times.

scottleibrand · 2017-08-12T05:10:14Z

Running this on a rig with default preferences (bilinear curve) to start with. The pump-loop is never completing before getting killed off. When I run it manually, it's getting stuck on some of the new code from #585. Moving the rest of my bug report over there for further discussion.

This reverts commit 72a60d9, reversing changes made to 547376a. Conflicts: lib/iob/total.js

tim2000s · 2017-08-12T11:23:13Z

Given @sulkaharo 's investigations into the maths of the existing bilinear curves, is it worth leaving out the bilinear option and simply releasing 0.6.0 with the updated "rapid" and "ultra-rapid" curves? We know that these scale safely and produce good results, and it will remove the broken maths for bilinear in the process.

tim2000s · 2017-08-12T12:05:07Z

I'm running exponential curves branch on a rig with node 0.10.29, updated to the latest versions of the code. Preferences are:

"max_iob": 12,
        "max_daily_safety_multiplier": 3,
        "current_basal_safety_multiplier": 4,
        "autosens_max": 1.2,
        "autosens_min": 0.7,
        "rewind_resets_autosens": true,
        "autosens_adjust_targets": true,
        "adv_target_adjustments": true,
        "maxCOB": 120,
        "override_high_target_with_low": false,
        "skip_neutral_temps": false,
        "unsuspend_if_no_temp": false,
        "bolussnooze_dia_divisor": 2,
        "min_5m_carbimpact": 8,
        "carbratio_adjustmentratio": 1,
        "autotune_isf_adjustmentFraction": 0.5,
        "remainingCarbsFraction": 1,
        "remainingCarbsCap": 90,
        "enableUAM": false,
        "enableSMB_with_bolus": false,
        "enableSMB_with_COB": false,
        "enableSMB_with_temptarget": false,
        "enableSMB_after_carbs": false,
        "curve": "bilinear",
        "useCustomPeakTime": false,
        "insulinPeakTime": 75

And the loop is running correctly. See logs:

tynbendad · 2017-08-13T20:52:06Z

does this change include a finer control over DIA (e.g., 4.5 hours vs 4 or 5)? or do you think i will no longer want that after using the new curves? right now 4 has trouble giving lows overnight and 5 doesn't quite get us down to target overnight, i'm hoping a longer autotune on 5 will fix that but not sure...

tim2000s · 2017-08-13T21:41:52Z

@tynbendad With exponential curves, DIA is no longer used for calculating insulin IOB or action.

tynbendad · 2017-08-13T21:51:34Z

thanks & great, that makes things simpler, i think...

ghost · 2017-08-14T14:44:30Z

Q to the curve set in preference.json, any information in the log which curve is set?

scottleibrand · 2017-08-14T14:58:37Z

Not currently. Perhaps we should have determine-basal print the curve-related preferences? Want to PR that?

tim2000s · 2017-08-15T05:29:11Z

@sulkaharo mentioned he was planning to add that.

tynbendad · 2017-08-17T05:16:23Z

just curious in case its needed by someone someday, is it possible to add a curve for regular insulin ("R")?

scottleibrand · 2017-08-17T05:18:23Z

Possible, sure. Worth it? Most definitely not, until/unless someone needs it.

mgranberryto · 2017-08-17T17:02:59Z

To my eye a peak of 90 and dia of about 8h approximates R well enough, but there a lot of other assumptions being made in the system about insulin activity that make it a bigger task than it immediately appears to use "R." I suspect there aren't many (any?) users using OpenAPS with regular insulin.

PieterGit · 2017-08-27T22:14:30Z

@scottleibrand : did you manage to resolve the stability issues you mentioned here #568 (comment) ?

I ran the curve = bilinear for about a week on my branch https://github.com/PieterGit/oref0/commits/201707_dev a while ago and did not have any stability problems. The branch was a bit to eager SMB'ing and sometimes caused hypo's.

Do people use 0.6.0 with this curve=rapid-acting on a daily basis now?

scottleibrand · 2017-08-27T23:16:22Z

I fixed the performance issues with some optimizations in 0.6.0-dev, but haven't retested Sulka's PR. We're using ultrarapid and it's working quite well.

tim2000s · 2017-08-28T13:42:12Z

I've been running with ultra-rapid for weeks now with no stability issues.

philipgo · 2017-09-07T21:34:21Z

Should the line in preferences.json read "curve": "ultra-rapid" or "curve": ultra-rapid ?

From the code I would expect ultra-rapid without quotation marks but Tim`s example has quotation marks. What is the correct form?

scottleibrand · 2017-09-07T21:40:20Z

"curve": "ultra-rapid" is how it should appear in preferences.json.

ghost · 2017-09-13T07:54:32Z

short Q, for the new curves I need to do a checkout 0.6.0-dev?
a rough ETA for availability in dev (the curves)?

scottleibrand · 2017-09-13T18:24:05Z

Correct. We are just waiting for someone to have some time to do some documentation before we merge 0.6.0-dev to dev for broader testing.

sulkaharo added 12 commits July 18, 2017 00:09

Fix require() statements to work with Node 8

8efc9e4

Change to determine_basal that exposes behavior changes

d7745ee

Oops can’t do that simplification

56b6823

Fiasp curve

5bb096c

removed debug logging

2c846e0

peak configuration, support old bilinear model

b58a1d7

Changes to code structure, more tests

16b88df

Merge commit 'd5a97b48b1db77ab614f16cb1c15b70c41c3936b' into fiasp

ad03c73

Revert a require() change that was included accidentally

ac98696

Merge branch 'wip/db_issue' into fiasp

f54ceff

Another change revert, needs testing outside the scope of Fiasp

36c7fdb

Removing accidental formatting changes

1139501

sulkaharo mentioned this pull request Jul 25, 2017

Support of FIAsp insulin curve LoopKit/Loop#388

Closed

mgranberryto reviewed Jul 25, 2017

View reviewed changes

Force IOB to 0 if over 5 hours have passed. Added tests, support for …

f574382

…Novo peak scaling. AUC normalized for activity.

mgranberryto reviewed Jul 25, 2017

View reviewed changes

Renamed the curves for consistency

abebb03

Small speedup to IOB calculation, use consistent date value if missin…

e4262e1

…g, added default curve to profile to ensure the correct curve is used

New generic curves

a261006

scottleibrand mentioned this pull request Aug 12, 2017

Unit test improvements, small bug fixes #585

Closed

scottleibrand force-pushed the 0.6.0-dev branch from 72a60d9 to 279750d Compare August 12, 2017 05:44

Revert "Merge branch 'cob-test' into 0.6.0-dev"

ebddd8d

This reverts commit 72a60d9, reversing changes made to 547376a. Conflicts: lib/iob/total.js

chmod +x bin/oref0_nightscout_check.py

3bf47f7

scottleibrand merged commit 9683781 into 0.6.0-dev Aug 13, 2017

scottleibrand deleted the exponential_curves branch August 13, 2017 17:38

scottleibrand mentioned this pull request Sep 6, 2017

Understand iob calcs openaps/docs#1033

Merged

tim2000s mentioned this pull request Sep 17, 2017

Merge 0.6.0-dev to dev for eventual 0.6.0 release #592

Merged

danamlewis mentioned this pull request Sep 19, 2017

Prep for eventual 0.6.0 dev to master release #650

Merged

5 tasks

This was referenced Oct 6, 2017

Prep for eventual 0.6.0 dev to master release #694

Merged

Prep for oref0 0.6.0 release dev to master #707

Merged


		curve = curve.toLowerCase();

		if (curve != 'novorapid' && curve != 'fiasp') {


		var diaratio = 5.0 / profile.dia;

		if (profile.insulinPeakTime !== undefined) {

		});


		it('should calculate IOB with Fiasp peak setting of 55', function() {

Exponential curves #568

Exponential curves #568

Uh oh!

Conversation

sulkaharo commented Jul 25, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

PieterGit commented Jul 25, 2017

Uh oh!

sulkaharo commented Jul 25, 2017

Uh oh!

sulkaharo commented Jul 25, 2017

Uh oh!

mgranberryto left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mgranberryto Jul 25, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sulkaharo Jul 25, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sulkaharo commented Jul 25, 2017

Uh oh!

mgranberryto left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mgranberryto commented Jul 25, 2017

Uh oh!

sulkaharo commented Jul 25, 2017

Uh oh!

sulkaharo commented Jul 25, 2017

Uh oh!

ghost commented Jul 26, 2017

Uh oh!

PieterGit commented Jul 26, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Jul 27, 2017

Uh oh!

sulkaharo commented Jul 27, 2017

Uh oh!

scottleibrand commented Aug 12, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tim2000s commented Aug 12, 2017

sulkaharo commented Jul 25, 2017 •

edited

Loading

mgranberryto Jul 25, 2017 •

edited

Loading

sulkaharo Jul 25, 2017 •

edited

Loading

PieterGit commented Jul 26, 2017 •

edited

Loading

scottleibrand commented Aug 12, 2017 •

edited

Loading