oref0
oref0 copied to clipboard
openaps
Autotune: support ISF and IC ratio schedules
Currently, autotune uses and tunes a single ISF and IC ratio. Some people use different ratios over the course of the day. It might be useful to support tuning different ratios for different times of day (if they're already different in the pumpprofile). Would need to figure out which data to attribute to which time of day, and make sure we have sufficient data for each schedule entry before making any changes. (For days when we don't, it may make sense to change all of them together.)
Can we deprecate the single ISF and IC ratio value in profile.json altogether, so it's impossible to actually use the single values as opposed to actually getting the correct value from the profile?
Not sure how you'd make it impossible for me to just use the 0th item in the array like I did to get autotune working quickly. I don't think there are any shortcuts here: someone just needs to volunteer to do the work.
Getting the right value is a one-liner; profiledata[] vs profile.isfLookup(profiledata,date). It'll be pretty easy to make that even cleaner (profile.isf(date)). Not sure why I'd want to make direct data access impossible as such; I mean this more in the lines of "how about we implement a simple to use API to get the right values right from the get go and deprecate the old method of getting profile data that doesn't work for most OpenAPS users".
Ok, that sounds like a good idea. It wouldn't address the topic of this issue, though, which is that figuring out how to properly tune multiple ISF and CR values is quite a step up in complexity from tuning just one.
Does anyone use ratios that are different enough at different times of day that you'd be motivated to help me implement ISF/CR schedules in autotune? I've never actually seen such a use case up close, so I'm not sure I can design for it properly.
I'd probably want to start with some retrospective autotune runs against NS data from someone using multiple profiles, see what autotune is suggesting given the different starting points, and then see if we can segment the data in a way that seems to make sense...
Hi Scott,
I am happy to test - I use multiple profiles. Only challenge may be that since I am in Stockholm I am a few hours ahead of you.
Regards,
John Sjolund
On Tue, 07 Feb 2017 at 04:55 Scott Leibrand
< mailto:Scott Leibrand [email protected]
wrote:
a, pre, code, a:link, body { word-wrap: break-word !important; }
Does anyone use ratios that are different enough at different times of day that you'd be motivated to help me implement ISF/CR schedules in autotune? I've never actually seen such a use case up close, so I'm not sure I can design for it properly.
I'd probably want to start with some retrospective autotune runs against NS data from someone using multiple profiles, see what autotune is suggesting given the different starting points, and then see if we can segment the data in a way that seems to make sense...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, https://github.com/openaps/oref0/issues/326#issuecomment-277894670 , or https://github.com/notifications/unsubscribe-auth/ARJyV-rfs6mqVueqVebJko6S8aKskfcBks5rZ-sugaJpZM4LeyvY .
Great! Hit me up in Slack #dev this evening your time. I believe @cjo20 will also be on.
Is this ticket about supporting different ISF/IC ratios for different times across the day, or is it about supporting multiple profiles (where each profile is a set of values for different times across the day)?
We would probably want to implement it to support the data as stored by the pumps and decoded by commands like openaps use pump read_insulin_sensitivities and openaps use pump read_carb_ratios (and bundled into a profile.json with openaps use get-profile). The profile.json already displays a schedule for ISF, if you have one. There is also a separate schedule for CR in carb_ratios.json, although I'm not sure if profile.json preserves the entire schedule if present, or just uses the current value. Autotune currently just ignores the fact that there is a schedule, and use/tune the midnight profile entry. The main challenge for me is figuring out how we want to do the algorithm piece: what data should be used to tune which ISF, and what we do when we have data that could apply to more than one entry in the schedule.
@jasoncalabrese has his rig repos public, so you can see the full profile.json format at https://github.com/jasoncalabrese/indy-ex2a/blob/master/predict/profile.json
@scottleibrand : i also am volunteer for testing ISF and IC schedules. What can we do to help you get this implemented?
We're headed for Maui today, so I might have to rely on you to do a bit more of the work for the next couple weeks. I was thinking we'd want to manually update autotune.sh to pull in data for the different times of day covered by your different schedules for different runs. So if you had one schedule for breakfast and lunch, and another for dinner, you might do one run that only considered data from 4am to 4pm, and see where it tunes your ISF and CR, and then modify autotune.sh to pull in data form 4pm to 4am, and run it again. I'd like to see if autotune converges on different ISF and CR's for the different timeframes, and if those match what you have set manually...
Hi, Has there been made any progression in regards to multiple cr/isf? Is there some testing help needed?
@scottleibrand : Volunteering for multiple profiles testing and contributions. What do you need?
I would really like to see this feature developed as I have multiple carb rations and struggling to work out changes required which is proving frustrating. Is anyone working on this? Would be pleased to help test.
At the moment I've been running the existing Autotune and changing the first carb ratio in the NS profile each time and then trying to work out the changes for each time of day with mixed success. As a starting point, would it be a case of trying to develop autotune to just consider the meals relevant to each ratio rather than applying the single ratio to everything? I'm considering removing the other treatments from my Mongo DB but would it be easy for test purposes to modify the autotune code so that it only considers treatments with specific text in the Notes column? That way we could run it for testing, ensuring that just the carb and insulin entries which contain specific text are considered. Thinking even more forward... perhaps we could even record the ratio that is being used in the Notes column and have Autotune apply that? I'm not a coder but happy to help with this in any way I can.
I've used autotune on and off over the past few months just to see what it would suggest. Today I think I updated oref0 to 0.5.5 (I downloaded the zip file, went to the oref-0.5.5 directory, and typed make, then I went into the bin directory and ran ./oref-autotune.sh... Is there a way to check what version I'm running?). My son has different IC ratios over the day, from 13 at breakfast, to 20 at lunch, to 24 at afternoon snack time to 30 at dinner. To run autotune I always put an IC ratio of 24, which lies more or less in the middle. I've seen the following suggestion given by autotune consistently: reduce basal from about 18:00 till 22:00 and reduce IC ratio from 24 to 20. We have tried doing something like this in the past, and what happens is: If we give insulin at dinner with an IC ratio lower than 30 his BG starts dropping shortly after having eaten dinner and he has low BG about 1 to 2 hours after dinner, and if we reduce basals from 19:00 till 22:00, from about 22:00 till midnight or sometimes even later than that, his BG spikes well above 300. I have the feeling that autotune would give better suggestions in my son's case if different IC ratios were taken into account by the algorithm. I'm not sure I'm skilled enough to contribute with coding, but I'd be happy to test anything you can send my way. Thanks!
I too would love to see this developed. My son has his diabetes managed by a paediatrician, and he has multiple carb ratios set across the day. Whilst he is a smart guy, I don't think he is a data scientist, so have this capability developed in autotuned would be great to help me optimise my sons pump settings...….
I've been thinking about this for a bit. I wonder whether the way to do it is to run autotune multiple times, using each of the scheduled ISF and CRs then at the end of the final run, take the first run, copy over the top from the next run at the point the schedule changes, and so on, which should give you 24 hours with each setting.
Whilst this would be fine on the Edison's, on the Pi0W it will take quite a long time.
It looks like work on this has stalled through lack of interest/people able to do the dev work. I certainly have an interest in this since my ISF and CRs vary quite significantly through the day (ISF between 25 and 57, CR between 5.8 and 11 based on my current settings). I definitely find it challenging to use the output from autotune when presented as a single average value for each.
I'm not very skilled as a developer but I'm pretty good when testing, if people have developed the code and want it testing. I'm more than happy to help revive this if there's still any interest. I'm in France.
@guydavies likewise I'm happy to help with any testing as well. Similar to you my carb ratio fluctuates throughout the day.
It is a bit cumbersome to select which ISF to use as the input and also not an easy choice for the end user. I do find this a bit frustrating myself.
Anyway, I'm also happy to help if I can. I'm an experienced coder in other languages but can hack small changes to javascript. In reality I'd probably be better off producing some pseudocode for someone else to refine though.
One "quick and dirty" workaround would be to run autotune once for each ISF setting and then apply the relevant recommendation back against each ISF slot. However, I don't think this would fully take account of the impact of the previous or next hour's settings so there my some iteration required if you wanted to take this approach.
To do it properly probably requires a but more finesse. I don't know if there are any notes on how the current algorithm works from a technical perspective or what the logical structure of the code is. It seems from an initial scan of the repository that most of the logic is done in oref0/lib/autotune/index.js (but maybe I am wrong) and the comments are reasonably good in there. Also, I presume the exact same logic is used by autotuneweb?
At a very high level, presumably when doing iterations of calculations then we should really use the one that is relevant for that time slot and calculate potential new ISFs in similar slots. That sounds a bit simplistic but it seems there is an array of hourly basals used and tuned so ISFs could be done in a similar way.
Just as an example, here are our current ISF settings: 00:00 - 01:00 : 5.6 01:00 - 04:00 : 7.0 04:00 - 07:00 : 6.5 07:00 - 08:30 : 6.0 08:30 - 11:00 : 5.5 11:00 - 15:00 : 5.0 15:00 - 21:00 : 8.0 21:00 - 24:00 : 5.0 Normally if there is a specific part of the day we are having issues with then that is the ratio we will select to be used.
So, let me know if there is still interest in this issue and maybe a few of us might collaborate on a potential solution.
I wonder whether that's the right way tondo this.
We make an assumption that ISF varies in a fairly linear way, however, with autotune's 5 minute bucketed data, you can review 5, 15, 30, etc mins and determine actual deviation for IOB, which should give you an ISF.
Bucketing that into useful increments then becomes interesting, as in, how much variation matters to apply to a point in time, and which point in time should that be? Is it worth applying a 10% change, for example?
Could you implement a simple model that follows the standard hourly structure we're used to that simply picks the most commonly calculated ISF value per hour and implements that in the schedule?
Or would it be better to look at the distribution of values in a range and determine when they change out of each bucket?
Just trying to think about how we might systematically determine ISF values via Autotune, and then use that mechanism to determine them throughout the day.
There's always a caveat with this, which is that during the day, significant portions of data are lost to carb/food heavy periods, where it's nigh on impossible to easily separate out the effect of carbs versus underlying sensitivity.
That last caveat is key. It makes all these ideas unworkable: there’s simply not enough clean data during a day that is dominated by ISF without being contaminated by carb absorption to be able to make solid conclusions about how it varies hour to hour.
We should instead start with autotuning a separate carb ratio for each meal. That is quite straightforward, as the CR calculations can be done independently for each combination of carb entries with overlapping absorption. So each day that one meal’s absorption stops before the next meal starts, you can calculate those meals’ CRs independently.
I think this discussion could be easier if we had better data on the perceived resistance curves of people / requirements for the ISF curves. Here's some anecdotal data from us:
Evenings: Looking at the ISF settings above, it looks quite similar to what our kid's curve is like and matches the anecdotal data I've seen on most growing kids, where the grown hormones cause significant insulin resistance during the evening starting around the time the body expects it's time to go to bed (7-8 PM ish), ending around 1 AM. The dosing need I've seen during this time is up to 2x the dose needed for daytime, with the extra challenge that growing kids are frequently very hungry during the evening and might suddenly decide to eat 3x the usual supper before hitting the bed. It's difficult to know exactly how to dose for these meals as extra hunger typically means lower carb absorption and the evening CR is set higher for us (and anecdotally for others) which in combination with the higher basal rate can cause a low if all the food is bolused fully. Simultaneously with autotune enabled, the ISF is not high (low?) enough to counter the high if the bolus is not correct in the evening.
After the 1AM is resistance is over, the kid is typically very sensitive to insulin from around 2:30 AM to 5 AM (again, anecdotally heard this from many other parents as well) and the change from very resistant to very sensitive is perceived to be extremely fast and the kid can very easily go low around 3:30, so our basal rate for that time is less than half that for the pre-midnight high.
Morning & day: We seem to go through periods of high resistance in the morning to no resistance in the morning, where for the high resistance periods we have a higher basal rate from 6 AM onward to help with the breakfast and try to bolus as accurately as possible. For the more sensitive periods we take down the basal and under bolus for the food a little, given kids who move a lot during the day crash to low more easily than adults. The hard to manage part here is the resistance profile of the morning keeps changing, resulting in the BG trending up toward lunch on some days, causing a postprandial high, while on some days the BG stays level. On the level days, the challenge is afternoon club running about easily causing a low, thus the basal rates (and desirably ISF) being a bit lower during the day, as per the profile set above. FWIW this would be easier if the kids was under adult supervision with a full T1 skillset 24/7, but us and most other parents need to deal with the kid being under lesser skilled maintenance and thus need to try to optimise the profile for daytime where the only tool we have is temp targets.
@sulkaharo Agree with your view on the insulin resistance overnight, super strong after going to sleep (somedays) then from around midnight she becomes very sensitive to insulin (most days) and can be low around 4am (sometimes).
I think this is linked to #977 because our CR is twice as strong at breakfast vs evening dinner which is causing lost/found carbs when the CR changes and it's impacting how the rig manages the corrections, ie 12pm in the afternoon the rig thinks there are less COB than there really is and 12am in the morning it thinks there are more than there really are. The afternoon one i think has caused us some sustained highs mid afternoon.
I'm still new to all this, but once i can get #977 working (i'd appreciate direction on how i can test this one), i would like to work out a way to calculate for multiple CR, as it seems we need to nail CR down before trying to find the differences in ISF.
Perhaps part of the set up process should be a fasting test for each meal, over the course of a week, to allow the collection of the appropriate data for comparison vs data with COB. This isn't always easy, especially with kids, but would be the quickest way to split the calcs.
There is currently a new plugin in last dev version of AndroidAPS ("Dynamic ISF") that roughly works with last day TDD and last week TDD to calculate current ISF to use in openAPS SMB algo (this ISF value is updated every 5 min). => Could it be another way to calculate Circadian values for ISF in Autotune ?
=> Average value of the 12 Dyn ISF values (one per 5min) for each hour of the day to calculate the 24 ISF values for one day => Average value for all selected days in autotune to get an "autotune circadian ISF"
I don't think it would work just simply doing that; the Dynamic ISF is designed to counter insulin resistance while high. You'd need to be able to determine when the high was caused by incorrectly entering / handling carbs vs because the isf is incorrect for that time of day. This is what Scott was referring to in his comment on 3rd January 2020.
Even if you could completely remove the effect of carbs from the data, you couldn't directly use the data on the dynamic ISF. The dynamic ISF only goes up when your BG is high, so if there were a time period where ISF was consistently too low, the rise in dynamic ISF would only show up when the impact of the low ISF starts to become apparent with a rising BG. But because ISF depends on BG, the ISF calculated by the dynamic ISF doesn't tell you what the ISF should have been 2 hours earlier to prevent the high.
I don't think it would work just simply doing that; the Dynamic ISF is designed to counter insulin resistance while high. You'd need to be able to determine when the high was caused by incorrectly entering / handling carbs vs because the isf is incorrect for that time of day. This is what Scott was referring to in his comment on 3rd January 2020.
Even if you could completely remove the effect of carbs from the data, you couldn't directly use the data on the dynamic ISF. The dynamic ISF only goes up when your BG is high, so if there were a time period where ISF was consistently too low, the rise in dynamic ISF would only show up when the impact of the low ISF starts to become apparent with a rising BG. But because ISF depends on BG, the ISF calculated by the dynamic ISF doesn't tell you what the ISF should have been 2 hours earlier to prevent the high.
Not quite. You're referring to the AutoISF model. The dynamic ISF model adjusts ISF according to all glucose levels, not just when high, and as a result, in theory (and practice so far) doesn't generally result in consequential highs because the ISF is never from the profile, and always calculated.
Hi What do you think of applying average change done by Autotune on circadian ISF and IC ? An average of Circadian ISF (and IC) is done to start autotune Modification is proposed (+/- x%) on ISF (or IC)
Then apply the same % modification on each ISF (or IC) value of Pump profile => I know it's not exactly a "Tuning of circadian variations", but it could be a first step for users that are "Happy" with their circadian variation, and don't use Autotune because of this limitation...
Good or Bad Idea ? possible side effects ?
I'm currently testing an adaptation of Autotune algo as a plugin in aaps, see below a graphical view of "circadian" proposal done last week:
(note french UI, G/I = IC/CR, SI = ISF)
In blue input profile in red tuned profile without or with % application on circandian IC)
