Enhancement: Units edition results

[Gero1999]

Issue

Users would like to be able to choose the units in which the results parameters are displayed.
Closes #113

Description

Sometimes user might be interested in changing the standard format of units provided by the app. In one that this may happen frequently is for example clearance (cl.obs), where current units always make very small values (~0) that can confuse when the rounding is used in the summary statistics.

Definition of Done

• Allow user to customize in results the units of measure for each parameter
• Scale appropriately parameter values based on new unit measures imputed

How to test

How to test features not covered by unit tests.

Contributor checklist

• System to change units in parameters works well before NCA

• System to change units in parameters works well after NCA

• Outputs post NCA still work fine and adapt well to new units (i.e, boxplots)

• Code passes lintr checks

• Code passes all unit tests

• New logic covered by unit tests

• New logic is documented

Notes to reviewer

Anything that the reviewer should know before tacking the pull request?

[Gero1999]

Hello team @m-kolomanski @Gotfrid @js3110 !

I have a small technical problem with this units package. This is a package that I used for the function transform_unit that automatically calculates conversions. This package is also used in PKNCA and @billdenney has also participated in its development.

When the package is installed through non-Windows OS, the installation through CRAN with install.packages() won't work unless a terminal command is run before to install the udunits2 object, as indicated in their README . The problem is that the testing on the remote GitHub-workflow might require this, as it is a Linux system.

There are many potential solutions to this, as the only affected things are the transform_unit function and its testthat testing. However I am not sure what is the best approach to solve it and I would like your input if possible. Here are my current ideas:

1. Add the package units to "Suggests" in the namespace, and only run transform_unit when possible with if (!requireNamespace("units", , quietly = TRUE) (in other cases return NA, which does not conflict with the App, as the user will be asked to manually populate the conversions).

2. Customize somehow the installation for each OS. I know that with R we can request the Sys.info() to obtain all info we need (sysname + perhaps version) to know what action to take before doing the install.packages. However this procedure concerns me, as I am not sure if we require additional permits from the user to do this installation method.

3. Do a new transform_unit function that is independent from the units package that is only intended for the physical units we use (concentration, time, volume, mass). I indeed did something of this in the past using regex, I would just need to refine it and create the tests.

Let me know what you think of them or if you could come up with a better solution and I will try to implement it!

[m-kolomanski]

Hi @Gero1999,

use whatever dependencies you need to use - there is no need to re-invent the wheel if ready solutions are available, and we are not the first to deal with system dependencies, so do not worry :)

In terms of installing the package itself, if installing a dependency (in that case units) fails due to missing system packages, the user is prompted to install those and this is alright - something that I deal with frequently as Ubuntu user. We only need to make sure that the package is present in the DESCRIPTION file. I do not think there are any other concerns, @Gotfrid?

In terms of github actions / workflows, we can install the dependency on the machine that runs the checks, I will get on that.

[billdenney]

I agree with @m-kolomanski, adding the dependency is the best path. Writing your own unit handling will likely be error-prone. (I've done it a few times in the past, and it always has lots of bugs the first time around.) The units package has the side-benefit that all standard unit conversions should be handled for you.

[Gero1999]

I think the feature itself is ready for review. The other conflicts will hopefully be solved once the workflow incorporates the dependency mentioned. Let me know if so far this convince you or you can think of improvements:

Feat characteristics

• Parameter Units button to visualize/modify PKNCA units table present in NCA settings & NCA results
• Modification only allowed on Custom Unit and Conversion Factor columns
• If modifications are done before running NCA then they will apply once is run
• If modifications are done after running NCA then they will apply to the results and to the NCA running
• If in Custom Unit the user introduces an unrecognized unit, Conversion Factor will be NA. If NAs are in Conversion Factor user won't be able to Save Units Table and it will be notified on how to proceed

[Gero1999]

I ended up merging instead of rebasing because in practice seemed less messy to me (I needed way too many commtits when rebasing). Hope is fine! Regarding some aspects of the module simplicity @m-kolomanski, I tried to document better the changes that occur:

1. I did not manage to make them explicit, although now they are implicit for both objects
2. I did not maange to only make 1 server call, because the UI has two input definitions and seems that I cannot repeat the same one two times!

But please let me know any concern with these solutions

[m-kolomanski]

Hey, it looks quite nice, but there are some minor issues to iron out.

The data flow is still a bit confusing, but I think we should fix that in the scope #144 , when modularizing the whole NCA tab.

[m-kolomanski]

issue: this button does not seem to do anything.

[m-kolomanski]

Hey, to me, the code looks good, thank you!

Since this PR touches the nca.R file directly, and we wish to rework it ASAP, there are some minor issues / suggestions that we should create a separate issue for and address within a new PR:

• Bug: the application crashes when a text value is provided as conversion factor;
• Suggestion: If conversion factor returns NA, might be worth displaying something else in the table, as opposed to an empty cell (like *Error or something, to explicitly inform user that there is something wrong).
• Suggestion: Disable the ability to select rows in unit table, as it does not provide any functionality.

[js3110]

Hi @Gero1999
It looks really good! I love the layout especially.

However I have noticed that the nca results are missing a lot of parameters (such as CL clearance) , which is important as this parameter is the main reason we are trying to implement unit changes (for pre clinical)

I have had a check and the parameters are also missing in main, but not in our rsconnect version so it must have slipped through in the #109 merge.
if you can fix it in this issue then great, and if not then lets make a separate issue for this!

[js3110]

Hi @Gero1999 It looks really good! I love the layout especially.

However I have noticed that the nca results are missing a lot of parameters (such as CL clearance) , which is important as this parameter is the main reason we are trying to implement unit changes (for pre clinical)

I have had a check and the parameters are also missing in main, but not in our rsconnect version so it must have slipped through in the #109 merge. if you can fix it in this issue then great, and if not then lets make a separate issue for this!

Looks to me as if this is coming from the interval creation, as if you look at mydata() it is set as FALSE for most of the parameters except for the ones included in the format_pkncadata_intervals function. We want all the parameters to be available, or the user should be able to choose. Currently neither are possible.

[js3110]

I've created issue #168 as it is separate from this issue.

[js3110]

LGTM