scottleibrand
commented
6 years ago (For purposes of this response, I'm going to focus on oref0 0.6.0-dev, although much of this applies (with modifications) to 0.5.x and earlier as well.)
OpenAPS behaves the same as Loop in terms of only correcting the assumed timing of future carb absorption based on past carb absorption, not changing the total amount. OpenAPS starts with a weaker assumption about projected carb absorption, because it does not ask the user to input a more precise estimate of carb absorption time, and instead initially assumes a bilinear /\ shaped carb absorption curve with a total duration of 3 hours. As soon as we see carb absorption, we assume that it will continue into the future, linearly decreasing to zero over however long it takes to absorb the remaining COB. (That sounds similar to your "project with decay" scenario, except that it only applies to how fast the remaining COB absorbs, not what the remaining COB actually is.) If the projected time to absorb all the remaining COB is more than 3 hours + 1.5x the time since the last carb entry (which usually happens before absorption ramps up, or if it slows early for some reason), then the remaining carbs not projected to absorb in time are overlaid using the bilinear /\ shaped carb absorption curve.
In addition, OpenAPS calculates multiple predicted BG "scenarios" and incorporates predictions from more than one of them in a blended manner. For some of the predictions this is somewhat analogous to the way Loop uses RC and momentum, but for the one most relevant to carb absorption, called UAM (for unannounced meal) it is somewhat different. UAM is now largely used to provide a "second opinion" on predicted carb effects for meals that are actually announced, but whose carb counts may be imprecise or inaccurate. UAM uses solely the last ~45m of deviations (BG deltas compared to insulin-only effects), and extrapolates how such deviations will continue into the future based on the recent deviation trend. If the current deviation is lower than the highest recent deviation, it assumes that deviations will continue to decrease at the rate they have been decreasing since that time. When deciding how to dose for predicted BGs, OpenAPS blends the COB BG predictions with the UAM BG predictions according to what percentage of entered carbs remain as COB. So when 90% of carbs have been absorbed, the original carb count, and resulting COB-based BG predictions, are only used for 10% of the decisionmaking, and UAM is used for the other 90%.
Hopefully that helps - let me know if you have any other questions about how OpenAPS handles any particular scenario and I'll be happy to answer them, but hopefully without hijacking the entire thread.
jeremybarnum
dm61
None of the two look like rectangles or triangles (although a triangle could apply perhaps to the first fast CA case). The snapshot is taken in the middle of the second CA (a large mixed lunch). It's pretty clear that Loop's CA prediction is somewhat below the actual future CA. This could be addressed, for example, by applying the RC/momentum approach to the CA curve itself (while still keeping the total area under curve equal to the carbs entered), thus providing a longer-term corrective impact on BG predictions, and offloading the main Loop's RC/momentum mechanism that would still handle short-term unmodeled effects. 
Kdisimone
github-actions[bot]
This is a thread to trigger brainstorming on potential next generation carb absorption prediction algorithms.
The current dynamic carbs algorithm accepts a carb input from the user with a specified absorption time. From that user-entered data, it calculates an absorption rate. (For simplicity, this discussion ignores the issues discussed in #577). The initial prediction is based on this absorption rate. Then, as the actual BG develops, Loop computes the actual absorption of carbs by comparing insulin-only effects to observed BG changes. The carbs actually absorbed are deducted from the carb entry and the remaining carbs are projected according to the original computed absorption rate. This makes the prediction much more responsive to real world observations, rather than user input and mathematical decay assumptions. It has significantly improved results for Loop users.
This approach means that if carbs are absorbed faster than expected, the end-point of carb absorption is sooner; and if slower than expected, the end-point is later. Implicitly, this assumes that the original carb input is exact, because any differences between expected absorption and observed absorption are attributed to the absorption time, rather than to the number of carbs consumed. This is the natural choice where the meal in question allows for exact carb counting. (Of course, momentum and RC do a lot to capture carb counting errors as a sort of "second line of defense" - but here I'm focusing exclusively on the algorithm for the carb absorption itself)
However, in situations where exact carb counting is not possible (call it "party mode" - I'm picturing social restaurant dinner where an accurate carb count could be challenging) it's easy to see that you might want to allocate some of the the observed deviation to carb counting error, rather than 100% to absorption time estimate error. Just for the sake of argument you could pick 50% to absorption time, and 50% to carb count error.
So assume a 30 gram carb input with a 3 hour absorption. Expected absorption over the first 60 minutes is 10 grams/hour. Assume that observed absorption is 20 grams in the first hour. The excess is 10 grams over an hour. Allocating 50% to absorption time would mean that 5 grams of the 10 gram "excess" is just faster-than expected absorption. But the other 5 grams of "excess" could be associated with undercounting carbs.
Then you have some choices, from least to most sensitive, about how to project the 5 grams associated with carb count error:
-no projection. Only observed deviation affects original input assumption. Original input is now assumed to have been 35 grams, with 20 grams absorbed over the first hour, and 15 remaining, which are decayed at the original absorption rate of 10g/hr, so the end of the absorption is in 1.5 hours. But as a result of the increase in the assumed carbs inputted, there will be high temping to cover the extra carbs. Momentum and RC will do some of this as well, but this would make it more aggressive.
-project with decay - for example 1 hour. Observed absorption is 15g/hr, project this forward decaying back to 10g/hr for an hour, averaging 12.5 g/hr for the next hour, and then back to 10g/hr. This would imply the original entry was actually 37.5 grams.
-project without decay. Scale up the entire assumed original carb entry by the observed deviation - so in this case the entry is assumed to have actually been 45 grams, instead of 30, because after allocating 50% of the deviation to carb counting error, the observed absorption rate is 50% bigger than the inputted one.
-The most extreme case would allocate 100% of the deviation to carb counting error and project the sample without decay. In this case, observed absorption is double the expected absorption, and so the carb input is assumed to be off by a factor of 2 - so it increases to 60 grams. Or, put differently, the remaining carb absorption is assumed to be 20g/hr, as observed, rather than 10g/hr, as inputted. That would increase the prediction by the excess of 10g/hr over 2 remaining hours, or 20g total - leading to pretty aggressive high temping. Conversely, if the absorption rate observed is much lower than the input implies, this would lead to more aggressive low-temping that the current factor of 1.5 produces in calculating the minimum absorption rate.
In addition, the observation time window can vary - trailing 15 minutes, trailing 30 minutes, etc, time from the consumption of the carbs, etc.
This approach requires us to have rules for a valid sample. Probably best not to make big decisions until there is some reasonable data (15 minutes of absorption after the first 10 minute delay?) but don't wait too long either. Some of this is already in Loopkit for calculating momentum.
There also need to be some safety parameters, and these should probably be asymmetric, but also configurable, probably in the code not the app, to make it a bit harder for people to get carried away with aggressiveness.
One example is max carb counting error. So, if the user selects uncertain count, and observed absorption is (for example) 3 times the inputted carb absorption, the assumed carbs consumed that would be high-temped against wouldn't exceed (for example) 2 times the inputted amount.
When absorption is much slower than expected arguably it is conservative to let this flow though, and lead to carb expiry rate that it is much faster than 1.5*input. In effect, this will start zero-temping earlier where, for example, a meal is not consumed after a bolus is taken. But for a variety of reason (GP, etc) people might want to configure this behavior differently.
It's worth noting that I believe the OpenAPS approach behaves somewhat this way - i.e. it dynamically changes the prediction of total carbs expected to be absorbed (as opposed to just the speed of absorption) in a fairly sensitive way as a function of the recently-observed carb absorption trend.