Carbs Absorption Calculation (for discussion)

[Philoul]

I noticed updates in dev branch concerning Carb absorption calculation that leads (according to me) to wrong COB values or wrong decay of carbs when we use algo with variable Sensitivity (could be DynISF plugin or latest PR with AutoISF aligned with interfaces with APS plugins...

Previously, profile values were used to calculate COB, but now within IobCobOref1Worker, the sens value taken to calculate everything is Variable ISF if aps?.supportsDynamicIsf() is true

But currently the equivalent concerning aps?.supportsDynamicIc() is always false (currently not implemented nowhere neither within DynISF variant of APS algorithm, nor in AutoISF algorithm.... => So on request (see line 207 in code below) profile.getIc(bgTime) will allways return profile IC value, when sens will allways get variable value calculated by DynISF algo (or AutoISF algo) (so this value can be much higher or lower than ISF value defined within profile for the same timeslot...

Considering that all variable APS algo reduce ISF value at high BG (to be more aggressive) and increase ISF value at low BG (to be less aggressive), that will lead to a Variable CSF value (ISF/IC) but for me in the wrong direction... => CSF will be lower at high BG (so carbs absorption will be accelerated, so will lead to lower COB results compared to a Fix CSF value due to profile only). I confirm on my side each time I was high with DynISF , COB decay is faster and UAM is detected (I stoped to use DynISF for this reason because ISF was always half the amount of my profile that works well) => CSF at low BG will be higher, so that will reduce carb absorption speed, so remaining COB will be higher compared to a fix CSF value due to profile only)... (I saw some screenshots in Discord with huge amount of remaing COB far from latest meal, associated with ahuge value of dynamic ISF and a low BG value)

Note that the Carbs absorption speed will be increased or reduced even when min_5m_carbimpart is used as security feature

This could lead for me to an over estimation of COB at low BG (so potential too strong calculated correction of remaining COB), and an under estimation of Carbs at high BG (so lower associated insulin, or increase unanounced meal detection when COB is down to 0) => I think we should probably consider CSF as a main parameter defined by user within profile (could be through IC and ISF values defined within profile), and not vary CSF according to bg value (or any other dynamic features of APS algo) to get same COB decrease speed whatever the level of BG vlaue

[vanelsberg]

I think we should probably consider CSF as a main parameter defined by user within profile [...] to get same COB decrease speed whatever the level of BG value.

Good observation @Philoul! Yes, this fully matches my experiences with Dynamic ISF which I stopped using (I gave up after trying at least 3 times) because it absolutely does not work for me, i.m.h.o. mostly because of this.

For as far as I can see, there is no reason why CSF should vary on sensibility (rather than a fixed value derived from profile)

[lostboy86]

Same for me, for longest decay of COB. plus a strange auto-increase of a COB value sometimes

[parapenT1sta]

For me becomes even stranger when using E-Carbs

[gerison77]

I therefore switched back to weighted average sensitivity because decay of carbs is calculated differently. I just now give it a testrun with dynisf since I quitted it immediately after the first try in oref.

[Philoul]

I continue a bit more my formula analysis on this topic (see screenshot below),

So according to formula (don't hesitate to correct me if you think I made a mistake), variable ISF will have an impact on Carb absorption only if BG value change (rise of BG value) and when DEV is below min_5m_carbimpact: Carb Absorption speed will be higher when ISF is lower.

Carb absorption speed is not modified when BG value is constant between 2 BG readings and DEV is above min_5m_carbimpact (so with high insulin activity after the meal if BG value doesn't increase...)

Finally min_5m_carbimpact threshold is also impacted by variable ISF (a lower ISF value will generate more min_5m_carbimpact)

[Philoul]

That said, if average variable ISF value is close to profile ISF, this will probably not have a huge impact on carb absorption speed, but if variable ISF is much higher, (or much lower) than profile ISF, then impact on Carb absorption can be important:

• if average variable ISF is much lower than profile ISF: then you will have more min_5m_carbimpact, and after a meal (increase of BG value and high insulin activity), then COB reduction will be very important (it's exactly my situation with DynISF, meal Carbs can be down to zero in less than 1h or 1h30 after a meal, my DynISF is about Profile ISF/2 on target and can be Profile ISF / 3 at high BG). This can lead to an under estimation of remaining COB so can reduce insulin correction due to COB at high BG.
• if average variable ISF is much higher than profile ISF, you will have less min_5m_carbimpact, and an important reduction of COB speed, even with min_5m_carbimpact (this can be critical if BG don't rise after the meal, because COB will be overestimated...)

[gerison77]

I am really glad, that you took up this issue. I made myself an excell sheet in which I can set CSF and calculate any combination of ISF and IC in order to get the same carbs decay in AAPS over my wohle circadian basal rate. It was much effort and the results not satisfying.

Is I wrote above I switched now to DynISF with weighted average sensitivty and I am impressed how good this works. I announce carbs though.

I hope the calculation of COB decay can be solved; since I would like to use UAMs as well, wich is not possible with the current sensitvity detection method.

[szantos]

@Philoul thanks for pointing it out! That is the main reason, I'm still using an almost 1 year old customized dev build.

I'd like to underline following security issue: After a meal bolus, when BG stays low, COB decay is too slow, and COB remains high. When IOB decays, the algo thinks, there is not enough IOB for all that COB and it will overdose.

[Philoul]

@szantos see https://github.com/nightscout/AndroidAPS/issues/3406 that could also be a idea linked to your cob decay issue...

[MilosKozak]

let's try this https://github.com/nightscout/AndroidAPS/commit/a513b657e2aab4e290847b6ce2945d88888f2044 available in 3.3.0-dev-c

[vanelsberg]

let's try this a513b65 available in 3.3.0-dev-c

Not OK. AAPS is constantly alerting on not enough TTD (which is not relevant for AutoISF) See my comments on the commit?

[Philoul]

@MilosKozak I like the idea of 24h average (ISF) for carbs absorption calculation. Do you think we could do the same for IC with 24h avg IC ? Several users have circadian profile for IC value for bolus calculation, but this leads to variation of carbs absorption speed 🤔...

[MilosKozak]

i think it's correnct but if you have (and take) IC from profile it doesn't make sense to calculate average

[Philoul]

Even if you have important variation of IC values within the profile? (for example in my profile IC value to manage breakfast is more than 40% lower than IC to manage lunch or dinner...) 🤔

[szantos]

IMHO a lot of people need lower IC for breakfast - me too. The most extreme case I've came across is a child who has 3-4x lower IC for breakfast, than for dinner (with similar meal composition).

But the amount of insulin is only one thing. The other one is the absorption speed (or the absorption speed of meal vs the insulin effect). In the morning, meal absorption seems to be faster (or insulin slower, or both).

Although the main purpose of tuning IC and ISF is not to model meal absorption speed, but their combination affects it. It would be nice to have a tool to model meal absorption speed variation throughout the day, for people who struggle with this phenomenon.

[vanelsberg]

...main purpose of tuning IC and ISF is not to model meal absorption speed

Yes. In my case I try to tune IC/ISF so I get to target with when taking carbs. In general this works as expected. Problem there is my ISF show extreme variations during the day and depend on "the day" (e.g. food, activity, sick, cold, etc)

Autosense helps but in general it can't keep up with variations - so most of te timedoes not get practical results :-| Worse: having a fair IC/ISF combination almost always leaves me with carbs absorption being too slow or too fast.

Would be nice to be able to set carbs absorption independent from IC/ISF (either a fix value or percentage of IC/ISF)?

[Philoul]

I think Carb absorption cannot be completly disconnected to ISF and IC Within the overall model CSF, ISF and IC are linked together, CSF=ISF/IC...

I know we can have huge variation in IC or ISF values during the day.

My understanding (but I can be wrong) was that Carbs absorption speed was much more stable during the day compared to IC or ISF values...

In latest dev (future 3.3 😉), 24h average ISF is calculated for DynISF (and AutoISF) APS algo only, and we still use Profile IC to calculate CSF (directly linked to carbs absorption...). => Carbs absortion speed variations due to ISF variations has been reduced a lot, but still remain variations due to IC values set within profile...

And if you use OpenAPS SMB or AMA, carbs absorption is calculated from profile circadian values, so can have important variations too.

So we have 2 questions (and/or) solution...

1. should we calculate a 24h avgCSF (combination of 24h avgISF and an 24h avgIC) and get a quite stable CSF value used for Carbs absorption speed within DynISF/AutoISF algo (Whatever variation of ISF due to algo and variation of IC set in profile) ?
2. should we extend avgCSF to OpenAPS AMA and/or OpenAPS SMB to calculate carbs absorption (so constant CSF value during the day for these APS algo, instead of variable CSF value linked to circadian ISF/IC values set in profile) ?

[ga-zelle]

During the last 4 years I never announced carbs and left it to AutoISF to issue appropriate SMBs. Nevertheless, this is an interesting discussion. Regarding average CSF you cannot use the ratio of average ISF and average IC - mathematically wrong. You would need to track CSF per loop and calculate that average.

For exercise and test you can do it sort of manually. The AAPS emulator delivers a table of key values per loop like profile and modified ISF. IC and CSF are currently not included. But as further output there is also a text file which contains these like shown in the AUTOISF tab's script debug section. From there they can easily be extracted and pasted into a spreadsheet and appended to the standard table. There you have all numbers required to test your favorite theories.

[Philoul]

@ga-zelle The objective of this proposal was to have carb absorption speed constant (or with slow variation according to slow variation of average IC, average ISF or average CSF) So the difference mathematically between Ratio of Average Values and Average of Ratio Values is probably small (second order), and probably not better or worse than using an average ISF instead of loop ISF...), what is important I think is to have a stable CSF value (if of course we consider that Carbs absortion should be more stable compare to IC or ISF variations during the day...)

[ga-zelle]

@Philoul Yes, my proposal with the emulator was about easily creating a real world data set. You can then see which method provides the optimal CSF. You can even feed it back into the emulator to check resulting changes in insulin delivery.

It is so interesting I am keen to spend time and support you with the emulator.