There are some inconsistencies in the glucose change graphs on the carbohydrates screen that make it harder to interpret.

I split this into two parts:

1. Inconsistency between views and times - which appears to be a bug affecting the glucose change graph

• dynamic carbohydrate absorption is sometimes shown in the landscape view but not portrait view
• dynamic carbohydrate absorption is sometimes not shown on the left edge of the graph in both views

2. a preference for a static prediction matching the carb entries - which from zulipchat discussion I understand is not expected behaviour, and from reading the code looks like a harder thing to achieve. I guess similar information can be had by reading through each of the carb entries and how absorption is tracking.

To Reproduce
On the home screen tap on carbs on board chart to get to the carbohydrates screen.

Look at the 'glucose change' graph, in particular the 'predicted' glucose change plotted on the graph.

Switch to landscape view. Look carefully at the 'glucose change' graph. In this view the grey glucose change graph is often different and almost completely follows the 'observed glucose change' graph - making the whole graph appear in dark green.

Issue is intermittent and can also appear in the portrait view.

Expected behavior
I would expect:

1. the predicted glucose change to be the same when shown in portrait and landscape mode

I would prefer:
2) a static prediction to be shown in the 'predicted' dataset - i.e. the 'predicted' glucose change to stay the same over time unless the meal entries are updated.
From zulipchat discussion I understand this is not expected behaviour at this point in time - the dataset labelled 'predicted' is in fact Loop's current estimate of the absorption rate of each meal up to the current point in time, which may be either minimum rate absorption or dynamic carb absorption. Note that as dynamic carb absorption equates to the observed glucose change, it gives you limited additional information compared to the observed glucose change dataset. You can see dynamic carb absorption is in effect because the graph looks messy, but can't easily see how this compares to an 'ideal'. A comparison of static prediction with ICE could be quite useful to support reviewing meal entry estimates (size and absorption time).

Screenshots
In the screenshot below the grey/dark green shows a static minimum absorption rate prediction derived from the carb entries. Overlaid on top in light green is the observed glucose effect or Insulin Counteraction Effects.

BC714572-ED9F-446D-A551-53AB5DF35D3E.png

The landscape mode screenshot below, taken seconds later, shows things differently.

Here, the minimum rate absorption estimate does not appear from about 12:20 to 19:38 (the time of the screenshot). It is present in the future. For example, the part of the two charts around 16:00 clearly has different values for the the 'predicted' dataset.

89BFB94D-443B-48AE-ABA9-75CD927154D8.png

Loop Version

• Version Number: v3.2.3
• Repo: Loopkit/Loop
• issue also appears in dev although the code has changed

CGM

• Device: Dexcom G6
• Manager app: Dexcom App

Pump

• Manufacturer: Omnipod Dash

Additional context
Discussion on Zulipchat: https://loop.zulipchat.com/#narrow/stream/144111-general/topic/ICE.20.2F.20glucose.20change.20graph.20display.20inconsistencies

Looks like this graph was originally added along with dynamic carb absorption: #507
But has been modified since, including when non-linear carb absorption (with dynamic effects) was added in Loop 2.0 . This screen is described for that and subsequent versions here: https://loopkit.github.io/loopdocs/operation/features/ice/#glucose-change-display

There are slightly different explanations of what is supposed to be shown on the graph on the two pages linked above.

One describes the 'predicted' dataset as being derived from the meal entries, which I had interpreted as a static prediction which is then compared with the observed glucose change. Elsewhere e.g. on the Open Loop documentation page the graph as a whole is described as displaying 'how the app thinks your meal is being absorbed'.