Allow deviation from original oref0

[LiroyvH]

First and foremost, important note: I CANNOT currently check what happens in Trio as I just started on U-200 testing (and are thus above 1:3 again) - sorry! I also don't have the logs anymore, its reset. I have solely looked at the code whilst I was working on something else related to U-200 and caught this by coincidence. I have thus NOT been able to gather log output and behavioral analysis interim. Therefore I'm not 100% confident this is an issue in Trio currently, but based on the changes made to the code I believe it is (or will be in 1.0) based on how it caused issues in iAPS in the past and how the algorithm actually wishes to behave when its a 1:1 copy of the original source. The feature request below therefore assumes this is indeed happening.

Is your feature request related to a problem? Please describe.

The original design of oref0 put a hard cap on carb ratios of 1:3 as it was deemed to be "impossibly low". The limitation was introduced to prevent bad conversions from mg/dl to mmol/l leading to issues. However, myself and what I consider a non-negligible amount of other users have an insulin resistance that requires lower carb ratios to be set; its very far from impossibly low. :) Whilst the app allows it, the algorithm won't; which leads to unexpected behavior/issues and wrong interpretation of insulin-profile changes. I remember in iAPS this simply caused oref0 to ignore anything lower than 3 and pretended it to be 3 instead (leading to unexpected behavior in the app) and this was subsequently patched in the local (to iAPS) implementation of oref0.

Trio initially included this "bugfix", but it appears (see disclaimer above) that this has been rolled back.
I gather that from reviewing these particular pieces of code in the Trio repository:
https://github.com/nightscout/Trio/blob/dev/trio-oref/lib/profile/carbs.js#L16-L19
And these in the trio-oref repository of which I assume it may be used in the future:
https://github.com/nightscout/trio-oref/blob/dev/lib/profile/carbs.js#L16-L19
https://github.com/nightscout/trio-oref/blob/dev/bin/oref0-meal.js#L81-L85
https://github.com/nightscout/trio-oref/blob/dev/bin/oref0-autotune-prep.js#L83-L91

Describe the solution you'd like

It'd be nice if Trio offers a way to overrule this limitation, if needs be with a warning, so the system will honor the setting. I think capping the ratio to 1:1 should be fine (no lower fractions) and is reasonable. However, it could be designed in such a way that 1:3 is the default cap and a specific override is required to overcome the limitation. The improvement in experience would be that on U-100, the system actually doses sufficient insulin to cover the carbs.

Describe alternatives you've considered

Change it in oref0. But that's not possible/is dismissed as an option as the developers:
a.) are not quite sure anymore what the issue was that lead up to this implementation (other than the very educated guess about mg/dl -> mmol/l conversion sometimes leading to issues in a past implementation) as it was implemented a long time ago,
b.) note that there are insufficient reports of diabetics that are experiencing complications from this limitation (I was the first to notice and report it) and that there are thus likely only very few diabetics with such a low I:C-ratio. (Though I'm not sure if many people would actually notice that this may be at the core of issues they could be experiencing; in iAPS for example it was just a note in the log that oref0 was capping it to 1:3; you wouldn't notice a thing in the UI, but you would notice inexplicable suggestions. (The bolus calculator I believe was affected by it, until it got... reworked.))

The openaps developers therefore recommend making local changes to the algorithm/implementation as needed instead of modifying oref0 as a whole. Hence why I'm suggesting to have Trio offer a local override to this safety cap in accordance with this suggestion. :)

If there is no desire to cater to people with very high insulin resistance in the default featureset: then another alternative to consider is to at the very least then offer a clear instruction or other (automated) means to patch the code/build Trio with this safety cap lowered to 1:1 or even 1:0.5.

Additional context

Discussion on changing it in oref0: openaps/oref0#1453

Technical Details

oref0 implementation must be modified/have an option to override the values for "impossible" values.

User Impact

The app and algorithm would continue to function as expected even whilst having an I:C lower than 3. This helps people with high insulin resistance. Whilst I understand the vast majority of Type 1 diabetics do not have such a low I:C, there are those of us who do and there is a growing interest in insulin pumps among Type 2 diabetics who may also benefit from accepting high insulin resistance features.

I have not analyzed whether or not there are similar caps for ISF, but I had not directly found any.

Thanks for your consideration.

[MikePlante1]

Sorry I don't have much to add, but I'll just mention that the bare minimum "solution" has been implemented in Trio v1.0, as there is a guardrail that limits setting your carb ratio to a minimum of 3.0 g/U. If oref does get altered to allow a stronger ratio, then that guardrail will of course be lowered to match the new minimum allowed by oref.

[LiroyvH]

@MikePlante1 Good, at least that makes it so people actually know what's happening on that end. :) However, that only remediates the issue of being able to set values that are incompatible with the default version of oref0. It'd be really nice if there is a feature that can overrule this, which affects both the I:C you can set (like you mentioned) as well as modifying the couple of places where this is enforced by oref0 to be more lenient. Or otherwise at the very very least provide a clear set of instructions in the documentation (and perhaps readme) on how to change this in a personal clone or perhaps make a separate branch that removes this, rather arbitrary*, limit and allows for lower values. (Eg 0.5 to 1.0 being no problem). There are several ways to do it, but doing it I think is very important to a group of T1D users with high insulin resistance as well as a significant chunk of T2D's. I understand it may be a small (albeit growing) group, but its an extremely small change that can make 'em happy.

_{* = the choice for 1:3 feels arbitrary to begin with, and the AT portion of the code aiming for 1:2 makes it more confusing where these numbers come from.}