diff --git a/NEWS.md b/NEWS.md index 21f06815a..1c2f02e45 100644 --- a/NEWS.md +++ b/NEWS.md @@ -23,7 +23,7 @@ # rbmi 1.2.3 -* Minor internal tweaks to ensure compatibility with the packages rbmi depends on +* Minor internal tweaks to ensure compatibility with the packages `rbmi` depends on # rbmi 1.2.1 diff --git a/R/analyse.R b/R/analyse.R index fbf281a58..8c14db88d 100644 --- a/R/analyse.R +++ b/R/analyse.R @@ -96,7 +96,7 @@ #' #' @section Parallelisation: #' To speed up the evaluation of `analyse()` you can use the `ncores` argument to enable parallelisation. -#' Simply providing an integer will get rbmi to automatically spawn that many background processes +#' Simply providing an integer will get `rbmi` to automatically spawn that many background processes #' to parallelise across. If you are using a custom analysis function then you need to ensure #' that any libraries or global objects required by your function are available in the #' sub-processes. To do this you need to use the [`make_rbmi_cluster()`] function for example: @@ -127,8 +127,8 @@ #' a temporary file on the local disk from which it is then read into each sub-process. This is #' done to avoid the overhead of transferring the data over the network. Our assumption is that #' if you are at the stage where you need to be parallelising your analysis over a remote cluster -#' then you would likely be better off parallelising across multiple rbmi runs rather than within -#' a single rbmi run. +#' then you would likely be better off parallelising across multiple `rbmi` runs rather than within +#' a single `rbmi` run. #' #' Finally, if you are doing a tipping point analysis you can get a reasonable performance #' improvement by re-using the cluster between each call to `analyse()` e.g. diff --git a/R/lsmeans.R b/R/lsmeans.R index 62ca80b4d..95ac897bd 100644 --- a/R/lsmeans.R +++ b/R/lsmeans.R @@ -19,7 +19,7 @@ #' ``` #' emmeans::emmeans(model, specs = "", counterfactual = "") #' ``` -#' Note that to ensure backwards compatibility with previous versions of rbmi +#' Note that to ensure backwards compatibility with previous versions of `rbmi` #' `weights = "proportional"` is an alias for `weights = "counterfactual"`. #' To get results consistent with `emmeans`'s `weights = "proportional"` #' please use `weights = "proportional_em"`. diff --git a/R/parallel.R b/R/parallel.R index 356cffd34..d6012400a 100644 --- a/R/parallel.R +++ b/R/parallel.R @@ -1,18 +1,18 @@ -#' Create a rbmi ready cluster +#' Create a `rbmi` ready cluster #' #' @param ncores Number of parallel processes to use or an existing cluster to make use of #' @param objects a named list of objects to export into the sub-processes #' @param packages a character vector of libraries to load in the sub-processes #' #' This function is a wrapper around `parallel::makePSOCKcluster()` but takes -#' care of configuring rbmi to be used in the sub-processes as well as loading +#' care of configuring `rbmi` to be used in the sub-processes as well as loading #' user defined objects and libraries and setting the seed for reproducibility. #' #' If `ncores` is `1` this function will return `NULL`. #' #' If `ncores` is a cluster created via `parallel::makeCluster()` then this function -#' just takes care of inserting the relevant rbmi objects into the existing cluster. +#' just takes care of inserting the relevant `rbmi` objects into the existing cluster. #' #' @examples #' \dontrun{ @@ -54,7 +54,7 @@ make_rbmi_cluster <- function(ncores = 1, objects = NULL, packages = NULL) { # Load user defined packages packages <- c(packages, "assertthat") - # Remove attempts to load rbmi as this will be covered later + # Remove attempts to load `rbmi` as this will be covered later packages <- setdiff(packages, "rbmi") devnull <- parallel::clusterCall( cl, @@ -65,7 +65,7 @@ make_rbmi_cluster <- function(ncores = 1, objects = NULL, packages = NULL) { # Ensure reproducibility parallel::clusterSetRNGStream(cl, sample.int(1)) - # If user has previously configured rbmi sub-processes then early exit + # If user has previously configured `rbmi` sub-processes then early exit exported_rbmi <- unlist(parallel::clusterEvalQ(cl, exists("..exported..parallel..rbmi"))) if (all(exported_rbmi)) { return(cl) @@ -87,7 +87,7 @@ make_rbmi_cluster <- function(ncores = 1, objects = NULL, packages = NULL) { ) } - # Set variable to signify rbmi has been configured + # Set variable to signify `rbmi` has been configured devnull <- parallel::clusterEvalQ(cl, { ..exported..parallel..rbmi <- TRUE }) diff --git a/R/rbmi.R b/R/rbmi.R index a4b569f15..3344417c4 100644 --- a/R/rbmi.R +++ b/R/rbmi.R @@ -1,7 +1,7 @@ #' @description #' -#' The rbmi package is used to perform reference based multiple imputation. The package +#' The `rbmi` package is used to perform reference based multiple imputation. The package #' provides implementations for common, patient-specific imputation strategies whilst allowing the user to #' select between various standard Bayesian and frequentist approaches. #' @@ -11,7 +11,7 @@ #' - [analyse()] - Analyses multiple datasets #' - [pool()] - Pools multiple results into a single statistic #' -#' To learn more about rbmi, please see the quickstart vignette: +#' To learn more about `rbmi`, please see the quickstart vignette: #' #' `vignette(topic= "quickstart", package = "rbmi")` #' diff --git a/README.md b/README.md index 862245fed..f78431ff5 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ status](https://www.r-pkg.org/badges/version/rbmi)](https://cran.r-project.org/p ## Overview -rbmi is a R package for imputation of missing data in clinical trials with continuous multivariate normal longitudinal outcomes. +The `rbmi` package is used for the imputation of missing data in clinical trials with continuous multivariate normal longitudinal outcomes. It supports imputation under a missing at random (MAR) assumption, reference-based imputation methods, and delta adjustments (as required for sensitivity analysis such as tipping point analyses). The package implements both Bayesian and approximate Bayesian multiple imputation combined with Rubin's rules for inference, and frequentist conditional mean imputation combined with @@ -46,7 +46,7 @@ vignette(topic = "quickstart", package = "rbmi") ## Validation -For clarification on the current validation status of rbmi please see the FAQ vignette. +For clarification on the current validation status of `rbmi` please see the FAQ vignette. ## Support diff --git a/man/analyse.Rd b/man/analyse.Rd index 86152c3c7..b69a54400 100644 --- a/man/analyse.Rd +++ b/man/analyse.Rd @@ -110,7 +110,7 @@ exactly which visits have been imputed. \section{Parallelisation}{ To speed up the evaluation of \code{analyse()} you can use the \code{ncores} argument to enable parallelisation. -Simply providing an integer will get rbmi to automatically spawn that many background processes +Simply providing an integer will get \code{rbmi} to automatically spawn that many background processes to parallelise across. If you are using a custom analysis function then you need to ensure that any libraries or global objects required by your function are available in the sub-processes. To do this you need to use the \code{\link[=make_rbmi_cluster]{make_rbmi_cluster()}} function for example: @@ -141,8 +141,8 @@ machine and not a remote cluster. One such optimisation is that the required dat a temporary file on the local disk from which it is then read into each sub-process. This is done to avoid the overhead of transferring the data over the network. Our assumption is that if you are at the stage where you need to be parallelising your analysis over a remote cluster -then you would likely be better off parallelising across multiple rbmi runs rather than within -a single rbmi run. +then you would likely be better off parallelising across multiple \code{rbmi} runs rather than within +a single \code{rbmi} run. Finally, if you are doing a tipping point analysis you can get a reasonable performance improvement by re-using the cluster between each call to \code{analyse()} e.g. diff --git a/man/ancova.Rd b/man/ancova.Rd index 1cbe56b3a..dd5926e22 100644 --- a/man/ancova.Rd +++ b/man/ancova.Rd @@ -80,7 +80,7 @@ In comparison to \code{emmeans} this approach is equivalent to: \if{html}{\out{
}}\preformatted{emmeans::emmeans(model, specs = "", counterfactual = "") }\if{html}{\out{
}} -Note that to ensure backwards compatibility with previous versions of rbmi +Note that to ensure backwards compatibility with previous versions of \code{rbmi} \code{weights = "proportional"} is an alias for \code{weights = "counterfactual"}. To get results consistent with \code{emmeans}'s \code{weights = "proportional"} please use \code{weights = "proportional_em"}. diff --git a/man/ancova_single.Rd b/man/ancova_single.Rd index 774250aeb..61cecb29b 100644 --- a/man/ancova_single.Rd +++ b/man/ancova_single.Rd @@ -49,7 +49,7 @@ In comparison to \code{emmeans} this approach is equivalent to: \if{html}{\out{
}}\preformatted{emmeans::emmeans(model, specs = "", counterfactual = "") }\if{html}{\out{
}} -Note that to ensure backwards compatibility with previous versions of rbmi +Note that to ensure backwards compatibility with previous versions of \code{rbmi} \code{weights = "proportional"} is an alias for \code{weights = "counterfactual"}. To get results consistent with \code{emmeans}'s \code{weights = "proportional"} please use \code{weights = "proportional_em"}. diff --git a/man/lsmeans.Rd b/man/lsmeans.Rd index 7d59c9348..6b763852f 100644 --- a/man/lsmeans.Rd +++ b/man/lsmeans.Rd @@ -40,7 +40,7 @@ In comparison to \code{emmeans} this approach is equivalent to: \if{html}{\out{
}}\preformatted{emmeans::emmeans(model, specs = "", counterfactual = "") }\if{html}{\out{
}} -Note that to ensure backwards compatibility with previous versions of rbmi +Note that to ensure backwards compatibility with previous versions of \code{rbmi} \code{weights = "proportional"} is an alias for \code{weights = "counterfactual"}. To get results consistent with \code{emmeans}'s \code{weights = "proportional"} please use \code{weights = "proportional_em"}. diff --git a/man/make_rbmi_cluster.Rd b/man/make_rbmi_cluster.Rd index 4b7c79bfa..e5456599c 100644 --- a/man/make_rbmi_cluster.Rd +++ b/man/make_rbmi_cluster.Rd @@ -2,7 +2,7 @@ % Please edit documentation in R/parallel.R \name{make_rbmi_cluster} \alias{make_rbmi_cluster} -\title{Create a rbmi ready cluster} +\title{Create a \code{rbmi} ready cluster} \usage{ make_rbmi_cluster(ncores = 1, objects = NULL, packages = NULL) } @@ -14,16 +14,16 @@ make_rbmi_cluster(ncores = 1, objects = NULL, packages = NULL) \item{packages}{a character vector of libraries to load in the sub-processes This function is a wrapper around \code{parallel::makePSOCKcluster()} but takes -care of configuring rbmi to be used in the sub-processes as well as loading +care of configuring \code{rbmi} to be used in the sub-processes as well as loading user defined objects and libraries and setting the seed for reproducibility. If \code{ncores} is \code{1} this function will return \code{NULL}. If \code{ncores} is a cluster created via \code{parallel::makeCluster()} then this function -just takes care of inserting the relevant rbmi objects into the existing cluster.} +just takes care of inserting the relevant \code{rbmi} objects into the existing cluster.} } \description{ -Create a rbmi ready cluster +Create a \code{rbmi} ready cluster } \examples{ \dontrun{ diff --git a/man/rbmi-package.Rd b/man/rbmi-package.Rd index 6deacb293..91889ae1a 100644 --- a/man/rbmi-package.Rd +++ b/man/rbmi-package.Rd @@ -6,7 +6,7 @@ \alias{rbmi-package} \title{rbmi: Reference Based Multiple Imputation} \description{ -The rbmi package is used to perform reference based multiple imputation. The package +The \code{rbmi} package is used to perform reference based multiple imputation. The package provides implementations for common, patient-specific imputation strategies whilst allowing the user to select between various standard Bayesian and frequentist approaches. @@ -18,7 +18,7 @@ The package is designed around 4 core functions: \item \code{\link[=pool]{pool()}} - Pools multiple results into a single statistic } -To learn more about rbmi, please see the quickstart vignette: +To learn more about \code{rbmi}, please see the quickstart vignette: \code{vignette(topic= "quickstart", package = "rbmi")} } diff --git a/misc/do_not_delete.txt b/misc/do_not_delete.txt index a2ee3c45f..afc979e0b 100644 --- a/misc/do_not_delete.txt +++ b/misc/do_not_delete.txt @@ -1,4 +1,4 @@ DO NOT DELETE -This is a flag file whose existance indicates to rbmi that it is running in development mode. +This is a flag file whose existance indicates to `rbmi` that it is running in development mode. Relevant code can be found in R/parallel.R diff --git a/vignettes/CondMean_Inference.Rmd b/vignettes/CondMean_Inference.Rmd index 4df01b458..b0d3d4860 100644 --- a/vignettes/CondMean_Inference.Rmd +++ b/vignettes/CondMean_Inference.Rmd @@ -147,7 +147,7 @@ Once the datasets have been imputed, we can call the `analyse()` function to app ```{r} -# Set analysis variables using rbmi function "set_vars" +# Set analysis variables using `rbmi` function "set_vars" vars_an <- set_vars( group = vars$group, visit = vars$visit, @@ -237,7 +237,7 @@ get_delta_match_refBased <- function(draws, data_ice, references) { cmi <- cmi[, c(vars$subjid, vars$visit, vars$outcome)] colnames(cmi)[colnames(cmi) == vars$outcome] <- "y_imp" - # Map back original patients id since rbmi re-code ids to ensure id uniqueness + # Map back original patients id since `rbmi` re-code ids to ensure id uniqueness cmi[[vars$subjid]] <- idmap[match(cmi[[vars$subjid]], names(idmap))] @@ -269,7 +269,7 @@ get_delta_match_refBased <- function(draws, data_ice, references) { cmi_MAR <- cmi_MAR[, c(vars$subjid, vars$visit, vars$outcome)] colnames(cmi_MAR)[colnames(cmi_MAR) == vars$outcome] <- "y_MAR" - # Map back original patients id since rbmi re-code ids to ensure id uniqueness + # Map back original patients id since `rbmi` re-code ids to ensure id uniqueness cmi_MAR[[vars$subjid]] <- idmap[match(cmi_MAR[[vars$subjid]], names(idmap))] # Derive delta adjustment "aligned with ref-based imputation", @@ -300,7 +300,7 @@ The argument `delta` can be used to add a delta-adjustment prior to the analysis ```{r} -# Set analysis variables using rbmi function "set_vars" +# Set analysis variables using `rbmi` function "set_vars" vars_an <- set_vars( group = vars$group, visit = vars$visit, diff --git a/vignettes/CondMean_Inference.html b/vignettes/CondMean_Inference.html index bfd6a05b9..da5c098bb 100644 --- a/vignettes/CondMean_Inference.html +++ b/vignettes/CondMean_Inference.html @@ -506,7 +506,7 @@

3.2 Impute

3.3 Analyse

Once the datasets have been imputed, we can call the analyse() function to apply the complete-data analysis model (here ANCOVA) to each imputed dataset.


-# Set analysis variables using rbmi function "set_vars"
+# Set analysis variables using `rbmi` function "set_vars"
 vars_an <- set_vars(
   group = vars$group,
   visit = vars$visit,
@@ -682,7 +682,7 @@ 
4.2 Imputation step including cal
   cmi <- cmi[, c(vars$subjid, vars$visit, vars$outcome)]
   colnames(cmi)[colnames(cmi) == vars$outcome] <- "y_imp"
   
-  # Map back original patients id since rbmi re-code ids to ensure id uniqueness
+  # Map back original patients id since `rbmi` re-code ids to ensure id uniqueness
   
   cmi[[vars$subjid]] <- idmap[match(cmi[[vars$subjid]], names(idmap))]
   
@@ -714,7 +714,7 @@ 
4.2 Imputation step including cal
   cmi_MAR <- cmi_MAR[, c(vars$subjid, vars$visit, vars$outcome)]
   colnames(cmi_MAR)[colnames(cmi_MAR) == vars$outcome] <- "y_MAR"
   
-  # Map back original patients id since rbmi re-code ids to ensure id uniqueness
+  # Map back original patients id since `rbmi` re-code ids to ensure id uniqueness
   cmi_MAR[[vars$subjid]] <- idmap[match(cmi_MAR[[vars$subjid]], names(idmap))]
   
   # Derive delta adjustment "aligned with ref-based imputation",
@@ -741,7 +741,7 @@ 
4.3 Analyse

 analyse() will take as the input argument imputations = res_delta_adjust$imputeObj_MAR, i.e. the imputation object corresponding to the MAR imputation (and not the JR imputation).
 The argument delta can be used to add a delta-adjustment prior to the analysis and we set this to the delta-adjustment obtained in the previous step: delta = res_delta_adjust$delta_adjust.

 

-# Set analysis variables using rbmi function "set_vars"
+# Set analysis variables using `rbmi` function "set_vars"
 vars_an <- set_vars(
   group = vars$group,
   visit = vars$visit,
diff --git a/vignettes/FAQ.Rmd b/vignettes/FAQ.Rmd
index d1e72a3fe..df8681e76 100644
--- a/vignettes/FAQ.Rmd
+++ b/vignettes/FAQ.Rmd
@@ -34,7 +34,7 @@ It is intended to be read after the `rbmi: Quickstart` vignette.
 

 
 
-## Is rbmi validated? 
+## Is `rbmi` validated? 
 
 With regards to software in the pharmaceutical industry, validation is the act of ensuring that the software meets the needs and
 requirements of users given the conditions of actual use. The FDA provides general principles and
@@ -44,12 +44,12 @@ validation depends on the entire software stack and the specific processes of ea
 
 That being said, some of the core components of any validation process are the design specification
 (what is the software supposed to do) as well as the testing / test results that demonstrate that
-the design specification has been met. For rbmi, the design specification is documented extensively,
+the design specification has been met. For `rbmi`, the design specification is documented extensively,
 both at a macro level in vignettes and literature publications, and at a micro level in detailed
 function manuals. This is supported by our extensive suite of unit and integration tests, which
 ensure the software consistently produces correct output across a wide range of input scenarios. 
 
-This documentation and test coverage enable rbmi to be easily installed and integrated into any
+This documentation and test coverage enable `rbmi` to be easily installed and integrated into any
 R system, in alignment with the system's broader validation process.
 
 
diff --git a/vignettes/FAQ.html b/vignettes/FAQ.html
index c61c9dc24..6cfd18356 100644
--- a/vignettes/FAQ.html
+++ b/vignettes/FAQ.html
@@ -355,7 +355,7 @@ 
Alessandro Noci, Craig Gower-Page and Marcel Wolbers

 
    
 
  • 1 Introduction
 
      
-
    • 1.1 Is rbmi validated?
      • 
+
    • 1.1 Is rbmi validated?
      • 
 
    • 1.2 How do the methods in rbmi compare to the mixed model for repeated measures (MMRM) implemented in the mmrm package?
      • 
 
    • 1.3 How does rbmi compare to general-purpose software for multiple imputation (MI) such as mice?
      • 
 
    • 1.4 How to handle missing data in baseline covariates in rbmi?
      • 
@@ -371,7 +371,7 @@ 
      1 Introduction
      
 It is intended to be read after the rbmi: Quickstart vignette.
      
 

      
 
      
-
      1.1 Is rbmi validated?
      
+
      1.1 Is rbmi validated?
      
 
      With regards to software in the pharmaceutical industry, validation is the act of ensuring that the software meets the needs and
 requirements of users given the conditions of actual use. The FDA provides general principles and
 guidance for validation but leaves it to individual sponsors to define their specific validation
@@ -379,11 +379,11 @@ 
      1.1 Is rbmi validated?
      
 validation depends on the entire software stack and the specific processes of each company.
      
 
      That being said, some of the core components of any validation process are the design specification
 (what is the software supposed to do) as well as the testing / test results that demonstrate that
-the design specification has been met. For rbmi, the design specification is documented extensively,
+the design specification has been met. For rbmi, the design specification is documented extensively,
 both at a macro level in vignettes and literature publications, and at a micro level in detailed
 function manuals. This is supported by our extensive suite of unit and integration tests, which
 ensure the software consistently produces correct output across a wide range of input scenarios.
      
-
      This documentation and test coverage enable rbmi to be easily installed and integrated into any
+
      This documentation and test coverage enable rbmi to be easily installed and integrated into any
 R system, in alignment with the system’s broader validation process.
      
 

      
 
      
diff --git a/vignettes/advanced.Rmd b/vignettes/advanced.Rmd
index 743b71488..1f18c7bea 100644
--- a/vignettes/advanced.Rmd
+++ b/vignettes/advanced.Rmd
@@ -276,7 +276,7 @@ between the two groups at the last visit with an associated p-value of
 
 # Imputation under MAR with time-varying covariates
 
-`rbmi` supports the inclusion of time-varying covariates in the imputation model. This is particularly useful for implementing so-called retrieved dropout models. 
+The `rbmi` package supports the inclusion of time-varying covariates in the imputation model. This is particularly useful for implementing so-called retrieved dropout models. 
 The vignette "Implementation of retrieved-dropout models using rbmi" (`vignette(topic = "retrieved_dropout", package = "rbmi")`) contains examples of such models.
 
 # Custom imputation strategies
diff --git a/vignettes/advanced.html b/vignettes/advanced.html
index 49fa9171b..6e47d026b 100644
--- a/vignettes/advanced.html
+++ b/vignettes/advanced.html
@@ -670,7 +670,7 @@ 
      4 Efficiently changing reference-
 

 

 
5 Imputation under MAR with time-varying covariates

-
rbmi supports the inclusion of time-varying covariates in the imputation model. This is particularly useful for implementing so-called retrieved dropout models.
+
The rbmi package supports the inclusion of time-varying covariates in the imputation model. This is particularly useful for implementing so-called retrieved dropout models.
 The vignette “Implementation of retrieved-dropout models using rbmi” (vignette(topic = "retrieved_dropout", package = "rbmi")) contains examples of such models.

 

 

@@ -714,7 +714,7 @@ 
6 Custom imputation strategies#>     pars <- list(mu = mu, sigma = sigma)
 #>     return(pars)
 #> }
-#> <bytecode: 0x7f7f2a7523a0>
+#> <bytecode: 0x7f904526d7c0>
 #> <environment: namespace:rbmi>

To further illustrate this for a simple example, assume that a new strategy is to be implemented as follows: - The marginal mean of the imputation distribution is equal to the marginal mean trajectory for the subject according to their assigned group and covariates up to the ICE. diff --git a/vignettes/quickstart.Rmd b/vignettes/quickstart.Rmd index 7dae351cf..c6e23aeb3 100644 --- a/vignettes/quickstart.Rmd +++ b/vignettes/quickstart.Rmd @@ -28,9 +28,9 @@ knitr::opts_chunk$set( # Introduction -The purpose of this vignette is to provide a 15 minute quickstart guide to the core functions of the rbmi package. +The purpose of this vignette is to provide a 15 minute quickstart guide to the core functions of the `rbmi` package. -The rbmi package consists of 4 core functions (plus several helper functions) which are typically called in sequence: +The `rbmi` package consists of 4 core functions (plus several helper functions) which are typically called in sequence: - `draws()` - fits the imputation models and stores their parameters - `impute()` - creates multiple imputed datasets @@ -201,7 +201,7 @@ For `method_bmlmi()`, all the imputed datasets correspond to sets of random impu The next step is to run the analysis model on each imputed dataset. This is done by defining an analysis function and then calling `analyse()` to apply this function to each -imputed dataset. For this vignette we use the `ancova()` function provided by the rbmi +imputed dataset. For this vignette we use the `ancova()` function provided by the `rbmi` package which fits a separate ANCOVA model for the outcomes from each visit and returns a treatment effect estimate and corresponding least square means for each group per visit. diff --git a/vignettes/quickstart.html b/vignettes/quickstart.html index e02d7c2a8..4012b6b24 100644 --- a/vignettes/quickstart.html +++ b/vignettes/quickstart.html @@ -342,8 +342,8 @@

Craig Gower-Page, Alessandro Noci, and Marcel Wolbers

1 Introduction

-

The purpose of this vignette is to provide a 15 minute quickstart guide to the core functions of the rbmi package.

-

The rbmi package consists of 4 core functions (plus several helper functions) which are typically called in sequence:

+

The purpose of this vignette is to provide a 15 minute quickstart guide to the core functions of the rbmi package.

+

The rbmi package consists of 4 core functions (plus several helper functions) which are typically called in sequence:

  • draws() - fits the imputation models and stores their parameters
  • impute() - creates multiple imputed datasets
    • @@ -560,7 +560,7 @@

    4 Impute

    5 Analyse

    The next step is to run the analysis model on each imputed dataset. This is done by defining an analysis function and then calling analyse() to apply this function to each -imputed dataset. For this vignette we use the ancova() function provided by the rbmi +imputed dataset. For this vignette we use the ancova() function provided by the rbmi package which fits a separate ANCOVA model for the outcomes from each visit and returns a treatment effect estimate and corresponding least square means for each group per visit.

    anaObj <- analyse(